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

Question

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

为方便起见，我考虑只打开php.ini中的implicit_flush设置，而不是向每个可以从中受益的脚本添加ob_implicit_flush()调用。

但是，该文档包含以下可怕但无法解释的评论：

  

implicit_flush

     

...

     

在Web环境中使用PHP时，启用此选项会产生严重的性能影响，通常建议仅用于调试目的。

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

Answer 1

这可能是也可能不是手册所暗示的内容，但是开启implicit_flush或调用ob_implicit_flush()具有严重性能影响的一个上下文是通过{{1已启用mod_deflate。

在此上下文中，mod_php调用可以将flush()的输出一直推送到浏览器。如果你有任何脚本以小块方式回显大量数据，那么刷新每个块会削弱mod_deflate压缩输出的能力，很可能导致压缩＆＃39;形式大于原始内容。

作为一个极端的例子，请考虑这个简单的脚本，它回显了一百万个随机数：

mod_deflate

关闭<?php header('Content-Type: text/plain'); for ($i=0; $i < 1000000; $i++) { echo rand(); echo "\n"; } ?> ，output_buffering也关闭（暂时），让我们在开启开发工具的Chrome中点击此内容：

请注意尺寸/内容列;解压缩的输出大小为10.0MB，但由于implicit_flush的gzip压缩，整个响应被压缩到4.8MB，大小减半。

现在点击完全相同的脚本，mod_deflate设置为implicit_flush：

再一次，＆＃39;解压缩＆＃39;输出大小为10.0MB。不过，这一次，HTTP响应的大小为28.6MB - On＆＃39;压缩＆＃39;实际上已经增加了三倍的响应量。

对我来说，这是绰绰有余的理由，需要注意PHP手册中关于mod_deflate配置选项关闭的建议，并且仅使用implicit_flush （或手动ob_implicit_flush()调用）在上下文中这样做实际上是有用的。