Как оптимизировать php+fpm?

Question

[VitaliyBorys]

Друзья, есть VPS c характеристиками:
Ubuntu 18.04
RAM: 6144 Мб
Диск SSD: 70000 Мб
CPU: 2x2.8 Ghz

Провожу стресс нагрузку с помощью jmetter.
Отправляю 100 потоков на главною страницу (тут даже в бд запросов совсем мало).
Результат получения ответа в ста потоках колеблится от с Load time: 1160 до Load time: 6136.
Если отправить просто один поток, то ответ за 230мс.

Думал что может проблемы в БД, или в коде. Решил создать просто пустой файл index.php и вывоел там phpinfo().
То есть никакой там базы нету, вообще ничего нету, кроме вывода phpinfo().

Отправляю 100 потоков и получаю :
С Load time: 124 и до Load time: 3135.

Почему такая существенная разница ? Почему вообще так долго ? Т
Предполагаю, что дела в php или nginx.

Я поставил все по дефолту (nxinx 1.4 + php-fpm7.2).

И изменил следующие параметры.
/etc/php/7.2/fpm/pool.d/www.conf
pm.max_children = 140
pm.start_servers = 20
pm.min_spare_servers = 20
pm.max_spare_servers = 60
pm.max_requests = 500

Вот конфигурация NGINX nginx.conf
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
use epoll;
worker_connections 2048;
multi_accept on;
}

http {

include /etc/nginx/mime.types;
default_type application/octet-stream;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;

access_log off;
error_log /var/log/nginx/error.log crit;

keepalive_timeout 30;
keepalive_requests 100;

client_max_body_size 1m;
client_body_timeout 10;
reset_timedout_connection on;
send_timeout 2;
sendfile on;
tcp_nodelay on;
tcp_nopush on;

gzip on;
gzip_disable "msie6";
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

open_file_cache max=200000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

# PHP-FPM Configuration Nginx
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/run/php/php7.2-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

Друзья, что не так ? Куда копать ?
Желаемый результат :
Отправить 100 потоков на пустой файл и получить их за одинаковую скорость, ну и не больше чем 200-300мс

Comments

[Lynn «Кофеман»]

Прямо сразу 100 без плавного повышения нагрузки?

А вам реально столько нужно?

[Дмитрий]

Zend opcache можно ещё глянуть
Ну и сам фпм тоже посмотреть

[VitaliyBorys]

Алексей Тен, плавное повышение может быть. Просто если 100 запросов на пустой файл, то почему 3 секуда аж ? Я думаю это долго, вы так не считаете ?

[VitaliyBorys]

Дмитрий, он по дефолту включен в php7.2-fpm

[Lynn «Кофеман»]

VitaliyBorys, потому что с нуля одномоментно поднять ещё 80 воркеров это всё равно не быстро. К тому же всего на двух ядрах

[Дмитрий]

VitaliyBorys, но там есть настойки

[VitaliyBorys]

Алексей Тен, как-то можно это оптимизировать ? Чтоб быстрее было ? При текущих параметрах машины

[Андрей]

А если /index.html с реальной статикой отдавать - какая скорость будет?

[VitaliyBorys]

Хорошая идея. я попробую.

[Adamos]

Попробовать аналогичную конфигурацию на пробном периоде у другого хостера?

[VitaliyBorys]

Пробовал. Результат практически тот же. Думаю надо копаться в настройках nginx и php-fpm

[VitaliyBorys]

Андрей,
Да. Поставил 200 потоков. отработало мгновенно. Ну на мысль ни на какую не натолкнуло.

[Андрей]

pm.max_requests = 1000000
pm.max_children = 10
pm.start_servers = 2

А если так?

Answer 1

[Vitaly Karasik]

- А что показывает 'top'?
- я бы проверил при какой нагрузке начинает замедляться

Answer 2

[deadem]

А вы, надеюсь, не с той же самой машины запросы шлёте? Jmeter охоч до памяти и ресурсов, что скорости совсем не прибавит... И число потоков нужно выставлять руководствуясь числом ядер процессора и размером памяти, которую будет есть jmeter плюс ваше приложение, иначе ресурсы будут утекать просто на переключение между потоками и работу со свопом. Вполне вероятно, что в итоге тормозит не сайт, а тестировщик. Многопоточную нагрузку правильно тестировать с удалённого сервера, чтобы исключить влияние среды тестирования на стенд. А если нужно протестировать работу со 100 потоками, придётся запускать одновременно несколько удалённых тестирующих машин, или искать 100-ядерный компьютер-монстр.

Рекомендую ознакомиться с jmeter.apache.org/usermanual/best-practices.html

Comments

[VitaliyBorys]

Ну конечно же не с той же машины.
Запросы посылаю со своего ноута.