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

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

20 голосов
/ 16 февраля 2010

В настоящее время я использую 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.

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

Ответы [ 7 ]

70 голосов
/ 28 марта 2011

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

  1. Количество рабочих: 20 не имеет особого смысла, если у вас нет 20-процессорной / основной машины, вы фактически оказываете негативное влияние, поскольку рабочие будут иметь чрезмерную перестановку контента. Если вы используете двухъядерный процессор, достаточно двух рабочих.

  2. Рабочие связи. Опять же, просто бросив предел в небеса, вы не решите свои проблемы. Если ваш вывод ulimit -n похож на 1024, тогда ваши рабочие соединения должны быть установлены на 1024 или меньше (возможно, даже на 768), маловероятно, что вы будете иметь 2 x 1024 одновременных соединений, особенно с чем-то вроде PHP.

  3. Местоположение корня и настройки PHP, см. http://wiki.nginx.org/Pitfalls, лучше всего, если вы поместите корневую директиву на уровне сервера {}, а не на уровне местоположения. Как только вы это сделаете, вы можете использовать $ document_root $ fastcgi_script_name в качестве значения SCRIPT_FILENAME, так как $ document_root будет автоматически распространяться на блоки размещения под ним.

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

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

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

6 голосов
/ 04 июня 2011

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

access_log off;

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

4 голосов
/ 02 августа 2010

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

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

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

3 голосов
/ 25 января 2013

Действительно добиться максимальной производительности с помощью nginx и php5-fpm - это искусство. Требуется действительно понимание того, какой контент вы обслуживаете.

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

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

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

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

1 голос
/ 24 февраля 2010

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

0 голосов
/ 28 февраля 2015

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

HHVM использует «вверх по времени» компилятор «Just in Time» и выполняет обычно код 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

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

спасибо за голосование

0 голосов
/ 20 мая 2011

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

...