问题描述
我的网站在 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/
这是一个 Grav CMS 使用 EC2 + ServerPilot + PHP7
运行的女巫亚马逊机器映像 (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 Plugin。 (https://github.com/getgrav/grav-plugin-cdn)
我的网站日志（请求/分钟）
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 个请求
已执行的测试
我对“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 | | | | |
+-----------+--------------+-------------+-------------+------------------+---------+---------+---------+--------+
这里是 free 命令的结果：
+-------+---------+--------+--------+--------+------------+-----------+
| | total | used | free | shared | buff/cache | available |
+-------+---------+--------+--------+--------+------------+-----------+
| Mem: | 1002052 | 334392 | 83368 | 16940 | 584292 | 478628 |
+-------+---------+--------+--------+--------+------------+-----------+
| Swap: | 524284 | 86784 | 437500 | | | |
+-------+---------+--------+--------+--------+------------+-----------+
结果分析：
我也许应该使用 t3.micro 而不是 t2.micro - 稍微快一点，便宜一点。(?)
解决方法
首先：一般来说，除非您在尚未打补丁以支持 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 的“通用”实例类型系列。