ощщем, ЛОР, пилю очередной тупняк, проходи мимо.
бенчмарк
ab -n 100000 -c 100 -k -H "Accept-Encoding: gzip, deflate" localhost/ 2>&1 | egrep "^(Failed|Requests)"
процессор Pentium G3258 с разгоном до 3.9GHz, остальное не важно. хотите пофапать на хай-лоад?
значит к делу. вот такой конфиг, (сервер _) отлавливает все запросы, которые не подходят под другие хосты.
server {
listen 80;
server_name _;
location = /_.gif {
empty_gif;
}
}
ab localhost/_.gif выдаст вам результат в 200000 (двести тысяч!) запросов в секунду. empty_gif это модуль, поэтому такой быстрый.
к сожалению, со статикой картина чуть более печальна. ab localhost/index.html (файлик, что идет вместе с nginx'ом), сообщает о выполнении 125000 тире 150000 запросов в секунду, что тоже не так плохо. то есть, берете свой проект, оборачиваете всю динамику в fastcgi_cache, дабы nginx кэшировал запросы в статику и получаете очень быстрый сайт, мягко говоря.
рецепт успеха
worker_processes 4;
worker_priority -5;
worker_rlimit_nofile 9000;
timer_resolution 100ms;
events {
use epoll;
worker_connections 9000;
multi_accept on;
}
чтобы не расходовать ресурс жесткого диска, I/O, желательно отключить логи, ну или, указать buffer=, да побольше.
error_log /var/log/nginx/error.log warn;
access_log /var/log/nginx/access.log main buffer=64k;
access_log off;
log_not_found off;
очень ресурсоемкая директива
с ней производительность просядет до копеечных 40000 тысяч на статике и на 20% на динамике, что лучше откажитесь от нее вообще. забудьте.
баллада о двух стульях и матери. придется выбирать между процессорным временем и линком. ресурсоемкая операция, производительность сервера страдает на 20%, но зато пропускная способность сети может быть увеличена в 3 раза за счет сжатия трафика.
open_file_cache max=9000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
с этим думаю ясно, кэш дескрипторов файлов. нужен.
забудьте о существовании if в nginx, не злоупотребляйте location, каждый отнимает много ресурсов.
любой другой ара-тюнинг по вкусу, на самом деле получится что-то вроде экономии на спичках, так например, tcp_nodelay дает разницу всего в 1000 запросов при 200000 к _.gif (empty_gif). посему смотреть нужно строго по ситуации, конкретных советов уже не дам.
теперь от статики к динамике. обязательно установить php opcache.
# curl http://php.net/distributions/php-5.5.23.tar.xz | tar -xJ -v
# cd php-5.5.23
# ./configure --disable-all --enable-opcache
# make build-modules
# install -m 755 modules/*.so /usr/lib/php/extensions
# echo "zend_extension=opcache.so" > /etc/php/conf.d/opcache.ini
хороший прирост в скорости дает Ъ-распараллеливание и правильная настройка. запускать нужно два бэкенда, абсолютно одинаковых, на одном хосте.
upstream php-fpm {
server unix:/var/run/php5-fpm.sock0 weight=100 max_fails=5 fail_timeout=5;
server unix:/var/run/php5-fpm.sock1 weight=100 max_fails=5 fail_timeout=5;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass php-fpm;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
настройка php-fpm'ов /etc/php/pool{0,1}.conf
[global]
log_level = notice
emergency_restart_threshold = 0
emergency_restart_interval = 0
process_control_timeout = 0
daemonize = yes
[pool0]
listen = /var/run/php5-fpm.sock0
listen.owner = www
listen.group = www
listen.mode = 0660
user = www
group = www
pm = static
pm.max_children = 8
pm.max_requests = 500
второй точно такой же
:%s/pool0/pool1
:%s/sock0/sock1
# /usr/sbin/php-fpm --fpm-config /etc/php/pool0.conf
# /usr/sbin/php-fpm --fpm-config /etc/php/pool1.conf
# /usr/sbin/nginx -t && /usr/sbin/nginx -s reload
а теперь получите пятикратный прирост производительности php. вот.
