[英]What are the “serious performance implications” of implicit_flush?
My site's admin section has a bunch of very slow report-generating scripts that echo
output line by line as it is generated. 我的网站的管理部分有一堆非常慢的报告生成脚本,它们在生成时逐行
echo
输出。 To have this output flushed immediately to the browser, instead of the user having to wait for minutes before they see any response, we have output_buffering
disabled and we call ob_implicit_flush
at the beginning of such scripts. 要将此输出立即刷新到浏览器,而不是用户在看到任何响应之前必须等待几分钟,我们将禁用
output_buffering
并在此类脚本的开头调用ob_implicit_flush
。
For convenience, I was considering just turning on the implicit_flush
setting in php.ini instead of adding ob_implicit_flush()
calls to every script that would benefit from it. 为方便起见,我正在考虑打开php.ini中的
implicit_flush
设置,而不是将ob_implicit_flush()
调用添加到每个可以从中受益的脚本。
However, the documentation contains the following scary but unexplained remark: 但是,该文档包含以下可怕但无法解释的注释:
implicit_flush
implicit_flush
...
...
When using PHP within an web environment, turning this option on has serious performance implications and is generally recommended for debugging purposes only.
在Web环境中使用PHP时,启用此选项会产生严重的性能影响,通常建议仅用于调试目的。
What are these "serious performance implications", and do they justify the manual's recommendation? 这些“严重的性能影响”是什么?他们是否证明了手册的推荐理由?
It may or may not be what the manual is hinting at, but one context in which either turning on implicit_flush
or calling ob_implicit_flush()
has serious performance implications is when using PHP with Apache through mod_php
with mod_deflate
enabled. 它可能是也可能不是手册所暗示的,但是启用
implicit_flush
或调用ob_implicit_flush()
一个上下文具有严重的性能影响是通过mod_php
在启用mod_deflate
情况下将PHP与Apache一起使用。
In this context, flush()
calls are able to push output all the way through mod_deflate
to the browser. 在这种情况下,
flush()
调用能够通过mod_deflate
将输出一直推送到浏览器。 If you have any scripts that echo large amounts of data in small chunks, flushing every chunk will cripple mod_deflate
's ability to compress your output, quite possibly resulting in a 'compressed' form that is larger than the original content. 如果你有任何脚本以小块方式回显大量数据,那么刷新每个块会削弱
mod_deflate
压缩输出的能力,很可能导致“压缩”形式大于原始内容。
As an extreme example, consider this simple script which echoes out a million random numbers: 作为一个极端的例子,考虑这个回忆出一百万个随机数的简单脚本:
<?php
header('Content-Type: text/plain');
for ($i=0; $i < 1000000; $i++) {
echo rand();
echo "\n";
}
?>
With output_buffering
off and implicit_flush
also off (for now), let's hit this in Chrome with the dev tools open: 随着
output_buffering
关闭和implicit_flush
也关闭(现在),让我们在开启开发工具的Chrome中点击这个:
Note the Size/Content column; 请注意“大小/内容”列; the decompressed output is 10.0MB in size, but thanks to
mod_deflate
's gzip compression, the entire response was compressed down to 4.8MB, roughly halving it in size. 解压缩的输出大小为10.0MB,但由于
mod_deflate
的gzip压缩,整个响应被压缩到4.8MB,大小减半。
Now hitting exactly the same script with implicit_flush
set to On
: 现在命中完全相同的脚本,并将
implicit_flush
设置为On
:
Once again, the 'decompressed' output is 10.0MB in size. 再次,“解压缩”输出的大小为10.0MB。 This time, though, the size of the HTTP response was 28.6MB -
mod_deflate
's 'compression' has actually trebled the size of the response. 但是这一次,HTTP响应的大小是28.6MB -
mod_deflate
的'compression'实际上是响应大小的三倍。
This, for me, is more than enough reason to heed the PHP manual's advice of leaving the implicit_flush
config option off , and only using ob_implicit_flush()
(or manual flush()
calls) in contexts where doing so actually serves a purpose. 对我来说,这足以
ob_implicit_flush()
PHP手册的建议,即关闭 implicit_flush
配置选项,并且仅在上下文中使用ob_implicit_flush()
(或手动flush()
调用),这样做实际上是ob_implicit_flush()
。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.