☰

相同配置下，Google Cloud 上的 TTFB 比 AWS 上更长

tag-icon • tag-icon nginx amazon-web-services performance ubuntu-14.04 google-cloud-platform
相同配置下，Google Cloud 上的 TTFB 比 AWS 上更长

长的时间潜水员，首次在 StackExchange 网络上发帖。

这几天我一直在为此绞尽脑汁，看了很多帖子，也尝试了很多方法，但毫无进展。情况如下：

我在 Ubuntu 14.04 上安装了免费版 EC2 机箱作为临时机器，并安装了 LEMP，具体来说是 Nginx 和 PHP7 以及 WordPress。我们已经建立了网站，一切运行正常。它的 TTFB 为 505 毫秒。

我设置了一个免费级别的云计算盒作为具有相同配置的生产机器，但 TTFB 为 14 秒。请注意，Google 盒子上的规格比 EC2 上的规格略好。g1-small（1 vCPU，1.7 GB 内存）与 t2-micro（1 vCPU，1 GB 内存）。两侧均配备 SSD。

我尝试了很多方法，包括这个答案中提到的诊断 TTFB 问题的许多方法https://serverfault.com/a/350422。我还尝试增加 PHP 和 WordPress 的内存。我尝试安装人们建议的用于性能优化的软件包和插件。我特别纠结于这样一个事实：我的暂存实例不需要这些。在你问“你为什么不在 AWS 上完成所有操作”之前，要知道使用 Google Cloud Compute 进行生产是这个项目的必要条件。

在我与他人的讨论中，有人说 Google Cloud 在响应完成之前没有输出刷新来提供内容。有人可以证实吗？

在此先感谢您提供的任何见解，为我指明解决此问题的正确方向。此外，请告诉我我可以提供的其他详细信息，以便更轻松地解决此问题。

編輯一：回答以下问题。非常感谢您提供帮助。

两台服务器是否位于同一地理位置？差异有多大？

EC2 实例位于美国东部或弗吉尼亚州。GCE 实例位于 US-West1a，我相信它位于俄勒冈州。我位于纽约市，因此地理位置差异不足以证明 14 秒的 TTFB 是合理的。此外，我使用的工具具有达拉斯等地理位置（两个城市之间的合理中点），并且也报告了 14 秒的 TTFB。

首先要弄清楚延迟在哪里。请编辑您的问题以包括 Google 网站的 curl、匹配的 Nginx 访问日志条目、任何匹配的 Nginx 错误日志条目以及 PHP 访问/错误日志。需要启用 PHP 访问日志。同时在 curl 发生时观察“top”，并截取代表性屏幕截图。最后，请分享两种环境的 Webpagetest.org 测试以演示问题，如果您的域名是秘密的，则进行模糊处理 - 网络爬虫无论如何都会找到所有域名。– Tim 3 小时前

  • 卷曲

    time_namelookup：0.000n
    time_connect：0.078n
    time_appconnect：0.000n
    time_pretransfer：0.078n
    time_redirect：0.000n
    time_starttransfer：13.469n
    time_total：13.469n

我没有足够的声誉点来发布图像或另一个图像的链接，但是当我运行 top 时，php-fpm7.0 和 mysqld 会弹出。

PID 用户 PR NI VIRT RES SHR S %CPU %MEM 时间+命令 24625 www-data 20 0 374680 43352 30376 S 0.7 2.5 0：00.90 php-fpm7.0 21244 mysql 20 0 870388 71088 11012 S 0.3 4.1 0：10.57 mysqld

  • Nginx 访问日志条目

    [2017 年 5 月 7 日：06：01：58 +0000] “GET / HTTP/1.1” 200 58528 “-” “curl/7.35.0”

  • Nginx 错误日志条目

这个请求没什么新意

  • PHP 访问日志条目

PHP-FPM 日志中没有任何内容。

  • PHP 错误日志条目

这个请求没有任何结果，但是我在此之前确实做了一个浏览器请求，以下是慢速日志中的内容（我将窗口设置为 5 秒）：

[07-May-2017 06:01:48]  [pool www] pid 24625
script_filename = /var/www/html/wordpress/index.php
[0x00007fad55e12810] mysqli_real_connect() /var/www/html/wordpress/wp-
includes/wp-db.php:1540
[0x00007fad55e126f0] db_connect() /var/www/html/wordpress/wp-includes/wp-db.php:658
[0x00007fad55e12620] __construct() /var/www/html/wordpress/wp-content/themes/xxxx/inc/artist-products.php:7
[0x00007fad55e12590] edb_db_init() /var/www/html/wordpress/wp-content/themes/xxxx/inc/db/items.php:258
[0x00007fad55e124d0] edb_get_product_link() /var/www/html/wordpress/wp-content/themes/xxxx/inc/artist-products.php:23
[0x00007fad55e123c0] edb_display_frontpage_items() /var/www/html/wordpress/wp-content/themes/xxxx/page-templates/home.php:95
[0x00007fad55e121e0] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/wp-includes/template-loader.php:74
[0x00007fad55e12140] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/wp-blog-header.php:19
[0x00007fad55e120a0] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/index.php:17
  • EC2 时间线

https://www.screencast.com/t/vxHTCcyf

  • GCE 时间表

https://www.screencast.com/t/22OXgA7T

最明显的尝试方法是编写一个基本的 hello world php 脚本并测量其 ttfb（如果还没有）。如果它接近 14 秒，那么您遇到的问题与 wordpress 或数据库无关。“Google Cloud 没有输出刷新”适用于 Google App Engine HTTP 响应，这些响应是整体返回的——因此这不适用于计算实例。

是的，我做过这个。Hello World 和其他静态文件响应很快。PHPInfo 也响应很快。如果我没记错的话，所有简单和静态文件的 TTFB 时间都在 700 毫秒左右。感谢您澄清输出刷新仅与 App Engine 相关。至少我知道是我所缺少的一个简单解决方案。

我所看到的唯一能给我提供一些帮助的东西就是 PHP 慢速日志记录。

[07-May-2017 00:56:39]  [pool www] pid 24793
script_filename = /var/www/html/wordpress/index.php
[0x00007fad55e14810] mysqli_real_connect() /var/www/html/wordpress/wp-includes/wp-db.php:1540
[0x00007fad55e146f0] db_connect() /var/www/html/wordpress/wp-includes/wp-db.php:658
[0x00007fad55e14620] __construct() /var/www/html/wordpress/wp-content/themes/xxxx/inc/artist-products.php:7
[0x00007fad55e14590] edb_db_init() /var/www/html/wordpress/wp-content/themes/xxxx/inc/db/items.php:258
[0x00007fad55e144d0] edb_get_product_link() /var/www/html/wordpress/wp-content/themes/xxxx/inc/artist-products$
[0x00007fad55e143c0] edb_display_frontpage_items() /var/www/html/wordpress/wp-content/themes/xxxx/page-templat$
[0x00007fad55e141e0] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/wp-includes/template-loader.php:74
[0x00007fad55e14140] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/wp-blog-header.php:19
[0x00007fad55e140a0] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/index.php:1

这让我认为数据库查询很慢，但我安装了 WP 的查询监控插件，并且所有查询都显示执行速度很快。

答案1

造成延迟的最可能原因是 AWS 和 GCP 之间的底层基础设施差异——在云世界中，规格表并不总是能真实反映实际性能，如果您想对性能进行基准测试，使用最便宜的实例类型从来都不是一个好主意。

GCP 中几乎每个性能角度都与 CPU 数量相关 - 例如每个 CPU 核心 2Gb 网络。此外，在 Google Cloud 上g1-micro，共享核心机器。来自链接：

共享核心机器类型提供一个虚拟 CPU，该虚拟 CPU 可以在运行实例的主机 CPU 上的单个硬件超线程上部分时间运行。

在 AWS 上，at2.micro被归类为可爆破- 从表面上看，它与 Google 的共享核心模型类似，但有细微的差别：

T2 实例的基准性能和突发性能由 CPU 积分决定。每个 T2 实例都会持续获得 CPU 积分，其速率取决于实例大小。T2 实例在空闲时会累积 CPU 积分，在活动时会使用 CPU 积分。一个 CPU 积分可提供一分钟内完整 CPU 核心的性能。

为了进行真正的同类比较，我强烈建议双方使用性能更高的实例类型来保证资源可用性，例如亚马逊m3.medium和谷歌n1-standard-1- 都提供 1 个 CPU 和 3.75GB RAM。

为了从可能的罪魁祸首列表中删除地理位置，我还会将您的 AWS 实例定位在 us-west-2，它也位于俄勒冈州 - 它可能离您的位置较远，但至少您将测试两个距离相似的实例，而不是一个近一个远。

我还会尝试多次重新创建实例，以防止“吵闹的邻居”和硬件怪癖 - 如果您使用配置管理（如果您在云中运行，您应该这样做）这应该是小菜一碟。

相关内容