[Sysadmins] apache tuning in nginx presence

[Michael Shigorin <mike@osdn.org.ua>]

	Здравствуйте.
Тут нарисовались довольно любопытные тенденции по настройке 
apache-1.3 в качестве бэкенда за nginx.

Если традиционно предлагается[1] поднимать в заметной мере
параметры, отвечающие за количество свободных серверов,
то в случае приёма соединений nginx этот подход, похоже,
менее полезен и может быть вредным (увеличивается scheduling
overhead).

Например, если до внедрения nginx были задействованы такие
параметры:

MinSpareServers 5
MaxSpareServers 20
StartServers 12
MaxClients 12

и это было близко к оптимуму, то в случае, когда неспешные
коннекшны отрабатывает мультиплексирующий nginx, нам гораздо
интересней снизить scheduling overhead путём понижения количества
процессов, между которыми будет распределяться процессорное время:

MinSpareServers 1
MaxSpareServers 2
StartServers 3
MaxClients 4

На двухъядерной однопроцессорной системе (HP ML150 G3,
один Xeon 5140, 2G FBDIMM) под Linux 2.6.18 (Server 4.0)
и скедулере имени OpenVZ (который "двухэтажный" -- сперва
контейнеры, потом задачи в них) исключительно такое изменение
конфигурации только apache привело к изменению результатов
/usr/sbin/ab -n 100 -c 20 (сто запросов в двадцать потоков)
по страничке с форумом:

Time per request:       5505.80 -> 4478.60 [ms] (mean)
Requests per second:    3.63 -> 4.47 [#/sec] (mean)
Time per request:       275.29 -> 223.93 [ms] (mean, across all concurrent requests)

Percentage of the requests served within a certain time (ms)
  50%   4785 -> 4285
  66%   5825 -> 4472
  75%   6879 -> 4610
  80%   7076 -> 4681
  90%   8408 -> 4826
  95%   9112 -> 5005
  98%   9587 -> 5071
  99%   9656 -> 5136
 100%  11491 -> 5276 (last request)

При этом MySQL настроен по соотносящейся части так[2]:

thread_cache = 8
thread_concurrency = 2

Настройка ставила своей целью наличие не менее двух потенциально
конкурентных процессов на одно процессорное ядро согласно общей
практике расчёта оптимальной загрузки системы, но при этом
в отличие от обычных рекомендаций -- была направлена на разумную
минимизацию количества конкурирующих экземпляров httpd, которые
в данной постановке задачи занимаются почти исключительно работой
с веб-приложением, а не дисковым или сетевым I/O и таким образом
конкурируют практически исключительно за CPU и RAM.

Т.е. ограничение количества наиболее активных процессов до двух
на ядро позволило выиграть примерно 10% латентности по нижней
границе и более 50% -- по верхней.

Нагрузка выглядит как две пары httpd:mysql с распределением
потребления процессора примерно как 10:1 на каждое ядро;
уменьшение MaxClients до двух с тем, чтобы ещё снизить
конкуренцию, принесло ~10% уменьшение верхней границы (100%),
но при этом примерно на ту же величину подняло нижнюю границу.

Проварьировав связку с "1-2-3-4", получилось, что при количестве
одновременных подключений 4/20/40/100 среднее время на запрос
особенно не изменяется (скорость остаётся около 4.50/сек).
Последнее замерялось как -n 500 -c 100.

Если эти результаты окажутся полезными -- буду рад включить ещё
несколько комментариев в штатный httpd.conf нашего apache-1.3.x.

PS: народ в Bcc:, надеюсь, не обидится, что поленился форвардить :)

PPS: ещё надеюсь, что не открыл америку через Форточку :)

[1] http://people.redhat.com/alikins/system_tuning.html
[2] http://fly.osdn.org.ua/~mike/docs/mysql-tuning.txt

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/