我正在寻找使用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”.
提前致谢.
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进行测试应该从多个服务器完成.
正如大卫所说,理想情况下,这将写成可以更容易扩展的东西,但考虑到此时不可行的时间框架.
我希望这有助于其他人.
