优化 Nginx + PHP-FPM 以加快响应时间(用于 Openx 广告)

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/2271670/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-25 05:49:34  来源:igfitidea点击:

Optimize Nginx + PHP-FPM for faster response times (for Openx adserving)

phpnginxopenx

提问by Fariz

I'm currently running Nginx + PHP-FPM for serving ads on OpenX. Currently my response times are horrible, even during times of low load. However, my CPU and Memory resources are fine, so I can't seem to figure out what the bottleneck is.

我目前正在运行 Nginx + PHP-FPM 来在 OpenX 上投放广告。目前,即使在低负载期间,我的响应时间也很糟糕。但是,我的 CPU 和内存资源很好,所以我似乎无法弄清楚瓶颈是什么。

My current config for nginx and php-fpm is:

我当前的 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

I only included the PHP-FPM paramaters I've changed for PHP-FPM.

我只包含了我为 PHP-FPM 更改的 PHP-FPM 参数。

Does anyone have any tips on how I can optimize it so I can serve more requests? I'm seeing horrendous response times right now.

有没有人有任何关于如何优化它以便我可以满足更多请求的提示?我现在看到了可怕的响应时间。

回答by KBeezie

First off, way too many workers, and limits set excessively high. The max worker count for php-fpm alone would bog your server down quite a bit. Uncapping the limits on a server won't necessarily speed it up but may actually have the opposite effect.

首先,工人太多,限制设置过高。单独使用 php-fpm 的最大工作线程数会使您的服务器陷入相当多的停滞。取消对服务器的限制不一定会加快速度,但实际上可能会产生相反的效果。

  1. Worker Count: 20 makes little sense if you do not have a 20 processor/core machine, you're actually causing a negative effect as the workers will have excessive content swapping. If you're running a dual core processor, 2 workers should suffice.

  2. Worker Connections: Again, just throwing a limit into the heavens doesn't solve your problems. If your ulimit -n output is something like 1024, then your worker connections would need to be set to 1024 or less (maybe even 768), its unlikely that you'll have 2 x 1024 simultaneous connections especially with something like PHP.

  3. Root location, and PHP settings, refer to http://wiki.nginx.org/Pitfalls, it works best if you put your root directive at the server {} level, not the location level. Once you do that you can use $document_root$fastcgi_script_name as the SCRIPT_FILENAME value as $document_root will be automatically propagated to location blocks below it.

  4. You may wish to handle static files directly, in other words:

    location ~* \.(ico|css|js|gif|jpe?g|png)$ {
        expires max;
        add_header Pragma public;
        add_header Cache-Control "public, must-revalidate, proxy-revalidate";
    }
    
  5. Use a PHP Accelerator, namely APC (with apc.enabled=1 in php.ini) or XCache, and be mindful of your php settings, such as the memory_limit. For example if you only have a system with 2GB of rams, it makes very little sense to allow 500 workers with a limit of 128MB each. Especially true if you're also running other services on your server.

  1. 工人数量:如果您没有 20 个处理器/核心的机器,则 20 毫无意义,您实际上会造成负面影响,因为工人将进行过多的内容交换。如果您运行的是双核处理器,2 个工人就足够了。

  2. Worker Connections:再说一次,只是在天上设置一个限制并不能解决你的问题。如果您的 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 加速器,即 APC(在 php.ini 中使用 apc.enabled=1)或 XCache,并注意您的 php 设置,例如 memory_limit。例如,如果您的系统只有 2GB 的内存,那么允许 500 个工人每个限制为 128MB 是没有意义的。如果您还在服务器上运行其他服务,则尤其如此。

回答by zmf

Would be also useful to put:

放置以下内容也很有用:

access_log off;

As i suppose you don't really care of log generation on these requests.

我想你并不真正关心这些请求的日志生成。

回答by zmf

You should definitely reduce the number of workers as I doubt you have 20 cores/processors. Additionally, I'd look into your database server, there's a big possibility that the problem is there.

您绝对应该减少工人数量,因为我怀疑您有 20 个内核/处理器。此外,我会查看您的数据库服务器,问题很可能出在那里。

Additionally you've upped the worker_rlimit_nofileto 50000, I hope you know that operating system usually set the limit to 1024 (default), you can try to request what's the current limit by typing ulimit -n

此外,您已将 提高worker_rlimit_nofile50000,我希望您知道操作系统通常将限制设置为 1024(默认),您可以尝试通过键入来请求当前限制是多少ulimit -n

You can raise hard limit of NOFILE (number of open files) by executing this command ulimit -n 50000in init.d or visit this other question on stackoverflowto learn how to use limits.confto permanently set limits system wide.

您可以通过ulimit -n 50000在 init.d 中执行此命令来提高 NOFILE(打开文件的数量)的硬限制,或者访问 stackoverflow上的其他问题以了解如何在limits.conf系统范围内永久设置限制。

回答by Skaag Argonius

