在AWS上突然变慢的PHP应用程序
我在AWS上运行一个旧的PHP（7.1）/ NGINX（1.10.2）应用程序。该应用程序在AWS上运行超过几个月。自2天以来，我们遇到了高延迟问题。但它不会影响整个页面。只有“密集型”PHP流程似乎在交付内容方面存在问题。在AWS上突然变慢的PHP应用程序
现在我查了很多其他相关的主题，但没有任何东西指向正确的方向。
首先：等待时间与网络无关，因为当从服务器向本地主机发送请求时，也会收到这些等待时间。它似乎也与数据库无关（该网站可以在< 3ms内连接到RDS DB，而DB CPU〜20％，内存自由> 2GB看起来不错）。连接到数据库并运行网络服务器进行的一些查询也表现良好。
网络服务器本身不占用太多的硬件资源（CPU 10-25％和内存空闲〜2GB）。此服务器上未安装任何cronjobs /计划任务。服务器上仍有超过50％的iNodes可用。网关正在检索/传输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访问日志只监视高“backend_processing_time”。
Nginx实际上将请求路由到S3存储区，除了一个S3挂载之外，我们没有任何大量临时文件或服务器上的其他东西。
发送到互联网的请求按预期执行。 DNS似乎也不是问题（像平常一样可以在互联网上访问数据库和其他服务）。
有没有人有想法可能会导致这些延迟问题？还应该调查哪些/ ？我非常感谢每一个帮助或问题，这些都可以让我指出正确的方向。
最好的问候。
你自己说的：
它告诉我，它花费大部分时间在MySQL交互（如应用程序发送了很多肮脏的查询了很多联接等，以及其这并不奇怪这里唯一性能昂贵的东西..）。
这是你的应用程序。这会导致你的“管道”堵塞，所以有些人会经历30-60等待。现在我还要检查现在是否超时的任何file_get_contents，因为这是突然的。
另外，我有一个问题是这样before on serverfault，我特别想指出的my comment：
我并不为这家公司工作了，他们在去 - 出于法律原因。但！当我离开时，我们的30秒负载站点降至3秒。我们的linode CPU出现故障。该解决方案完全是 - 缓存。我们框架的初始化过程在性能方面是非常昂贵的，而且内部框架没有内置缓存。我只能说CACHE - 对象缓存，页面缓存，使用清漆！这将解决你的问题（但你仍然会有一个糟糕的框架，当你无法缓存，你会伤心..你必须修复性能不佳的代码）。
我希望这可以帮助你。哦也this comment too：
当你去看医生，他告诉你采取一定吃药 - 因为他知道你不会听“停止饮用苏打水和吃快餐”的语句 - 这就是为什么有对我来说没有很好的答案 - 因为事实是，没有设置或快速修复真正应用 - 只有我们必须大幅度改变我们的网络应用程序本身的可悲事实。
感谢您关于file_get_contents的提示我会研究这一点。当然，它显然可能是应用程序。但是在过去3天内没有任何变化（没有流量增加，没有数据库中的索引变化等）。所以如果它从3-8秒下降到30或甚至60，我会非常惊讶，因为它是一个糟糕的遗产应用程序.. – Tim
一旦我们因共享平台链接上的file_get_contents而发生该问题。当然，我们在它前面有一个@符号。只是一个想法。另一个是 - 你是否被抓取？比你习惯的更重用法（什么语句！）可能会触发设计不佳的应用程序阻塞。 – amurrell
试着弄清楚这30-60秒是否确切，可能与实际的超时配置一致。并根据什么网址/请求发生。 – amurrell
机器人的组合，来自云服务器的一些请求我们搜索（几个月以来），RDS Cpu信用和平均真正太多的SQL查询的一些陌生人请求引起了这种现象。结果发现，t2中型实例的Cloudwatch指标显示了2个核心（t2.medium的基准性能+有时更高的值30-80％）的CPU利用率平均值（20％），并且这会持续不断地杀死所有cpu信用你失去了他们全部，然后很难获得新的学分（例如在夜间）。
你使用T2 EC2实例吗？ –
是的，通常很小，但我随机也尝试了一种媒介。 – Tim
您需要设置一些基本的操作系统监控，以关注CPU，内存和IO等事情，以便您可以了解服务器上正在发生的事情。如果你对性能的唯一可见性是“应用程序很慢”，那么你将会有一段非常艰难的时间来确定问题实际上是什么。 – Sammitch