Оптимизация на стороне сервера с помощью Nginx и pm-static

Наш серверный стек состоял из PHP 7.1.10, Nginx 1.13.3 и MySQL 5.7.19 в Ubuntu 16.04.

PHP-FPM и его настройки диспетчера процессов

php-fpm порождает свои собственные процессы, независимые от процесса веб-сервера. Управление количеством этих процессов настраивается в /etc/php/7.1/fpm/pool.d/www.conf (здесь 7.1 можно заменить на действительный номер версии PHP, который используется в настоящее время).

В этом файле мы находим настройку pm . Этот параметр может быть установлен на dynamic , ondemand и static . Динамическая, возможно, самая распространенная мудрость; это позволяет серверу манипулировать количеством порожденных процессов PHP между несколькими настройками:

 pm = dynamic ; The number of child processes to be created when pm is set to 'static' and the ; maximum number of child processes when pm is set to 'dynamic' or 'ondemand'. ; This value sets the limit on the number of simultaneous requests that will be ; served. pm.max_children = 6 ; The number of child processes created on startup. ; Note: Used only when pm is set to 'dynamic' ; Default Value: min_spare_servers + (max_spare_servers - min_spare_servers) / 2 pm.start_servers = 3 ; The desired minimum number of idle server processes ; Note: Used only when pm is set to 'dynamic' ; Note: Mandatory when pm is set to 'dynamic' pm.min_spare_servers = 2 ; The desired maximum number of idle server proceses ; Note: Used only when pm is set to 'dynamic' ; Note: Mandatory when pm is set to 'dynamic' pm.max_spare_servers = 4 

Значения этих значений не требуют пояснений, и порождение процессов осуществляется по требованию, но ограничено этими минимальными и максимальными значениями.

После исправления проблемы с общими папками Windows с помощью nfs и тестирования с помощью Locust мы смогли получать примерно пять запросов в секунду с ошибками около 17–19% при 100 одновременных пользователях. Как только он был заполнен запросами, сервер замедлялся, и каждый запрос выполнялся более десяти секунд.

Затем мы изменили настройку pm на ondemand .

Ondemand означает, что нет минимальных процессов: как только запросы останавливаются, все процессы останавливаются. Некоторые поддерживают этот параметр, потому что это означает, что сервер не будет тратить ресурсы в нерабочем состоянии, но для экземпляров выделенного (не общего) сервера это не обязательно лучший вариант. Порождение процесса включает в себя издержки, и то, что приобретается в памяти, теряется во времени, необходимом для порождения процессов по требованию. Настройки, которые имеют отношение здесь:

 pm.max_children = 6 ; and pm.process_idle_timeout = 20s; ; The number of seconds after which an idle process will be killed. ; Note: Used only when pm is set to 'ondemand' ; Default Value: 10s 

При тестировании мы немного увеличили эти настройки, меньше заботясь о ресурсах.

Также есть pm.max_requests , который можно изменить и который определяет количество запросов, которые каждый дочерний процесс должен выполнить перед повторным вызовом.

Этот параметр представляет собой компромисс между скоростью и стабильностью, где 0 означает неограниченный.

ondemand не принес больших изменений, за исключением того, что мы заметили больше начального времени ожидания, когда мы начали заполнять наше приложение запросами, и больше начальных сбоев. Другими словами, больших изменений не было: приложение могло обслуживать от четырех до максимум шести запросов в секунду. Время ожидания и частота отказов были аналогичны dynamic настройкам.

Затем мы попробовали настройку pm = static , что позволило нашим процессам PHP захватить максимум ресурсов сервера, за исключением подкачки или остановки процессора. Этот параметр означает, что мы постоянно выталкиваем максимум из нашей системы. Это также означает, что — в рамках ограничений нашего сервера — не будет никаких накладных расходов на порождение.

 proxy_cache_path /home/vagrant/Code/ng-cache levels=1:2 keys_zone=ng_cache:10m max_size=10g inactive=60m; proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504; fastcgi_cache_path /home/vagrant/Code/ngd-cache levels=1:2 keys_zone=ngd_cache:10m inactive=60m; fastcgi_cache_key "$scheme$request_method$host$request_uri"; fastcgi_cache_use_stale error timeout invalid_header http_500; fastcgi_ignore_headers Cache-Control Expires Set-Cookie; add_header NGINX_FASTCGI_CACHE $upstream_cache_status; server { listen 80; listen 443 ssl http2; server_name nginx-performance.app; root "/home/vagrant/Code/project-nginx/public"; index index.html index.htm index.php; charset utf-8; proxy_cache ng_cache; location / { try_files $uri $uri/ /index.php?$query_string; } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { access_log off; log_not_found off; } access_log off; error_log /var/log/nginx/nginx-performance.app-error.log error; sendfile off; client_max_body_size 100m; location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php/php7.1-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_intercept_errors off; fastcgi_buffer_size 16k; fastcgi_buffers 4 16k; fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; fastcgi_cache ngd_cache; fastcgi_cache_valid 60m; } location ~ /\.ht { deny all; } ssl_certificate /etc/nginx/ssl/nginx-performance.app.crt; ssl_certificate_key /etc/nginx/ssl/nginx-performance.app.key; } 

 proxy_cache_path /home/vagrant/Code/ng-cache levels=1:2 keys_zone=ng_cache:10m max_size=10g inactive=60m; 

 fastcgi_cache_purge 

 fastcgi_cache_path /data/nginx/cache keys_zone=cache_zone:10m; map $request_method $purge_method { PURGE 1; default 0; } server { ... location / { fastcgi_pass backend; fastcgi_cache cache_zone; fastcgi_cache_key $uri; fastcgi_cache_purge $purge_method; } } 

 add_header NGINX_FASTCGI_CACHE $upstream_cache_status;