PHP5 服务器的带宽提速技巧:输出和 Zlib 压缩

发布于 2024-10-25 05:29:15 字数 693 浏览 2 评论 0原文

我对设置 PHP 带宽节省有效速度增益体验时 htaccess 中设置的性质有一些详细的专业问题:

请允许我在请提前获得您对此事的回答和澄清,因为我不理解百科全书式的长页 apache 手册

下面的示例是我的 Apache 2.0 和 PHP 5.2.3 上实际运行的内容

# preserve bandwidth for PHP enabled servers
<ifmodule mod_php4.c>
    php_value zlib.output_compression 16386
</ifmodule>

Q1: ifmodule mod_php4.c 是否表明它适用于 PHP 4 而不是 PHP5?

问题2:服务器引擎将其放在php.ini中而不是htaccess中会更快吗?

Q3:压缩默认设置为16386。如果我们将其降低到4K,会发生什么

Q4:如果我们将其设置得更高,例如128K,会发生什么?

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 ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

别再吹冷风 2024-11-01 05:29:15

问题1:ifmodule mod_php4.c 是否表明它适用于 PHP 4 而不是 PHP5?

是的。 运行。 PHP4 没有理由继续安装,除非您的脚本在 PHP5 下会崩溃。

Q2:服务器引擎将其放在 php.ini 中而不是 htaccess 中会更快吗?

除了 Apache 启动期间的一些操作码之外,一丁点都不重要。意思是,不...除非 .htaccess 文件尚不存在,在这种情况下,当 Apache 找到该文件时,性能可能会受到微小影响。 (更少的 .htaccess 文件 => 更少不必要的 stat 调用 => 更快的性能。)

问题 3:压缩默认设置为 16386。如果我们将其降低到 4K,会发生什么

这是输出缓冲区的大小。如果将其降至 4k,数据发送速度会稍快一些。根据页面的平均大小,这可能意味着数据可能需要以多个块的形式发送,这对于获取数据的用户来说很可能是一个非常小的性能下降。

问题4:如果我们将其设置得更高,例如128K,会发生什么?

这意味着在数据发送到客户端之前会发生 128k 的缓冲。如果您的页面在 gzip 压缩后超过 128k,则可能有问题

设置 PHP 带宽节省和有效的速度增益体验:

不久前,人们开始建议不要使用 PHP 的内置 gzip,建议 Apache 的 mod_deflate 代替。这让 PHP 只关心生成 HTML,而让 Apache 关心压缩和提供它。也有同样的效果。虽然 mod_deflate 的手册页是百科全书式的,但它也简单明了。您可能已经拥有它,并且只是在 httpd.conf 中未使用所需的行。

因为它可以在“过滤器”级别运行,所以使用它还意味着生成压缩 MIME 类型的任何内容(包括 CGI 脚本和普通的旧 HTML 文件)都可以自动进行 gzip 压缩。


更新评论的答案:

我要继续阅读吗?正确地在行之间,您建议我删除块 A 并仅在 此处所示位置

这通常是正确的,尽管您那里的配置块当前是按扩展名定位文件。相反,您可以使用 AddOutputFilterByType 配置指令按 MIME 类型进行定位,如 mod_deflate 手册中所述。

删除 PHP 配置时,还要检查系统上的 php.ini,因为它可能还包含您可能不需要的压缩指令。

无论您使用什么方法打开 mod_deflate,Apache 都会足够聪明,不会对内容进行双重压缩。

更改块 A 以使其与 PHP5 最兼容的正确方法是什么?

这取决于您的系统上调用的 mod_php 5.x 版本。它将是普通的旧常规 mod_php 或 mod_php5。在 httpd.conf 中的其他位置(或在 /etc/httpd/conf.d/*.conf 中)查找 LoadModule 指令。

实际配置指令是正确的,它只是包含在“仅在加载 PHP4 时才执行此操作”块中。

假设您的 5.x mod_php 名​​为 mod_not_butter。如果是这种情况,该块将如下所示:

<IfModule mod_not_butter.c>
    php_value suckitude_factor -1
</IfModule>

我想知道我可能还需要哪些其他选项来自定义/加速我的 mod_deflate APACHE gzip 处理

有很多选项。除了缓冲区大小(DeflateBufferSize),您应该将其设置为您期望的平均未压缩数据大小。 (我之前错误地记得缓冲区是在压缩之后,而实际上是在压缩之前。)

所有其他选项都是您不需要触及的合理默认值,因为到更改它们时实际上会以有意义的方式影响性能,您需要使用其他技术来减轻 Apache 的负担。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文