П.С. А может есть способы бороться с количеством обращений? Интересно, что тут можно сделать ))
Спустя 10 минут, 32 секунды (12.01.2011 - 01:27) inpost написал(а):
gidrosoldat
Крутость сервера * оптимальность скриптов + использование кеширования и буфера - количество обращений одновременных = работа сайта. Подставив в это уровнение лишь число посетителей ты врядли узнаешь результат.
Крутость сервера * оптимальность скриптов + использование кеширования и буфера - количество обращений одновременных = работа сайта. Подставив в это уровнение лишь число посетителей ты врядли узнаешь результат.
Спустя 1 минута, 5 секунд (12.01.2011 - 01:28) Игорь_Vasinsky написал(а):
| Цитата |
| А может есть способы бороться с количеством обращений? |
конечно - пеестать платить за домен - и обращения к БД исчезнут.
на счёт остального - не задумовался - т.к. google и майл.ру не писал ещё.
всё зависит от сервера и его конфигурации.
Спустя 40 минут, 25 секунд (12.01.2011 - 02:09) inpost написал(а):
gidrosoldat
До 1000 онлайн легко выдержит сайт, а дальше надо думать =)
Игорь_Vasinsky
Когда начинает шкалить Мускул - надо кешировать страницы и запросы, когда начинает шкалить ПХП - надо покупать лучше сервак с лучшей конфигурацией.
До 1000 онлайн легко выдержит сайт, а дальше надо думать =)
Игорь_Vasinsky
Когда начинает шкалить Мускул - надо кешировать страницы и запросы, когда начинает шкалить ПХП - надо покупать лучше сервак с лучшей конфигурацией.
Спустя 13 часов, 10 минут, 28 секунд (12.01.2011 - 15:19) gidrosoldat написал(а):
Ну хорошо, давайте на примерах:
Этот самый форум, в каждой строке есть:
значок темы,
название,
описание темы,
сколько тем и ответов,
время, автор и тема последнего обновления.
По идее можно все эти данные вставить в одну таблицу и на этом успокоится. Однако, при этом данные будут дублироваться с другими таблицами и при добавлении темы или комментария придется делать несколько обращений к базе данных (записывать в разные таблицы).
Другой способ, раскладывать все по своим полочкам - данные по форумам в таблице форумов, данные по темам в таблице тем, данные по пользователям в теблице пользователей. Но, при таком расскалде (хмм, действительно расскладе )) не получится вытащить всю информацию одним запросом. Потому как не будет в таблице категорий информации о последнем обновлении (времени, пользователи и последней теме). Количество запросов увеличивается в разы...
Млин, запутанно как-то вышло, извините. Но может кто уже задумывался над этим.
Этот самый форум, в каждой строке есть:
значок темы,
название,
описание темы,
сколько тем и ответов,
время, автор и тема последнего обновления.
По идее можно все эти данные вставить в одну таблицу и на этом успокоится. Однако, при этом данные будут дублироваться с другими таблицами и при добавлении темы или комментария придется делать несколько обращений к базе данных (записывать в разные таблицы).
Другой способ, раскладывать все по своим полочкам - данные по форумам в таблице форумов, данные по темам в таблице тем, данные по пользователям в теблице пользователей. Но, при таком расскалде (хмм, действительно расскладе )) не получится вытащить всю информацию одним запросом. Потому как не будет в таблице категорий информации о последнем обновлении (времени, пользователи и последней теме). Количество запросов увеличивается в разы...
Млин, запутанно как-то вышло, извините. Но может кто уже задумывался над этим.
Спустя 3 часа, 2 минуты, 56 секунд (12.01.2011 - 18:22) inpost написал(а):
gidrosoldat
Нагрузка идёт на первую страницу, собственно, она и кешируется по всем запросам.
Нагрузка идёт на первую страницу, собственно, она и кешируется по всем запросам.
Спустя 2 часа, 33 минуты, 59 секунд (12.01.2011 - 20:56) gidrosoldat написал(а):
inpost
то есть кеширование это один из способов избежать излишних запросов к БД?
Ок, оставим пока на время кеширование (хотя не плохо было бы, что бы кто нибудь добавил такой раздел в ваши курсы).
Кстати, мой вопрос так и остался без ответа. Оправдано ли будет дублирование некоторых данных в таблицах, результатом чего станет уменьшение числа обращений к БД ? Или это неправильная тактика и от этого лучше сразу отвыкать?
(спустя 30 минут) Таак, я тут для себя открыл SQL функцию LEFT JOIN, которая практически ответила на мой вопрос. В любом случае, спасибо за ликбез, немного жаль вашего впустую потраченного времени ))
то есть кеширование это один из способов избежать излишних запросов к БД?
Ок, оставим пока на время кеширование (хотя не плохо было бы, что бы кто нибудь добавил такой раздел в ваши курсы).
Кстати, мой вопрос так и остался без ответа. Оправдано ли будет дублирование некоторых данных в таблицах, результатом чего станет уменьшение числа обращений к БД ? Или это неправильная тактика и от этого лучше сразу отвыкать?
(спустя 30 минут) Таак, я тут для себя открыл SQL функцию LEFT JOIN, которая практически ответила на мой вопрос. В любом случае, спасибо за ликбез, немного жаль вашего впустую потраченного времени ))
Спустя 1 час, 3 минуты, 26 секунд (12.01.2011 - 21:59) inpost написал(а):
gidrosoldat
ага, и сделай огромный left-join и поломай себе сайт =) Удачи.
ага, и сделай огромный left-join и поломай себе сайт =) Удачи.
Спустя 20 минут, 59 секунд (12.01.2011 - 22:20) gidrosoldat написал(а):
inpost, зачем огромный? Без излишнего фанатизма, без шума, без пыли )) Вообщем, пока ничего конкретно сказать не могу. Проверю на практике и выдам трезвую оценку )