Настройка высокопроизводительного сервера nginx и wordpress

Я проводил нагрузочные тесты (через 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"

Что мне не хватает? Почему ожидающие запросы не ставятся в очередь, а затем не завершаются или не задерживаются позже в процессе?

Источник

2 ответа

Скорее всего, ваша проблема связана с конфигурацией PHP-FPM, поскольку вы используете статический диспетчер процессов только с 8 дочерними процессами. Практически любое нагрузочное тестирование мгновенно израсходует эти 8 дочерних процессов и потребует большего - когда нет никакого незанятого дочернего процесса для обработки кода PHP, вы получите 502 ошибки, которые вы видите.

Вы должны перейти на динамический, или даже лучше (на мой взгляд), по требованию.

Кроме того, установите max_children достаточно высоким, в зависимости от того, какие виды нагрузочных тестов вы выполняете. Не зная деталей тестов, которые вы запускаете, я не могу предложить никаких значений для max_children. В моем случае, когда у меня есть несколько сайтов, которые в целом получают ~2500 уникальных посетителей и ~15 000 просмотров страниц в день, мой 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 должен вести себя, когда целевые серверы выключаются, используя проверки работоспособности. При этом вы можете определить, как долго будет задерживаться, когда сервер будет отмечен как отключенный. Будучи отклоненными, запросы не будут поступать к нему, пока не пройдёт условие проверки здоровья, чтобы снова его отметить.

Источник
Другие вопросы по тегам