我在AWS上运行旧的PHP（7.1）/ NGINX（1.10.2）应用程序。该应用程序在AWS上运行了几个月。从2天开始，我们遇到了高延迟问题。但它不会影响整个页面。只有＆＃34;密集＆＃34; PHP进程似乎在传递内容方面存在问题。
我现在查看了很多其他相关主题，但没有任何东西指向正确的方向。
首先：延迟与网络无关，因为我在从服务器向localhost发送请求时也会遇到这些延迟。它似乎也与数据库无关（网站能够连接到<3ms内的RDS DB，DB CPU~20％，无内存＆2GB看起来不错）。连接到数据库并运行网络服务器发出的一些查询也表现良好。
Web服务器本身不会消耗如此多的硬件资源（CPU 10-25％和内存可用~2GB）。此服务器上未安装任何cronjobs /计划任务。服务器上仍有超过50％的iNode可用。网络网关正在检索/传输8-25MB /秒。我们根本不监控任何类型的DoS。
我已经检查并尝试调整PHP FPM设置（memory_limit，进程管理，子进程等）。这里没有任何帮助。取消/激活OPCache确实没有影响。
即使我使用先前安装的AMI并启动新服务器，也会再次发生相同的延迟问题。在多个可用区域中运行应用程序时也会发生相同的情况。
要查看PHP花费时间的地方，我使用了blackfire.io，实际上它告诉我它大部分时间花在mysql交互上（这并不奇怪，因为应用程序发送了大量带有大量连接的脏查询等。这是唯一性能昂贵的东西......）。我还在代码本身添加了一些调试输出。它通常在不到6秒的时间内完成（遗憾的是我们从搜索中得知的正常平均值。）
根据目标群体的延迟平均为3-8秒，但我们也发现了请求超时（30-60秒）的许多延迟。
此时我甚至不确定这里要提供什么。我不想在这里粘贴每个相关的配置等。所以请告诉我你需要在这里提供什么帮助：/
php-fpm / nginx日志没有记录与此问题相关的任何内容。与syslog相同。唯一可以找到的是Timed out waiting for reply from 91.189.89.199:123 (ntp.ubuntu.com)，但是偶数date仍然是同步的.PHP FPM慢日志（超时设置为5秒。）也是空的。 ELB访问日志仅监视高级＆＃34; backend_processing_time＆＃34; s。
Nginx实际上将请求路由到S3存储桶，除了一个S3挂载之外，我们在服务器上没有任何大量的临时文件或其他内容。
发送到互联网的请求正在按预期执行。 DNS似乎也不是问题（可以照常在互联网上访问数据库和其他服务）。
有没有人有想法会导致这些延迟问题？还应该/ 可以调查什么？我非常感谢能够指出正确方向的每一个帮助或问题 最诚挚的问候。
答案 0 :(得分：0)
你自己说：
它告诉我它大部分时间花在mysql交互上（这并不奇怪，因为应用程序发送了很多带有很多连接等的脏查询，而且它是唯一性能上昂贵的东西......）。
这是你的申请。这会导致你的“管道”堵塞，所以有些人会经历30-60等待。现在我还要检查现在超时的任何file_get_contents，因为这是突然的。
此外，我遇到了类似before on serverfault的问题，我特别要指出my comment：
我不再为那家公司工作了，而且他们因为法律原因而被解雇了。但！当我离开时，我们的30秒加载站点降至3秒。而我们的linode CPU出现故障。解决方案完全是 - 缓存。我们框架的启动过程在性能方面是非常昂贵的，并且内部框架没有内置缓存。我只能说CACHE - 对象缓存，页面缓存，使用清漆！这将解决您的问题（但您仍然会有一个糟糕的框架，当您无法缓存时，您会感到难过......您必须修复性能不佳的代码。）
我希望这会对你有所帮助。哦this comment too：
当你去看医生，他告诉你服用某些药物 - 因为他知道你不会听“停止喝苏打水和吃快餐”的陈述 - 这正是为什么对我来说没有好的答案 - 因为事实是，没有真正应用的设置或快速修复 - 只有我们必须大幅改变我们的网络应用程序本身的可悲事实。
答案 1 :(得分：0)
机器人的组合，来自云服务器的一些陌生人请求仅请求我们的搜索（几个月），RDS Cpu信用以及平均实际上太多的SQL查询导致了这种现象。事实证明，针对t2媒体实例的Cloudwatch指标显示了2个核心中每个核心的CPU利用率（20％）的平均值（t2.medium的基线性能+有时更高的值30-80％）并且这一次不断地杀死所有cpu积分你失去了所有这些，然后很难获得新的学分（例如在夜间）。