php - 如何使用 AWS EC2 减少 time_starttransfer (TTFB)

Question

我的网站在 AWS EC2 上。

我用这个命令检查了 TTFB（到第一个字节的时间）：

curl --output /dev/null --silent --write-out "time_namelookup=%{time_namelookup}\ntime_connect=%{time_connect}\ntime_appconnect=%{time_appconnect}\ntime_pretransfer=%{time_pretransfer}\ntime_redirect=%{time_redirect}\ntime_starttransfer=%{time_starttransfer}\ntime_total=%{time_total}\n" --url http://13.37.46.163/

这是我在计算机上运行命令时的结果：

time_connect=0,014614
time_appconnect=0,000000
time_pretransfer=0,014657
time_redirect=0,000000
time_starttransfer=0,119092
time_total=0,134436

这是我在网络服务器本身上运行命令时的结果：

time_namelookup=0.000058
time_connect=0.001296
time_appconnect=0.000000
time_pretransfer=0.001336
time_redirect=0.000000
time_starttransfer=0.084576
time_total=0.085031

我注意到在这两种情况下，最长的时间都是 time_starttransfer。我怎样才能减少这个时间？

什么是 time_starttransfer？

从开始到第一个字节即将被传输所用的时间（以秒为单位）。这包括 time_pretransfer 以及服务器计算结果所需的时间。

我的网站配置

我的网站链接是：http: //13.37.46.163/

这是一个使用EC2 + ServerPilot + PHP7运行的 Grav CMS女巫

Amazon 系统映像 (AMI)
Ubuntu Server 20.04 LTS (HVM)，EBS 通用 (SSD) 卷类型。64 位 (x86)

EC2 实例类型
t2.micro

网络服务器
Nginx

编程语言
PHP

反向代理
Nginx

缓存
我已经使用了已启用的Opcache，您可以在此处看到：http: //13.37.46.163/info.php#module_zend+opcache

