Я проводил нагрузочные тесты (через blitz.io), пытаясь настроить производительность сервера на пуле серверов с php 5.5, wordpress 3.9.1 и nginx 1.6.2.
Моя путаница возникает, когда я перегружаю один сервер слишком большим трафиком. Я полностью понимаю, что на сервере есть ограниченные ресурсы, и на каком-то уровне он должен будет начать отклонять соединения и / или возвращать 502 (или аналогичные) ответа. Что меня смущает, так это то, почему мой сервер, кажется, возвращает 502-е так рано во время нагрузочного теста.
Я попытался настроить nginx для приема нескольких подключений:
nginx.conf
worker_processes auto;
worker_rlimit_nofile 100000;
events {
worker_connections 1024;
use epoll;
multi_accept on;
}
site.conf
location ~ \.php$ {
try_files $uri =404;
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_read_timeout 60s;
fastcgi_send_timeout 60s;
fastcgi_next_upstream_timeout 0;
fastcgi_connect_timeout 60s;
}
php www.conf
pm = static
pm.max_children = 8
Я ожидаю, что нагрузочный тест довольно быстро насытит рабочих PHP. Но я также ожидаю, что nginx продолжит принимать соединения и после истечения времени ожидания fast_cgi начнет возвращать какой-то код ошибки HTTP.
На самом деле я вижу, что nginx возвращает 502 почти сразу после запуска теста.
nginx error.log
2014/11/01 20:35:24 [error] 16688#0: *25837 connect() to unix:/var/run/php5-fpm.sock failed
(11: Resource temporarily unavailable) while connecting to upstream, client: OBFUSCATED,
server: OBFUSCATED, request: "GET /?bust=1 HTTP/1.1", upstream:
"fastcgi://unix:/var/run/php5-fpm.sock:", host: "OBFUSCATED"
Что мне не хватает? Почему ожидающие запросы не помещаются в очередь, а затем либо завершаются, либо истекает время ожидания позже в процессе?
Ваша проблема, скорее всего, связана с вашей конфигурацией PHP-FPM, потому что вы используете статический диспетчер процессов только с 8 дочерними процессами. Практически любое нагрузочное тестирование будет использовать эти 8 дочерних процессов мгновенно и потребовать большего - когда нет незанятого дочернего процесса для обработки кода PHP, вы получите 502 ошибки, которые видите.
Вам стоит переключиться на динамический, а еще лучше (на мой взгляд) ondemand.
Кроме того, установите для max_children достаточно высокое значение, в зависимости от того, какие нагрузочные тесты вы выполняете. Не зная подробностей выполняемых вами тестов, я не могу предложить никаких значений для max_children. В моем случае, когда у меня есть несколько сайтов, которые в целом получают ~ 2500 уникальных посетителей и ~ 15000 просмотров страниц ежедневно, для моего max_children установлено значение 64, и оно никогда не приближается к этому числу. Я установил его выше, чем мне нужно, потому что нагрузочное тестирование показало, что мой сервер может обрабатывать намного больше трафика, чем он получает в настоящее время.
После успешного выполнения нагрузочных тестов у вас будет лучшее представление о том, как настроить конфигурацию PHP-FPM. Я бы сказал, установите max_children равным 64, как я; просто проверьте журнал PHP-FPM, чтобы узнать, не превышаете ли вы этот предел, и при необходимости увеличьте его.
Это означает, что часть php вышла из строя и больше не слушает сокет unix.
Таким образом, nginx не будет ничего ставить в очередь, поскольку он просто не может связаться с прокси-сервером для отправки запроса, и на этом этапе вы можете легко представить, что запросы обрабатываются очень быстро на стороне nginx.
Если ваш php-сервер не упал, запросы действительно будут в режиме ожидания относительно fastcgi_connect_timeout и fastcgi_read_timeout значения, ожидая появления какого-либо события. Если эти таймауты были достигнуты, вы должны увидеть 504 коды ошибок.
Ваш worker_connections кстати кажется немного заниженным по сравнению с rlimit.
Также может быть пора начать использовать upstream блок, чтобы решить, как должен вести себя nginx, когда целевые серверы не работают, используя проверки работоспособности. С его помощью вы можете управлять продолжительностью задержки, по достижении которой сервер будет отмечен как неработающий. После того, как он считается отключенным, запросы не дойдут до него до тех пор, пока не будет выполнено условие проверки работоспособности, чтобы пометить его снова.