|
ru.perl
- RU.PERL ----------------------------------------------------------------------
From : Artem Chuprina 2:5020/400 15 Mar 2004 23:57:04
To : Timur Vafin
Subject : Re: автокеширование объектов
--------------------------------------------------------------------------------
Timur Vafin -> Artem Chuprina @ Mon, 15 Mar 2004 19:09:37 +0000 (UTC):
>>>>>>> Объясни популярно, какой смысл в кеше бекенда, если фронтенду
>>>>>>> практически всегда приходится ходит к бекэнду за тем, чтобы что то
>>>>>>> было в кеше?
IF>>>>>> В том, что вместо 200 модперловых апачей у тебя их 15-20.
TV>>>>> Мы друг друга не понимаем, точно ;( Как апачей будет меньше если на
TV>>>>> каждый запрос к фротэнду, он идет к бекэнду?
AC>>>> Тормоз - тоже механизм. Связку фронтэнд-бэкэнд не лимитирует скорость
AC>>>> канала до клиента. Связку клиент-сервер - лимитирует.
AC>>>> Кроме того, крайне редко бывает так, что _все_ содержимое страницы,
AC>>>> включая CSS'ы и картинки, требует запроса к базе, а следовательно,
AC>>>> обращения к бэкэнду. _Как правило_ на одну страницу, показанную
AC>>>> клиенту его браузером, требуется 10-20 запросов, из которых к бэкэнду
AC>>>> - ровно один.
TV>>> Мы же уже договорились, что всю статитку отдаем кем то другим, отличным
TV>>> от апача с мод_перл? Разговор сразу шел только о тех запросох которые
TV>>> обрабатывает апач с мод_перлом.
AC>> Тогда их у тебя стало 15-20 вместо 200 еще на предыдущем этапе.
TV> Да видимо у меня кривые руки. Тогда получается, что 15-20 апачей
TV> должно быть при каокй популярности ресурса?
TV> В моем примере, в _среднем за сутки_ 5-6 запрос в секунду к модперловым
TV> апачам.
Один из ведущих новостников на пиках давал до 180 запросов в секунду к
фронтэндам. Статистику по запросам к бэкэндам не считали, но количество
бэкэндов держали в пределах 40. Да, приходилось местами извращаться.
5-6 запросов в секунду к бэкэнду при 15-20 бэкэндах в среднем же дает
бэкэнду 3 секунды на отработку запроса. Это уже само по себе долго,
куда больше-то? При такой средней нагрузке я бы ставил MaxClients 50,
если позволяет память (бурный своппинг тут сильно ухудшит дело, так что
обычно лучше чаще видеть в логах reached MaxClients setting, чем
получить шуршание свопом - когда под другим, менее посещаемым новостником
была слабенькая машинка, помнится, снижение MaxClients с 30 до 20
ускорило сервер почти вдвое), MaxSpareServers 5-7, MinSpareServers 3.
--
Artem Chuprina
RFC2822: <ran@ran.pp.ru>, FIDO: 2:5020/122.256, ICQ: 13038757
--- ifmail v.2.15dev5.3
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
