php – implicit_flush的“严重性能影响”是什么？

我的网站的管理部分有一堆非常慢的报告生成脚本,它们按生成的方式逐行回显输出.要将此输出立即刷新到浏览器,而不是用户在看到任何响应之前必须等待几分钟,我们将禁用output_buffering,并在此类脚本的开头调用ob_implicit_flush.

为方便起见,我正在考虑在PHP.ini中启用implicit_flush设置,而不是向每个可以从中受益的脚本添加ob_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.

这些“严重的性能影响”是什么？他们是否证明了手册的推荐理由？

解决方法:

它可能是也可能不是手册所暗示的,但是一个上下文中,启用implicit_flush或调用ob_implicit_flush()具有严重的性能影响,当使用PHP与Apache通过mod_PHP启用mod_deflate时.

在这种情况下,flush()调用能够通过mod_deflate将输出一直推送到浏览器.如果你有任何脚本以小块方式回显大量数据,那么刷新每个块会削弱mod_deflate压缩输出的能力,很可能导致一个比原始内容更大的“压缩”形式.

作为一个极端的例子,考虑这个回忆出一百万个随机数的简单脚本：

<?PHP
    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()调用),这样做实际上是有用的.