基于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之后才出现异常（应该是压力测试机达到瓶颈了），后续准备增加压力测试机或者是云平台的压力测试服务。

未完待续。。。