Здравствуйте. Тут нарисовались довольно любопытные тенденции по настройке 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 <[EMAIL PROTECTED]> ------ Linux.Kiev http://www.linux.kiev.ua/ _______________________________________________ Sysadmins mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/sysadmins
