在我的服务器中打开 zlib.output_compression 有什么注意事项吗？答案

【问题标题】：Is there any caveats with turning zlib.output_compression in my server?在我的服务器中打开 zlib.output_compression 有什么注意事项吗？
【发布时间】：2010-06-02 18:01:19
【问题描述】：

我在我的服务器上启用了 zlib 和 Zend Optimizer，我已经阅读了有关

zlib.output_compression

指令。在我的服务器中打开这个指令有什么注意事项吗？

【问题讨论】：

您想开启输出压缩吗？你应该让你的服务器做less而不是更多。
解释gumbo所说的，输出压缩减少了发送到客户端机器的文件大小，代价是让服务器在发送每个文件时对其进行压缩。如果您尝试优化服务器执行时间，那么您在这里找错了树。
嗯，我明白你在说什么。那么 zlib.output_compression 的真正用途是什么？换句话说，减少“发送到客户端计算机的文件大小”有什么好处？
输出压缩是为了减少你的HTTP数据包的大小——如果我没记错的话，通常是33%左右。这在您有大页面的情况下很有帮助，其中压缩/解压缩的时间量

标签： php optimization performance execution

【解决方案1】：

首先，您应该确定瓶颈是什么（或可能处于负载之下）。
通过打开（透明）压缩，您可以用 CPU 资源换取数据（网络）吞吐量。因此，您必须考虑：我的数据（高度）可压缩吗？将数据传输到客户端所需的时间是瓶颈吗？我可以为压缩花费多少 CPU 资源？我的脚本还使用了哪些其他资源（例如内存消耗、数据库连接……）？哪个资源会成为（重）负载下的瓶颈？脚本的一个实例何时、何地以及多长时间会阻塞另一个实例？以此类推。

您可能还对YSlow 之类的工具、xdebug 中内置的分析器、apache benchmarking tools 之类的工具、apc 之类的（代码）缓存...等等感兴趣。

【讨论】：

总结得很好，哪个资源是你的问题？ CPU 还是带宽？在带宽上增加额外的计算能力要便宜得多，所以从管理的角度来看，增加更多的计算能力来处理压缩文件的额外负担以节省带宽符合您的最佳利益。

【解决方案2】：

要加速 PHP 代码，最有效的方法是运行 opcode cache。

Zend Optimizer+ 就是一个例子。较旧的 Zend Optimizer（没有“+”）是代码优化器，而不是操作码缓存，如果您不使用操作码缓存，它实际上可能会减慢 PHP 代码。

在你这样做之后，就会进行大量艰苦的工作来测试瓶颈（正如其他人所提到的）。您需要仔细重构代码以缓解瓶颈。大多数性能专家表示，性能问题是由糟糕的应用程序架构引起的，而不是由单个代码行引起的。

缓存需要多次显示的内容也是提高性能的常用解决方案。但是，决定缓存哪些内容以及缓存多长时间是您需要进行测试、实验和判断的另一个领域。

考虑瓶颈可能根本不在您的 PHP 代码中。可能是您的数据库没有正确的索引。 Finding the right indexes 考虑到您需要运行的查询也是一项细致的工作，并且涉及测试。

您的瓶颈也经常出现在客户端。即使您的 PHP 代码在服务器上快速运行，页面在浏览器中的加载效率也可能很低，从而造成性能不佳的感觉。

恕我直言，所有网页设计师和开发人员都应该将 Steve Souders books 和 blogs 设为必读。

这也与您询问的 zlib 配置以及客户端性能测量工具（如 YSlow 和 Google PageSpeed）有关。

【讨论】：

【解决方案3】：

学习分析。
然后优化瓶颈。

【讨论】：

【解决方案4】：

输出压缩是要走的路。 将压缩级别设置为 1，因为它提供了最大的节省/CPU 开销比率。默认级别是 1-9 中的 6，这可能会因为一些额外的字节而减慢速度而导致效率低下。

【讨论】：