基于php-fpm的应用服务器如何提升curl的处理能力
- 环境
- 16vCpu;32G (虚机)
- centos7.5
- nginx1.20
- php-fpm7.3
- 压力测试目标
- 1000qps 1秒响应
- php-fpm优化如下
- opcache enable
- pm: static
- pm.max_children: 32*1024/50≈650
- pm.max_requests: 10240
- rlimit_files: 65535
- request_terminate_timeout: 5
- linux内核已优化
- 系统句柄已优化(65535)
当前应用服务器主要实现调用(使用curl函数)内部服务重新组装数据提供出网接口,内部服务响应时间在50毫秒以内。
nginx的qps达到700左右之后,php-fpm active proacess为650,nginx的qps小于active connect,出网的接口响应为2-3秒,此时cpu的使用率为50%左右,内存使用了25%左右。
将php-fpm的tcp的方式改成socket方式,性能没有明显提升。
增加php-fpm的进程数750,nginx的qps控制在700左右,出网接口响应时间仍然为2-3秒,甚至有5秒的。
应用服务器安装多个版本的php,使用upstream负载多个端口,php-fpm进程总个数为1200,cpu使用率为70%左右,内存使用了30%左右,出网接口性能没有明显改善。
额外增加一台服务器,使用两台进行负载,每台都开启500个php-fpm进行,出网接口响应时长在1秒之内。
猜测:一台服务器达到瓶颈后,即使增加cpu和内存也无效,将一台16核CPU+32G内存虚机拆成两台8核CPU+16G内存的虚拟机性能会更好
不考虑多台服务器负载,如何提高单台服务器的处理能力,望社区里的大神指导一二,如果能说明瓶颈点的原理就更好了,发点相关资料也可以。
补充说明:
此次优化是对旧业务系统的优化,新技术的改造短时间内是无法实施的,至于为何要用php来中转接口是历史遗留问题了,短时间内可能是无法采用其他技术实现网关的。正在准备增加新的虚拟机,不过单台的性能还应该继续努力下。。。
– 2021.11.25 –
之前服务器里安装了性能监控(tideways+xhgui),将其屏蔽后重新测试,qps达到950之后才出现异常(应该是压力测试机达到瓶颈了),后续准备增加压力测试机或者是云平台的压力测试服务。
未完待续。。。
推荐文章: