Re: Уменьшение размера очереди для бэкенда
Gena Makhomed
gmm at csdoc.com
Tue Jan 15 01:04:28 MSK 2008
Здравствуйте, Михаил.
Вы писали 14 января 2008 г., 1:13:00:
> Или не давать Апачу новые запросы, пока он не переварил старые.
эти запросы апачу и так не уходят, а стоят в системной очереди.
параметр MaxClients оптимально настроен?
http://www.opennet.ru/base/dev/tune_maxclients.txt.html
================================================================
Date: Wed, 20 Jun 2001 16:03:57 +0400 (MSD)
From: Igor Sysoev <is at stack.net>
To: apache-talk at lists.lexa.ru
Subject: Оптимальная настройка *Servers и MaxClients директив в Apache
> Есть в httpd.conf следующие директивы:
> Timeout
> KeepAlive
> KeepAliveTimeout
> MinSpareServers
> MaxSpareServers
> StartServers
> MaxClients
> MaxRequestsPerChild
>
> Как вычислить (определить) значения этих директив, для стабильной
> работы сервера? ОТ каких занчений надо отталкиваться, на что
> обратить внимание?
Запускаешь /server-status, смотришь сколько idle servers.
Если 0, то нужно увеличить MaxClients.
Запускаешь top и смотришь, есть ли активный свопинг. Если нет,
то можно по-маленьку (скажем, по 10) увеличивать MaxClients.
Если есть свопинг и нет idle серверов, то нужно добавлять память.
MaxRequestsPerChild можно сделать больших для обычного Апача
и небольшим (порядка 300-500) для mod_perl'а. Хотя я размеры mod_perl'а
ограничиваю с помощью Apache::SizeLimit, а не MaxRequestPerChild.
KeepAlive имеет смысл ставить, если один сервер отдаёт и текст
и картинки, тогда MSIE, а это >60% запросов (90% всего - 30% через
прокси), будут качать страницу и картинки через одно соединение -
быстрее будет отдаваться и на одного MSIE будет расходоваться
один процесс Апача, а не 4 (обычно).
Игорь Сысоев
================================================================
PS только поскольку Apache будет за nginx`ом, то MaxClients
наверное стоит увеличивать более плавно, по 5 или даже по 1
KeepAlive при соединениях с backend`ами nginx не использует
--
С уважением,
Gena mailto:gmm at csdoc.com
More information about the nginx-ru
mailing list