扩展Nginx、PHP-FPM和MongoDB

Question

我正在寻找在Nginx下使用PHP-FPM扩展PHP应用程序的最佳方法。我正在考虑大约1200的并发性。目前，任何超过400的东西都会开始获得缓慢的响应时间。响应大小通常很小，但少数可能相当大。请求的大小通常都很小，除了少数几个。

在负载过重之前，一切都是快速进行的。响应时间爬行到2到50秒之间的任何位置。在轻负载下，响应时间在100到300毫秒之间变化。

服务器设置为2台服务器。负载均衡器在前面，PHP-FPM，Nginx和MongoDB在两个盒子上。一台服务器运行主设备和仲裁器，另一台运行从设备(除非发生故障转移)。我知道Mongo的最佳实践，但我没有足够的服务器来拥有专用的数据库服务器。

仍然有相当多的ram空闲，并且最后1分钟的平均负载永远不会超过0.7。它们是8个核心盒，每个核心盒有16 be的内存，所以这不应该是瓶颈。Mongo一点都不冒汗，Nginx和PHP-FPM似乎也不是。我已经使用db.serverStatus()检查了top统计数据和MongoDB。

我的问题是，考虑到我的并发性，我的Nginx fastcgi设置看起来是否正确，还有什么是我可能遗漏的，即使它与Nginx设置没有任何关系？

fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;

较低的"ulimit -n“会减慢速度吗？在负载较重时，Mongo使用大约500到600个连接。Ulimit设置如下：

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 147456
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 147456
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

仅供参考，当对1200并发进行负载测试时，我将升级"ulimit -n“。

提前谢谢。

Answer 1

看起来只需要一点计算就可以了。因为我有8个可用的内核，所以我可以生成更多的nginx工作进程：

nginx.conf

worker_processes 4;
events {
    worker_connections 1024;
}

16 of的ram将为静态数量的php-fpm工作人员提供一些腿部空间。

php-fpm.conf

pm = static
pm.max_children = 4096

Nginx fastcgi设置保持不变。我可能有更多的调整要做，因为随着设置的改变，可接受的并发性保持不变，而服务器负载下降，但这似乎做到了技巧，至少是一个起点。

在负载变得相当高之前，单个服务器似乎可以处理大约2000个并发。ApacheBench开始收到大约500个并发的错误，因此使用AB的测试应该在多个服务器上完成。

正如David所说，理想情况下，这应该用更容易扩展的方式编写，但考虑到时间框架，在这一点上是不可行的。

我希望这对其他人有帮助。

Answer 2

MongoDB不是这里的瓶颈。如果你需要1200+并发连接，PHP-FPM (和一般的PHP )可能不是这个工作的工具。实际上，算了吧。这是，而不是合适的工具。许多基准测试断言，在200-500个并发连接之后，nginx/PHP-FPM开始动摇(参见here)。

去年我遇到了类似的情况，我没有尝试扩展不可伸缩性，而是使用Kilim (我也参与了一个项目)用Java语言重写了应用程序。另一个很好的选择是用Erlang编写它(这也是Facebook使用的)。我强烈建议您在这里重新评估您的语言选择，并在为时已晚之前进行重构。

假设你让PHP-FPM在1200个甚至1500个并发连接的情况下“正常”工作。2000年呢? 5000? 10000？绝对，毫无疑问，毫无疑问是不可能的。