PHP5 服务器的带宽提速技巧:输出和 Zlib 压缩 [英] Bandwith Speed Boost Tips for PHP5 Servers: Output and Zlib Compression
问题描述
关于在设置 PHP 带宽节省时 htaccess 中设置的性质以及有效速度提升，我有一些详细的专业问题:
请允许我提前感谢您对此事的回答和澄清，因为我不理解百科式长页 apache 手册
下面的示例是在我的 Apache 2.0 和 PHP 5.2.3 上实际运行的内容
# 为启用 PHP 的服务器保留带宽<ifmodule mod_php4.c>php_value zlib.output_compression 16386</ifmodule>.
问题 1:ifmodule mod_php4.c 是否建议它用于 PHP 4 而不是 PHP5?
问题 2:在 php.ini 中而不是 htaccess 中，服务器引擎是否会更快?
Q3:压缩默认设置为16386.如果我们将其降低到例如 4K
Q4:如果我们将它设置得更高会发生什么，例如128K ?
Q1:ifmodule mod_php4.c 是否建议它用于 PHP 4 而不是 PHP5?
是的.运行.除非您的脚本会在 PHP5 下崩溃，否则没有理由继续安装 PHP4.
<块引用>Q2:在 php.ini 中而不是 htaccess 中，服务器引擎是否会更快?
除了 Apache 启动期间的一些操作码之外，一点都不重要.意思是，不...除非 .htaccess 文件不存在，在这种情况下，Apache 找到该文件可能会对性能造成很小的影响.(更少的 .htaccess 文件 => 减少不必要的 stat 调用 => 一切 的更快性能.)
Q3:压缩默认设置为 16386.如果我们将其降低到 4K 会发生什么
这是缓冲区的大小为输出.如果你把它降到 4k，数据会稍微快点发送.根据页面的平均大小，这可能意味着数据可能需要以多个块发送，这对于获取数据的用户来说可能是一个非常小的性能下降.
<块引用>Q4:如果我们将它设置得更高会发生什么，例如128K?
这意味着 128k 的缓冲会在数据发送到客户端之前发生.如果您的页面在 gzip 后超过 128k，则可能有问题.
<块引用>设置 PHP 带宽节省和有效的速度提升:
不久前，人们开始建议不要使用 PHP 的内置 gzip，建议 Apache 的 mod_deflate 代替.这让 PHP 只关心生成 HTML，而让 Apache 担心压缩和提供它.它也有同样的效果.虽然 mod_deflate 的手册页是百科全书，但它也很简单明了.您可能已经有了它，只是在 httpd.conf 中没有使用所需的行.
因为它可以在过滤器"级别运行，所以使用它也意味着任何东西产生压缩的 MIME 类型，包括 CGI 脚本和普通的旧 HTML 文件都可以自动 gzipped.
<小时>更新评论回复:
<块引用>我会继续阅读吗?在行之间正确地建议我删除块 A 并且在 如这里所见
这通常是正确的，尽管您拥有的配置块当前按扩展名定位文件.相反，您可以使用 AddOutputFilterByType 配置指令按 MIME 类型进行定位，如 mod_deflate 手册中所述.
删除 PHP 配置时，还要检查系统上的 php.ini，因为它可能还包含您可能不需要的压缩指令.
Apache 将足够聪明，不会对内容进行双重 gzip，无论您使用什么方法打开 mod_deflate.
<块引用>更改块 A 以使其与 PHP5 最兼容的正确方法是什么?
这取决于您的系统上调用了 5.x 版本的 mod_php.它将只是普通的普通 mod_php 或 mod_php5.在 httpd.conf(或/etc/httpd/conf.d/*.conf)的其他地方寻找 LoadModule 指令.
实际配置指令是正确的，它只是包含在仅在加载 PHP4 时才执行此操作"块中.
假设您的 5.x mod_php 被称为 mod_not_butter.如果是这种情况，该块将如下所示:
php_value 吸度系数 -1</IfModule> <块引用>
我想知道还有哪些其他选项可以自定义/加速我的 mod_deflate APACHE gzip 处理
有很多选择.除了缓冲区大小(DeflateBufferSize)，您应该将其设置为您期望的平均未压缩数据大小.(我之前记错了缓冲区是在压缩之后，而实际上是在压缩之前.)
所有其他选项都是您不需要触及的合理默认值，因为当更改它们实际上会以有意义的方式影响性能时，您将希望使用其他技术来减轻 Apache 的负担.
I have some detailed, specialist questions about the nature of the settings that go in htaccess when setting up PHP bandwith savings and the effective speed gain experienced:
Allow me to thank you in advance for your answer and clarifications on this matter as I dont understand the encyclopedic style long-page apache manuals
Example below is what is actually running on my Apache 2.0 and PHP 5.2.3
# preserve bandwidth for PHP enabled servers
<ifmodule mod_php4.c>
php_value zlib.output_compression 16386
</ifmodule>
.
Q1: Does ifmodule mod_php4.c suggest that its for PHP 4 and not PHP5?
Q2: Would it be faster for the server engine to have this in php.ini, instead of htaccess?
Q3: The compression is default set to 16386. What happens if we lower it to, say, 4K
Q4: What would happen if we set it higher, e.g. 128K ?
Q1: Does ifmodule mod_php4.c suggest that its for PHP 4 and not PHP5?
Yes. RUN. PHP4 has no reason to still be installed unless you have scripts that will break under PHP5.
Q2: Would it be faster for the server engine to have this in php.ini, instead of htaccess?
It shouldn't matter one iota except for a few opcodes during Apache startup. Meaning, no... unless the .htaccess file was not already present, in which case there may be a tiny performance hit as Apache finds the file. (Fewer .htaccess files => less needless stat calls => faster performance for everything.)
Q3: The compression is default set to 16386. What happens if we lower it to, say, 4K
This is the size of the buffer for the output. If you drop it to 4k, data will be sent slightly sooner. Depending on the average size of the page, this can mean that data could need to be sent in multiple chunks, which may well be a very tiny performance drop for the user getting the data.
Q4: What would happen if we set it higher, e.g. 128K ?
This means that 128k of buffering woudl happen before data was sent to the client. If your pages are over 128k post-gzipping, something's probably wrong.
setting up PHP bandwith savings and the effective speed gain experienced:
A while ago, people started recommending not using PHP's built-in gzip, suggesting Apache's mod_deflate instead. This lets PHP just care about generating the HTML, and lets Apache worry about compressing and serving it. It also has the same effect. While the manual page for mod_deflate is encyclopedic, it's also simple and straightforward. You may already have it available and simply have the required lines unused in your httpd.conf.
Because it can operate at the "filter" level, using it also means that anything producing the compressed MIME types, including CGI scripts and plain old HTML files can get gzipped automatically.
Update with answers to comments:
Do I read on & inbetween the lines correctly that you suggest me to remove the block A and have only block B in place as seen here
This is generally correct, though the configuration block you have there is currently targeting files by extension. Instead, you can target by MIME type using the AddOutputFilterByType configuration directive, as documented on the mod_deflate manual.
When removing the PHP configuration, also inspect the php.ini on your system, as it may also contain compression directives that you might not need.
Apache will be smart enough not to double-gzip content, no matter what method you use to turn on mod_deflate.
what would be the proper way to change the block A to make it most compatible with PHP5?
It depends on what the 5.x version of mod_php is called on your system. It'll be either just plain old regular mod_php or mod_php5. Look for the LoadModule directive elsewhere in httpd.conf (or in /etc/httpd/conf.d/*.conf).
The actual configuration directive is correct, it's just wrapped in a "do this only if PHP4 is loaded" block.
Let's say that your 5.x mod_php is called mod_not_butter. If this is the case, the block would look like:
<IfModule mod_not_butter.c>
php_value suckitude_factor -1
</IfModule>
I wonder what other options I might have to customize/speed up my mod_deflate APACHE gzip processing
There are lots of options. Don't touch any of them except the buffer size (DeflateBufferSize), which you should set to the average uncompressed data size that you expect. (I earlier misremembered that the buffer was after compression, while it's actually before.)
All of the other options are sane defaults that you don't need to touch, because by the time that changing them would actually impact performance in a meaningful way, you'll want to have other technologies involved to take load off Apache.
这篇关于PHP5 服务器的带宽提速技巧:输出和 Zlib 压缩的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