Really pushing performance to the max with nginx and php5-fpm is an art. It takes really understanding the kind of contents you are serving.

使用 nginx 和 php5-fpm 真正将性能推到最大是一门艺术。需要真正了解您所服务的内容类型。

For example, I don't see any try_files usage, or any kind of caching in your configuration. Do you know nginx comes with built-in memcache support? You can cache images and html/css, as well as php pages. If you care mostly for clicks, those clicks will still be counted even if displays are not.

例如,我在您的配置中看不到任何 try_files 用法或任何类型的缓存。你知道 nginx 有内置的 memcache 支持吗?您可以缓存图像和 html/css,以及 php 页面。如果您最关心点击次数,即使没有显示,这些点击次数仍会被计算在内。

Put your banners in a tmpfs mount, don't log access_log or error_log, disable modules you don't need in php, use a recent version of mysql, use innodb to reduce table locking, play with the flushing method of innodb to reduce disk writes, increase maximum memory tables in mysql to reduce the creation of temporary files on disk when joins are requested via SQL, etc.

把你的banners放在tmpfs挂载中,不要记录access_log或error_log,在php中禁用你不需要的模块,使用最新版本的mysql,使用innodb减少表锁定,使用innodb的flush方法减少磁盘写入,增加 mysql 中的最大内存表以减少通过 SQL 请求连接时在磁盘上创建临时文件等。

Nginx is just one part of a very large and complex formula. I have not even mentioned Kernel params to optimize the TCP Stack and Network Card performance, Swap usage, Memory usage, or gzip compression of HTML/CSS you may be serving via OpenX (If you are).

Nginx 只是一个非常庞大而复杂的公式的一部分。我什至没有提到内核参数来优化 TCP 堆栈和网卡性能、交换使用、内存使用或您可能通过 OpenX 提供的 HTML/CSS 的 gzip 压缩(如果您是)。

And yes, like others above me mentioned, your settings look excessive and show a lack of understanding of basic optimization concepts. In other words, hire a professional :-)

是的,就像我上面提到的其他人一样,您的设置看起来过多,并且缺乏对基本优化概念的理解。换句话说,聘请专业人士:-)

回答by Todd

do you have 20 processors or cores on your machine? also maybe try events with the default for your OS... maybe more fcgi processes instead of more nginx... probably starting with 2 - 4 nginx workers is enough...

你的机器上有 20 个处理器或内核吗?也可以尝试使用操作系统默认的事件......也许更多的 fcgi 进程而不是更多的 nginx......可能从 2 - 4 个 nginx 工作人员开始就足够了......

回答by p4guru

Definitely way too may workers as folks have mentioned. I personally prefer xcache over APC for php opcode caching. You should check out configuration in modified centmin auto bash shell nginx/php-fpm install script http://vbtechsupport.com/796/

正如人们所提到的那样,工人当然也可以。我个人更喜欢 xcache 而不是 APC 用于 php 操作码缓存。您应该在修改后的 centmin auto bash shell nginx/php-fpm 安装脚本http://vbtechsupport.com/796/ 中查看配置

回答by MariaJameson

The most effective way to make a server system much faster is to use Facebooks HipHop Virtual Machine (HHVM) instead of PHP (PHP not must be installed any more).

使服务器系统更快的最有效方法是使用 Facebook 的 HipHop 虚拟机 (HHVM) 而不是 PHP(不必再安装 PHP)。

HHVM uses upstream of the CPU a "Just in Time Compiler" and executes the usually PHP code 5 to 10 times faster than PHP itself, it makes it possible to get along with a smaller number of servers or smaller servers and to reduce the power consumption essentially. Wikipedia used HHVM to reduce the CPU server load by the factor 5: http://www.golem.de/news/php-facebooks-hhvm-macht-wikipedia-schneller-1501-111515.html

HHVM 使用 CPU 上游的“Just in Time Compiler”,执行通常 PHP 代码的速度比 PHP 本身快 5 到 10 倍,这使得它可以与较少数量的服务器或较小的服务器相处并降低功耗本质上。维基百科使用 HHVM 将 CPU 服务器负载减少了 5 倍:http: //www.golem.de/news/php-facebooks-hhvm-macht-wikipedia-schneller-1501-111515.html

It can be installed together with Nginx as Linux package and be included in Nginx very easily similar as FastCGI, and soon after a few minutes it can be tested trough a small "Hello World" PHP file: https://github.com/facebook/hhvm/wiki/Getting-Started

它可以作为 Linux 包与 Nginx 一起安装,并且很容易包含在 Nginx 中,类似于 FastCGI,几分钟后就可以通过一个小的“Hello World”PHP 文件进行测试:https: //github.com/facebook /hhvm/wiki/入门

The new PHP7 PHPNG should be in truth according to benchmark tests only 30% faster.

根据基准测试,新的 PHP7 PHPNG 实际上应该只快 30%。

thanks for upvoting

感谢您的点赞