Оптимизация Nginx + PHP-FPM для более быстрого времени отклика (для Openx adserving)

В настоящее время я запускаю Nginx + PHP-FPM для показа объявлений на OpenX. В настоящее время мое время отклика является ужасным даже во времена низкой нагрузки. Тем не менее, мои ресурсы процессора и памяти прекрасны, поэтому я не могу понять, что такое узкое место.

Моя текущая конфигурация для nginx и php-fpm:

worker_processes 20;
worker_rlimit_nofile 50000;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  15000;
    multi_accept off;
    use epoll;
}

http {
    include       /etc/nginx/mime.types;

    access_log  /var/log/nginx/access.log;

    sendfile        on;
    tcp_nopush     off;

    keepalive_timeout  0;
    #keepalive_timeout  65;
    tcp_nodelay        on;

    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
    gzip_comp_level 2;
    gzip_proxied    any;
    gzip_types    text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

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

server {
    listen   80;
    server_name  localhost;
    access_log  /var/log/nginx/localhost.access.log;

# Default location
    location / {
        root   /var/www;
        index  index.php;
    }

## Parse all .php file in the /var/www directory
    location ~ .php$ {
        fastcgi_pass   localhost:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /var/www$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_param  QUERY_STRING     $query_string;
        fastcgi_param  REQUEST_METHOD   $request_method;
        fastcgi_param  CONTENT_TYPE     $content_type;
        fastcgi_param  CONTENT_LENGTH   $content_length;
        fastcgi_ignore_client_abort     off;
    }

PHP-FPM:
rlimit_files = 50000
max_children = 500

Я включил только параметры PHP-FPM, которые я изменил для PHP-FPM.

Есть ли у кого-нибудь советы о том, как я могу его оптимизировать, чтобы я мог обслуживать больше запросов? Я вижу ужасные времена отклика прямо сейчас.

Ответы

Ответ 1

Во-первых, слишком много рабочих и лимиты слишком высоки. Максимальный рабочий счетчик только для php-fpm может немного заглушить ваш сервер. Отказ от ограничений на сервере не обязательно ускорит его, но может иметь противоположный эффект.

Количество рабочих: 20 не имеет смысла, если у вас нет 20-процессорной/основной машины, вы фактически нанесете отрицательный эффект, так как у рабочих будет чрезмерное переключение содержимого. Если вы используете двухъядерный процессор, должно быть достаточно 2 рабочих.
Рабочие соединения: Опять же, просто бросать лимит в небеса не решает ваши проблемы. Если ваш вывод ulimit -n составляет примерно 1024, тогда ваши рабочие соединения должны быть установлены на 1024 или меньше (может быть, даже на 768), маловероятно, что у вас будет 2 x 1024 одновременных подключения, особенно с чем-то вроде PHP.
Расположение корня и настройки PHP см. в http://wiki.nginx.org/Pitfalls, он лучше всего работает, если вы поместите свою корневую директиву на уровне сервера {}, а не уровень местоположения. Как только вы это сделаете, вы можете использовать $document_root $fastcgi_script_name как значение SCRIPT_FILENAME, поскольку $document_root будет автоматически распространяться на блоки местоположения под ним.

Вы можете обращаться с статическими файлами напрямую, другими словами:

location ~* \.(ico|css|js|gif|jpe?g|png)$ {
    expires max;
    add_header Pragma public;
    add_header Cache-Control "public, must-revalidate, proxy-revalidate";
}

Используйте ускоритель PHP, а именно APC (с apc.enabled = 1 в php.ini) или XCache, и помните о своих настройках php, таких как memory_limit. Например, если у вас есть только система с 2 ГБ баранов, у нее мало смысла разрешать 500 рабочих с ограничением по 128 Мбайт каждый. Особенно верно, если вы также используете другие службы на своем сервере.

Ответ 2

Было бы также полезно поставить:

access_log off;

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

Ответ 3

Вы должны определенно сократить количество рабочих, поскольку я сомневаюсь, что у вас есть 20 ядер/процессоров. Кроме того, я бы посмотрел на ваш сервер базы данных, там большая вероятность, что проблема там.

Кроме того, вы повысили worker_rlimit_nofile до 50000, надеюсь, вы знаете, что операционная система обычно устанавливает ограничение на 1024 (по умолчанию), вы можете попытаться запросить текущий лимит, набрав ulimit -n

Вы можете поднять жесткий предел NOFILE (количество открытых файлов), выполнив эту команду ulimit -n 50000 в init.d или fooobar.com/questions/254481/..., чтобы узнать как использовать limits.conf для постоянного ограничения пределов системы.

Ответ 4

У вас есть 20 процессоров или ядер на вашем компьютере? также возможно попробовать события со значением по умолчанию для вашей ОС... возможно, больше процессов fcgi, а не больше nginx... возможно, начиная с 2 - 4 рабочих nginx достаточно...

Ответ 5

Действительно повышение производительности до max с nginx и php5-fpm - это искусство. Он действительно понимает, какое содержание вы обслуживаете.

Например, я не вижу использования try_files или какого-либо кэширования в вашей конфигурации. Вы знаете, что nginx поставляется со встроенной поддержкой memcache? Вы можете кэшировать изображения и html/css, а также php-страницы. Если вам больше всего нравятся клики, эти клики по-прежнему будут учитываться, даже если на дисплее нет.

Поместите свои баннеры в монтирование tmpfs, не заходите в журнал access_log или error_log, отключите модули, которые вам не нужны в php, используйте последнюю версию mysql, используйте innodb для уменьшения блокировки таблицы, играйте с методом промывки innodb для уменьшения записи на диске, увеличения максимальных таблиц памяти в mysql для уменьшения создания временных файлов на диске при запросе запросов через SQL и т.д.

Nginx - это лишь одна часть очень большой и сложной формулы. Я даже не упомянул параметры Kernel для оптимизации производительности TCP-стека и сетевой карты, использования Swap, использования памяти или сжатия gzip HTML/CSS, которые вы можете обслуживать через OpenX (если есть).

И да, как и другие выше меня, ваши настройки выглядят чрезмерно и показывают отсутствие понимания основных концепций оптимизации. Другими словами, нанять профессионала: -)

Ответ 6

Определенно, это могут быть и рабочие, о которых говорили люди. Я лично предпочитаю xcache поверх APC для кэширования кода опциона php. Вы должны проверить конфигурацию в измененном файле centmin auto bash shell nginx/php-fpm install script http://vbtechsupport.com/796/

Ответ 7

Самый эффективный способ сделать серверную систему намного быстрее - использовать Facebook HipHop Virtual Machine (HHVM) вместо PHP (PHP не должен быть установлен больше).

HHVM использует перед процессором "Just in Time Compiler" и выполняет обычно PHP-код в 5-10 раз быстрее, чем сам PHP, он позволяет ладить с меньшим количеством серверов или меньших серверов и уменьшать энергопотребление в основном. Википедия использовала HHVM для снижения нагрузки на сервер ЦП на фактор 5: http://www.golem.de/news/php-facebooks-hhvm-macht-wikipedia-schneller-1501-111515.html

Он может быть установлен вместе с Nginx как пакет Linux и включен в Nginx очень легко, как FastCGI, и вскоре через несколько минут его можно протестировать через небольшой файл PHP Hello World: https://github.com/facebook/hhvm/wiki/Getting-Started

Новый PHPNG PHPNG должен быть правдивым в соответствии с тестовыми испытаниями только на 30% быстрее.

спасибо за выживание