我有一个t2.nano
实例在北弗吉尼亚可用区 ( us-east-1
) 运行了将近 1 年。
为了减少延迟,我刚刚将该实例创建的 AMI 部署到t3.micro
新加坡 ( ) 区域的实例。实例的 Apache 服务器附加了ap-southeast-1
一个 RDS (AZ: )。us-east-1
但是,t3.micro
新加坡的响应速度比旧的t2.nano
(美国北弗吉尼亚州)慢得多,而旧的响应距离是新加坡的 4 倍多(孟加拉国达卡)。
作为缓慢的证据,Google 的 Pagespeed网站将新旧服务器的排名分别为 100 和 71,而平多姆将 2 个服务器分别排名为 100 和 81 >矩阵这两个网站的排名分别为 100 和 79。GTmetrix 对这两个网站的比较截图如下:
编辑:
这些排名是使用不平衡的请求错误生成的,但以下屏幕截图现在显示实例的等待时间确实很长t3.micro
:
该服务器托管了许多其他 REST API(使用Laravel
框架开发,用于 Web 前端和移动应用程序),所有这些都反映了长时间的延迟。
我没有在这个系统中使用任何配置,并且所有其他配置(安全组、AMI、IAM、RDS、S3 等)对于两个实例来说都是完全相同的。
我知道 RDS 连接可能会出现几毫秒的延迟(并且可能由于任何缓存而出现一些延迟?),但平均超过 10 秒的延迟让人难以忍受。
什么原因会导致这种差异?应该做些什么来避免这种情况?
答案1
这两个实例所服务的页面是不一样。
总页面大小为大 150 倍(386kB vs 2.8kB),请求数量为8 倍以上(17 比 2)。
首先对齐两个设置这样它们就以相同的方式为您的页面提供服务,然后我们就可以查看实际的实例性能。
另外,将数据库放在不同的区域也无济于事——典型的网站可能会进行相当多的数据库查询,如果每个查询增加半秒左右的延迟,那么它很快就会累积起来。
最后,T2 和 T3 实例使用所谓的CPU 积分- 一旦耗尽,性能就会迅速下降。可能是您在安装某些软件或以其他方式用完信用后立即进行了性能测试。在这种情况下,性能会非常差。给它一些时间来积累更多信用并重试。
希望有帮助:)