我正在寻找使用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”.

提前致谢.