关于CDN，我已经使用 Grav CDN 插件。( https://github.com/getgrav/grav-plugin-cdn )

我的网站日志（请求/分钟）

即，平均 1 个请求/分钟

进行的测试

尝试对 Php 不托管的静态文件运行 TTFB 测试

我对“main.js”文件进行了 TTFB 测试。

结果如下：

time_namelookup=0.000034
time_connect=0.002659
time_appconnect=0.000000
time_pretransfer=0.002702
time_redirect=0.000000
time_starttransfer=0.003983
time_total=0.004026

结果分析：
结果令人满意（time_starttransfer=0.003983）。但我认为这个结果是由于文件的重量与整个网站相比很轻。我们可以推断出问题在于 PHP 而不是 NGINX。

运行top和free命令以检查正在运行的内容/正在使用的资源，我不需要什么？

这是top命令的结果：

+-----------+--------------+-------------+-------------+------------------+---------+---------+---------+--------+
| %Cpu(s):  | 4.0 us,      | 0.3 sy,     | 0.0 ni,     | 95.7 id,         | 0.0 wa, | 0.0 hi, | 0.0 si, | 0.0 st |
+-----------+--------------+-------------+-------------+------------------+---------+---------+---------+--------+
| MiB Mem : | 978.6 total, | 75.8 free,  | 332.2 used, | 570.6 buff/cache |         |         |         |        |
+-----------+--------------+-------------+-------------+------------------+---------+---------+---------+--------+
| MiB Swap: | 512.0 total, | 427.2 free, | 84.8 used.  | 461.7 avail Mem  |         |         |         |        |
+-----------+--------------+-------------+-------------+------------------+---------+---------+---------+--------+

当我重新加载我的网站以检查 CPU 百分比时，我得到了结果。

这是free命令的结果：

+-------+---------+--------+--------+--------+------------+-----------+
|       | total   | used   | free   | shared | buff/cache | available |
+-------+---------+--------+--------+--------+------------+-----------+
| Mem:  | 1002052 | 334392 | 83368  | 16940  | 584292     | 478628    |
+-------+---------+--------+--------+--------+------------+-----------+
| Swap: | 524284  | 86784  | 437500 |        |            |           |
+-------+---------+--------+--------+--------+------------+-----------+

结果分析：
我可能不应该使用t3.micro-t2.micro稍微快一点，稍微便宜一点。（？）

score 0 · Accepted Answer

为了提高性能并降低 TTFB，我进行了以下改进：

1 - PHP 缓存很关键

您应该运行 PHP opcache 和 usercache（例如 APCu）以获得最佳性能。

2 - SSD 驱动器

SSD 驱动器可以带来很大的不同。大多数内容都可以缓存在 PHP 用户缓存中，但有些内容作为文件存储，因此 SSD 驱动器会对性能产生很大影响。避免使用网络文件系统，例如 NFS。

3 - 清理 CSS

UnCSS 在这里尤为重要。该工具检查一组文件中所有使用的 CSS 选择器，并删除所有未使用的选择器。您可能认为这听起来容易出错且没有必要，但巧妙地使用它是对 CSS 文件的最有效缩减。

4 - 优化服务器

我托管的服务器也支持 Gzip 压缩，我设置了 Expires-headers 以避免浏览器不必要地加载文件。

5 - 使用 CDN

CloudFront、CloudFlare 或 MaxCDN 等 CDN 可用于将数据缓存到更靠近用户的位置。（内容交付网络）可以从源检索非缓存内容。

使用 CDN 可以将资产交付时间从 30 秒减少到 3 秒。

对于 Cloudfront 用户：不要犹豫，配置 CDN 以缓存您的动态内容 https://www.youtube.com/watch?v=tqoDBNWBwas&t=2s

6 - 选择好的实例系列 （适用于 AWS 用户）

对于非常小的网站，您应该更喜欢 t3.micro 而不是 t2.micro - 速度更快且更便宜。

score 0 · Accepted Answer

第一：一般来说，除非您在未打补丁以支持 T3 的操作系统上运行，否则您应该更喜欢 T3 而不是 T2（尤其是在 Linux 上——我已经看到一些关于 T2 在 Windows 上的一些次要成本优势的讨论）。在我看来，价格的小幅下调是为了让你使用 T3 而不是 T2，以便他们最终可以淘汰 T2。T3 使用他们的 Nitro 实例风格，通常更好（更快），尤其是在网络 IO 中，尽管我不希望你的测试会产生影响。（顺便说一句，如果您真的在寻找便宜的东西，那么价格更低的 T3A 实例我已经很幸运了）

第二：您正在使用 T 系列实例。来自 AWS：

T3 实例是下一代可突增通用实例类型，可提供基准级别的 CPU 性能，并能够根据需要随时突增 CPU 使用率。T3 实例提供了计算、内存和网络资源的平衡，专为 CPU 使用率适中但在使用中遇到临时高峰的应用程序而设计。

这一切都很好，因为在同一台物理机器上有很多用户。当然，对于许多其他家庭来说也是如此，但在这种情况下，您并没有被“分配”一个要使用的核心。您和许多其他人都告诉 AWS，您的工作负载并没有那么高，您希望以仅偶尔使用 CPU 为代价获得更便宜的实例。这很好，但 AWS 试图在这里赚钱，并没有为您的 T 实例提供专用 CPU（同样，这是您告诉他们的选择）。作为回报，CPU 可能无法在您希望的毫秒内可用，并且实例可能需要等待，直到请求的资源可用于物理实例。根据该实例上有多少其他人以及它的过度配置程度，您的结果可能会有所不同。

据我所知，AWS 没有发布任何关于 T 实例过度配置的信息。如果您怀疑您可能有闲聊的邻居，您总是可以通过停止和启动实例来切换到不同的物理机器（您不需要终止实例）。这应该会切换您正在运行的物理主机，但不能保证您会获得更好的机器。从本质上讲，您要求从最便宜的实例系列中获得一流的性能。这可能不会达到您的期望。

简而言之，如果您想要最小延迟和保证速度，您将需要切换到不同的实例系列。如果您需要更多关于一致和更低延迟性能的保证，M5 的“通用”实例类型系列可能更可取。

php - 如何使用 AWS EC2 减少 time_starttransfer (TTFB)

什么是 time_starttransfer？

我的网站配置

我的网站日志（请求/分钟）

进行的测试

2 回答 2

Related

Reference