如何使用 AWS EC2 减少 time_starttransfer (TTFB)
How to reduce the time_starttransfer (TTFB) with AWS EC2
我的网站在 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 以及服务器计算结果所需的时间。
我的网站配置
我的网站 link 是：http://13.37.46.163/
它是一个 Grav CMS 运行 EC2 + ServerPilot + PHP7
亚马逊机器映像 (AMI)
Ubuntu 服务器 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)
我的网站日志 (requests/min.)
1 00:02
1 00:38
1 00:54
1 01:06
1 01:12
1 01:23
1 03:49
1 04:32
1 04:57
6 05:15
1 05:17
1 05:31
1 05:37
1 06:08
1 06:32
1 07:30
1 07:38
1 07:55
1 08:31
1 10:07
1 10:35
1 10:52
1 10:59
1 12:53
1 13:00
1 14:18
1 14:28
1 14:29
1 14:48
1 16:05
1 18:40
1 19:20
1 20:24
1 20:30
即平均每分钟 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 命令检查什么是 运行ning / 什么正在使用资源，什么不需要？
这里是 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 - 稍微快一点，稍微便宜一点。(?)
首先：一般来说，除非您 运行 在 OS 上尚未打补丁以支持 T3，否则您应该更喜欢 T3 而不是 T2（尤其是 Linux - 我有在 Windows 上看到一些关于 T2 的一些小成本优势的讨论）。在我看来，价格的小幅下降是为了让你使用 T3 而不是 T2，这样他们最终就可以淘汰 T2。 T3 使用他们的 Nitro 实例风格，这通常更好（更快），尤其是在网络 IO 中，尽管我不希望您的测试产生影响。 （顺便说一句，如果你真的在寻找便宜的，我有幸买到价格更低的 T3A 实例）
其次：您使用的是T系列实例。来自 AWS：
T3 instances are the next generation burstable general-purpose instance type that provide a baseline level of CPU performance with the ability to burst CPU usage at any time for as long as required. T3 instances offer a balance of compute, memory, and network resources and are designed for applications with moderate CPU usage that experience temporary spikes in use.
这一切都很好，因为同一台物理机器上有很多用户。当然，对于许多其他家庭也是如此，但在这种情况下，您不是 'assigned' 可以使用的核心。您和许多其他人告诉 AWS，您的工作负载并没有那么高，您希望以仅偶尔使用 CPU 为代价获得更便宜的实例。这很好，但 AWS 正试图在这里赚钱，并没有为您的 T 实例提供专用的 CPU（同样，这是您告诉他们的选择）。在 return 中，CPU 可能无法在您希望的毫秒内可用，实例可能需要等待，直到请求的资源可用于物理实例。根据该实例上有多少其他人以及它的过度配置情况，您的结果可能会有所不同。
据我所知，AWS 不会发布任何关于 T 实例过度配置的信息。如果您怀疑您可能有健谈的邻居，您总是可以通过停止和启动实例来切换到不同的物理机器（您不需要终止实例）。这应该可以切换您 运行 正在使用的物理主机，但不能保证您会得到更好的机器。从本质上讲，您要求的是最便宜的 class 实例系列的最佳 class 性能。这可能不会达到您的期望。
简而言之，如果您想要最小的延迟和保证的速度，您将需要切换到不同的实例系列。如果您需要更多保证一致性和更低延迟性能，'generic' M5 实例类型系列可能更可取。
为了提高性能并减少 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 - 速度稍快且更便宜。
我的网站在 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 以及服务器计算结果所需的时间。
我的网站配置
我的网站 link 是：http://13.37.46.163/
它是一个 Grav CMS 运行 EC2 + ServerPilot + PHP7
亚马逊机器映像 (AMI)
Ubuntu 服务器 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)
我的网站日志 (requests/min.)
1 00:02
1 00:38
1 00:54
1 01:06
1 01:12
1 01:23
1 03:49
1 04:32
1 04:57
6 05:15
1 05:17
1 05:31
1 05:37
1 06:08
1 06:32
1 07:30
1 07:38
1 07:55
1 08:31
1 10:07
1 10:35
1 10:52
1 10:59
1 12:53
1 13:00
1 14:18
1 14:28
1 14:29
1 14:48
1 16:05
1 18:40
1 19:20
1 20:24
1 20:30
即平均每分钟 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命令检查什么是 运行ning / 什么正在使用资源，什么不需要？
这里是 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 - 稍微快一点，稍微便宜一点。(?)
首先：一般来说，除非您 运行 在 OS 上尚未打补丁以支持 T3，否则您应该更喜欢 T3 而不是 T2（尤其是 Linux - 我有在 Windows 上看到一些关于 T2 的一些小成本优势的讨论）。在我看来，价格的小幅下降是为了让你使用 T3 而不是 T2，这样他们最终就可以淘汰 T2。 T3 使用他们的 Nitro 实例风格，这通常更好（更快），尤其是在网络 IO 中，尽管我不希望您的测试产生影响。 （顺便说一句，如果你真的在寻找便宜的，我有幸买到价格更低的 T3A 实例）
其次：您使用的是T系列实例。来自 AWS：
T3 instances are the next generation burstable general-purpose instance type that provide a baseline level of CPU performance with the ability to burst CPU usage at any time for as long as required. T3 instances offer a balance of compute, memory, and network resources and are designed for applications with moderate CPU usage that experience temporary spikes in use.
这一切都很好，因为同一台物理机器上有很多用户。当然，对于许多其他家庭也是如此，但在这种情况下，您不是 'assigned' 可以使用的核心。您和许多其他人告诉 AWS，您的工作负载并没有那么高，您希望以仅偶尔使用 CPU 为代价获得更便宜的实例。这很好，但 AWS 正试图在这里赚钱，并没有为您的 T 实例提供专用的 CPU（同样，这是您告诉他们的选择）。在 return 中，CPU 可能无法在您希望的毫秒内可用，实例可能需要等待，直到请求的资源可用于物理实例。根据该实例上有多少其他人以及它的过度配置情况，您的结果可能会有所不同。
据我所知，AWS 不会发布任何关于 T 实例过度配置的信息。如果您怀疑您可能有健谈的邻居，您总是可以通过停止和启动实例来切换到不同的物理机器（您不需要终止实例）。这应该可以切换您 运行 正在使用的物理主机，但不能保证您会得到更好的机器。从本质上讲，您要求的是最便宜的 class 实例系列的最佳 class 性能。这可能不会达到您的期望。
简而言之，如果您想要最小的延迟和保证的速度，您将需要切换到不同的实例系列。如果您需要更多保证一致性和更低延迟性能，'generic' M5 实例类型系列可能更可取。
为了提高性能并减少 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 - 速度稍快且更便宜。