我最近遇到了一个我仍然无法克服的问题。
所以，我有一个用WordPress写的市场。 在开发过程之后，我试图通过网站自然加载许多资源来优化速度。
我使用了WpFastestCache ，它为我生成.htaccess。 问题是这样的：
当mod_deflate和mod_expires被启用时，我得到一个相当整洁的资源加载时间，但一个巨大的（大约10s！）TTFB。
当mod_deflate和mod_expires被禁用，TTFB下降到几乎没有，但我得到一个巨大的资源加载时间。
这是常见还是独特的情况？
考虑到在启用压缩function和禁用压缩function时遇到问题，听起来问题的根本原因不在于压缩，而在于其他地方。
您解释启用/禁用压缩时症状如何改变。 然而，症状的变化只是一个小小的变化，而这种变化就是大多数压缩scheme所期望的。
当禁用压缩时，您会看到响应的第一部分很快产生。 完全有可能的是，快速生成的响应部分是一个静态内容与用户数据无关的头部，这可能就是为什么生成这么快的原因。 有问题的部分是数据源需要很长时间来产生其余的输出。
一旦引入压缩，症状就会改变。 标题数据可能会被快速传送到压缩代码，但是为了提高性能，压缩代码会在将数据发送到客户端之前等待更多的数据。 所以less量的数据将被放置在缓冲区中一段时间。
一些API允许生成数据的代码指示压缩代码刷新缓冲的数据，如果在这里使用，可以使症状看起来与未压缩的设置相同。 但是，如果迄今为止产生的数据本身没有用处，则冲洗缓冲区是不值得的。
你应该关注的是为什么在最后一个字节发送之前需要这么长的时间。 我猜测，如果你试图测量到最后一个字节的时间，它将大致相同，没有压缩。
服务器上的负载如何？
如果服务器上的负载很高，则可能表示正在忙于执行CPU密集型任务，以产生对正在接收的请求的响应。 这也可能表明服务器需要大量的I / O（通常可以通过增加更多的RAM来减less）。
如果服务器上的负载较低，响应速度仍然很慢，则通常表示正在等待与另一台服务器（可能是一台数据库或一台DNS服务器响应缓慢）的networking通信。 它也可能表示你的代码中有一个错误。
如果无法从服务器负载，networkingstream量检查或日志文件中推断是什么导致缓慢，则可能需要向应用程序添加更多的日志logging，以便了解如此长时间内正在执行的操作。