加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 运营中心 > Nginx > 正文

扩展Nginx,PHP-FPM和MongoDB

发布时间:2020-12-13 21:05:36 所属栏目:Nginx 来源:网络整理
导读:我正在寻找使用PHP-FPM在Nginx下扩展PHP应用程序的最佳方法.我正在考虑大约1200的并发性.目前,超过400的任何一个开始得到缓慢的响应时间.响应大小通常很小,但有些可能相当大.请求大小通常很小,除了少数几个. 事情快速发展,直到负担沉重.响应时间可以爬到2到5

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

提前致谢.

最佳答案
似乎只需要一点点计算.由于我有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进行测试应该从多个服务器完成.

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

我希望这有助于其他人.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读