php 应用程序在 AWS 上突然变慢答案

【问题标题】：php application suddenly slow on AWSphp 应用程序在 AWS 上突然变慢
【发布时间】：2018-04-01 01:52:06
【问题描述】：

我在 AWS 上运行旧的 PHP (7.1) / NGINX (1.10.2) 应用程序。该应用程序在 AWS 上运行了几个月。自 2 天以来，我们遇到了高延迟问题。但它不会影响整个页面。只有“密集”的 PHP 进程似乎在交付内容时存在问题。

我现在查找了许多其他相关主题，但没有任何内容可以为我指明正确的方向。

首先：延迟与网络无关，因为我在从服务器向本地主机发送请求时也会遇到这些延迟。它似乎也与数据库无关（该网站能够在 2GB 看起来不错）。连接到数据库并运行网络服务器进行的一些查询也可以正常运行。

Webserver 本身不会消耗太多硬件资源（CPU 10-25% 和可用内存约 2GB）。此服务器上未安装任何 cronjobs/计划任务。服务器上仍有超过 50% 的 iNode 可用。网络网关正在检索/传输 8-25MB/秒。我们根本不监控任何类型的 DoS。

我已经检查并尝试调整 PHP FPM 设置（内存限制、进程管理、子进程等）。这里没有任何帮助。停用/激活 OPCache 并没有真正的影响。

即使我使用以前安装的 AMI 并启动新服务器，同样的延迟问题也会再次发生。在多个可用区中运行应用程序时也会发生同样的情况。

要查看 PHP 将时间花在哪里，我使用了 blackfire.io，实际上它告诉我它大部分时间都花在了 mysql 交互上（这并不奇怪，因为应用程序发送了大量带有大量连接的脏查询等。它是这里唯一性能昂贵的东西..)。我还向代码本身添加了一些调试输出。它通常在不到 6 秒的时间内完成（遗憾的是，这是我们从搜索中得知的正常平均值..）

根据目标群体，延迟平均在 3-8 秒之间，但我们也发现请求超时（30-60 秒）的延迟很多。

在这一点上，我什至不确定在这里提供什么。我不想在这里粘贴所有相关的配置等。所以请告诉我你需要在这里提供什么帮助：/

php-fpm/nginx 日志不会记录与此问题相关的任何内容。与系统日志相同。唯一可以找到的是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 似乎也不是问题（可以像往常一样访问互联网中的 db 和其他服务）。

有没有人知道什么会导致这些延迟问题？还有什么应该/可以调查？我非常感谢每一个可以为我指明正确方向的帮助或问题。
最好的问候。

【问题讨论】：

您使用的是 T2 EC2 实例吗？
是的，通常很小，但我也随机尝试了中号..
您需要设置一些基本的操作系统监控以密切关注 CPU、内存和 IO 等内容，以便您对服务器上发生的事情有一定的了解。如果您对性能的唯一了解是“应用程序很慢”，那么您将很难弄清楚问题到底出在哪里。
AWS 为您提供了这一点，我的问题中列出了详细信息
如果您使用的是 T2 实例，那么它们可能会耗尽 CPU 积分。您需要在 CloudWatch 中检查这些实例的 CPU 信用指标。

标签： php amazon-web-services nginx latency

【解决方案1】：

你自己说的：

它告诉我它大部分时间都花在了 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 秒，我会感到非常惊讶，因为它只是一个糟糕的遗产应用程序..
我们曾经因为共享平台链接上的 file_get_contents 而遇到这个问题。当然，我们前面有一个@符号。只是一个想法。另一个是 - 你被爬了吗？比你习惯的使用量大（多么好的一句话！）可能会因设计不佳的应用而引发阻塞。
尝试确定 30-60 秒是否准确，可能与实际超时配置一致。以及发生了什么网址/请求。
服务器上的请求计数和 CPU 使用率始终保持不变（包括延迟开始之前的时间）。延迟总是不同的，平均而言甚至没有那么高..但仍然高于通常+> 30s延迟。它导致具有不同内容的多个站点的工作速度大大降低，即使真正的执行不需要那么长时间.. :( 所以实际上很难说

【解决方案2】：

TL;DR 在撰写本文时，我并没有真正意识到 RDS 也有 CPU 积分这一事实

机器人的组合、来自云服务器的一些陌生人请求仅请求我们的搜索（几个月以来）、RDS Cpu 积分以及平均而言确实太多的 sql 查询导致了这种现象。结果表明，t2 中型实例的 Cloudwatch 指标显示了 2 个内核中每个内核的 CPU 利用率平均值 (20%)（t2.medium 的基线性能 + 有时更高的值 30-80%），这会不断杀死所有 CPU 积分一次你失去了它们，然后很难获得新的积分（例如在晚上）。

【讨论】：