它可能是也可能不是手册所暗示的,但是一个上下文中,启用implicit_flush或调用ob_implicit_flush()具有严重的性能影响,当使用PHP与Apache通过mod_php启用
mod_deflate时.
在这种情况下,flush()调用能够通过mod_deflate将输出一直推送到浏览器.如果你有任何脚本以小块方式回显大量数据,那么刷新每个块会削弱mod_deflate压缩输出的能力,很可能导致一个比原始内容更大的“压缩”形式.
作为一个极端的例子,考虑这个回忆出一百万个随机数的简单脚本:
header('Content-Type: text/plain');
for ($i=0; $i < 1000000; $i++) {
echo rand();
echo "\n";
}
?>
随着output_buffering关闭和implicit_flush也关闭(现在),让我们在开启开发工具的Chrome中点击这个:
请注意“大小/内容”列;解压缩的输出大小为10.0MB,但由于mod_deflate的gzip压缩,整个响应被压缩到4.8MB,大小减半.
现在命中完全相同的脚本,并将implicit_flush设置为On:
再次,“解压缩”输出的大小为10.0MB.但是这一次,HTTP响应的大小是28.6MB – mod_deflate的’compression’实际上是响应大小的三倍.
对我来说,这足以理解PHP手册的建议,即关闭implicit_flush配置选项,并且仅在上下文中使用ob_implicit_flush()(或手动flush()调用),这样做实际上是有用的.