Question

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

在重负荷之前，情况快速发展。响应时间可以爬到2到50秒之间。在轻负载下，响应时间在100到300毫秒之间变化。

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

仍有相当多的ram免费，最后1分钟的平均负载永远不会超过0.7。它们是8个核心盒子，每个都有16个ram，所以这不应该成为瓶颈。 Mongo根本没有出汗，Nginx和PHP-FPM似乎也不是。我使用db.serverStatus（）检查了顶级统计信息和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;
}

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

PHP-fpm.conf

pm = static
pm.max_children = 4096

Nginx fastcgi设置保持不变。我可能有更多的调整todo，因为设置已更改，可接受的并发性保持不变，而服务器负载下降，但这似乎是诀窍，至少是一个起点。

单个服务器似乎在负载变得非常高之前处理大约2000个并发。 ApacheBench开始获得大约500并发的错误，因此使用AB进行测试应该从多个服务器完成。

正如大卫所说，理想情况下，这可以写成可以更容易扩展的东西，但考虑到此时不可行的时间框架。

我希望这有助于其他人。

Answer 2

MongoDB不是这里的瓶颈。如果您需要1200多个并发连接，PHP-FPM（以及一般的PHP）可能不是该工作的工具。实际上，划伤那个。它是 NOT 适合工作的正确工具。许多基准测试断言，在200-500个并发连接之后，nginx / PHP-FPM开始动摇（参见here）。

我去年处于类似情况，而不是尝试扩展不可扩展的，我使用Kilim（我也参与的项目）在Java中重写了应用程序。另一个很好的选择是在Erlang（这是Facebook使用的）中写它。我强烈建议你在这里重新评估你的语言选择，然后再进行重构。

假设你让PHP-FPM工作“好”，1200甚至1500个并发连接。 2000年怎么样？ 5000？ 10000？绝对，毫无疑问，无可置疑。

扩展Nginx，PHP-FPM和MongoDB

2 个答案: