时间到第一个字节先生的奇怪情况

我有一个基于Linode 1024 VPS的Web服务器，基于

• Ubuntu 11.10
• Nginx 1.0.5
• PHP 5.3.6（带有PHP-FPM，APC）
• 清漆3.0.2

还有一些基于WordPress 3.3.1的博客。其中之一是纯博客，具有默认配置，主题和仅“ Hello World”帖子，用于测试服务器。另一个是从其他服务器克隆的博客，其中包含近1万个帖子和超过1万条评论。该博客每天有5k唯一身份。

服务器在测试博客的ab测试中给出了很好的数字，但是对克隆的博客进行相同的测试是不可能的：ab测试会使服务器负载过多，并且我必须停止该过程，无论如何这会使ab显示出来这个结果真差。

在正常操作时，仪表板还显示“正常”负载，但是在ab测试期间，正常显示较大负载。

还有另外一件奇怪的事情发生（对我来说最重要）：到第一个字节的时间非常长，但是之后等待该站点的速度非常快。可以使用tools.pingdom.com之类的服务轻松对其进行测试，从而得出此结果。请注意表示“等待时间”的黄色区域。

为什么会这样呢？可能的想法：

• 错误的PHP-FPM配置
• Linode DNS响应时间太长了。废话-测试博客解决DNS问题，TTFB很棒
• 错误的Nginx配置

如果有人需要更多信息，

• 在这里，您具有当前克隆的博客nginx配置文件 （/etc/nginx/sites-available/muycomputerpro.com）
• 在这里，你已经得到了当前的my.cnf配置（/etc/mysql/my.cnf）（我知道，暂时不缓存，这不会对过去的TTFB差异）
• 在这里，您具有当前的PHP-FPM配置（/etc/php5/fpm/pool.d/www.conf）

首先，这不是答案，而是诊断方法。

这绝不是全面的-甚至是接近的内容，这只是一个起点。

到第一个字节的时间

到第一个字节的时间（TTFB）有很多组成部分：

• DNS查找：查找域的IP地址（可能的改进：更多/分布式/响应DNS服务器）
• 连接时间：打开服务器的套接字，协商连接（典型值应在“ ping”时间附近-通常需要往返行程-keepalive应有助于后续请求）
• 等待中：发送第一个字节之前需要进行初始处理（这是您应进行的改进-这对动态内容而言最为重要。

当查看ApacheBench输出时，您还会看到：

• 处理：这是等待+内容的完全传输的总和（如果传输时间明显长于下载接收到的数据量的预期时间，则会进行进一步处理（在接收到第一个字节之后）（例如，页面刷新内容（如果可用）

比较以消除组件

除了少数例外，您的问题将出在后端处理上，这通常归因于过于复杂/低效的代码或配置不当的MySQL。

解决此问题的一种好方法是进行一系列比较，以消除设置的各个方面。良好的比较应保持尽可能恒定，以帮助缩小问题范围。当前，您提供了以下比较：

1. 在旧服务器和新服务器上运行的相同（克隆）站点：
   • 区别：服务器
   • 结果：旧服务器运行很快；新服务器运行缓慢
   • 注意：这里需要的是量化这些服务器之间的差异-包括使用的堆栈（Nginx等）和硬件（旧服务器是否速度更快，因为它是一台更强大的机器？）
   • 结论：代码可以在正确的设置下快速运行
2. 在新服务器上测试站点与完整站点
   • 区别：内容，主题，插件等
   • 结果：测试站点速度快，完整站点速度慢
   • 注意：从理论上讲，此测试应帮助您消除设置的很多方面-DNS，网络，甚至您的nginx / php / mysql设置-但是，这不是很“公平”。
   • 结论：额外的内容对性能有重大影响

理想的测试是让您复制整个站点，然后删除除一篇文章和相关注释之外的所有内容。该测试的目的是最终确定问题是大量的内容还是造成设置的其他方面（wordpress插件，主题等）。您实质上将比较在同一台（新）服务器上加载相同页面（相同长度等）上相同站点的性能，唯一的区别是站点总内容（例如，某个插件很可能不会随着内容的增加可以很好地扩展）。

在不做任何更改的情况下，您还可以进行其他一些比较：

• 从远程位置与本地进行测试-这将有助于确定是否是网络，延迟，dns等引起的
  • 您已经（某种程度上）做到了这一点，并且大多数结论是您没有网络问题。
• 通过Varnish（即端口80）与直接通过nginx（端口8080）进行测试-尝试在测试之间不更改配置-只需使用正确的端口即可。这将向您展示清漆的影响。由于Varnish是一个缓存层，因此它应该非常快地处理第一个请求之后的所有请求-本质上，它应该绕过后端和生成动态页面所需的处理，并非常快地处理缓存的副本。
  • 您已经做到了这一点（尽管不是在本地），并证明了Varnish对您的表现有重大的积极影响。

调整后端

至此，您应该已经发现问题或得出结论认为它在您的后端中。剩下的就是Nginx，PHP或MySQL。

（我要在这里提到，那就是它总是很方便的知道你的瓶颈是CPU，内存或I / O -之间sar，top，iostat，vmstat，free，，等你应该能够得出这个结论的一些）

Nginx的

Nginx只是接受请求并提供静态内容或将请求转移到PHP-FPM － Nginx通常没有太多优化。

• 设置工人=＃CPU内核
• 启用keepalive（值10-15是好的）
• 禁用不必要的日志记录
• 如果需要，增加缓冲区大小
• 避免使用if语句（在可能的情况下，使用静态名称代替正则表达式，消除不必要的扩展名）

理想情况下，您的测试博客和克隆博客具有相同的配置，在这种情况下，您已经有效地消除了Nginx的问题。

应用

如果您试图确定代码中的问题（例如，慢插件等），那么慢日志就是开始的地方。

• 启用MySQL慢日志和PHP-FPM慢日志，运行您的基准测试，并查看即将发生的情况。

的MySQL

• 增加缓存并运行mysqltuner.pl以获得一个良好的起点。

的PHP

• 禁用不需要的扩展，
• 禁用register_globals，magic_quotes _ *，expose_php，register_argc_argv，always_populate_raw_post_data
• 增加memory_limit
• open_basedir和safe_mode具有显着的性能影响，但也可以提供附加的防御层。使用和不使用它们进行测试，以确定它们对性能的影响是否可以忍受。

PHP-FPM

• 调整pm。*值-增加它们以应对高负荷

值得注意的是，您的htop结果显示php-fpm占用了大量CPU-并且您的问题似乎确实与此直接相关。

快取

优化了每个可能的瓶颈后，就开始缓存。

• 您已经有一个opCode缓存（APC）-确保它正在运行（它与测试文件一起提供）-检查您的缓存命中率，并在可能的情况下将APC缓存缓存到内存而不是磁盘上。
• 设置代码以进行缓存（例如，使用Wordpress插件，例如W3TC）
• 使用nginx，您可以设置FastCGI缓存-但由于您具有Varnish，因此最好避免这种情况。
• 设置一个缓存层，例如Varnish（已完成）-并确保其正常工作（例如，使用varnishstat，请阅读实现较高的Hitrate）
• 为网站的组件添加更多缓存-例如，适用的MemCached

有时，由于应用程序和硬件的限制，您可能无法提高后端性能太多（但是，这就是缓存的要点），以最大程度地减少后端的使用。

进一步阅读

• 性能调优PHP
• 优化PHP
• 优化Nginx以实现高负载