php – implicit_flush的“严重性能影响”是什么？
|
我的网站的管理部分有一堆非常慢的报告生成脚本,它们按生成的方式逐行回显输出.要将此输出立即刷新到浏览器,而不是用户在看到任何响应之前必须等待几分钟,我们将禁用
output_buffering,并在此类脚本的开头调用
ob_implicit_flush.
为方便起见,我正在考虑在php.ini中启用 但是,该文档包含以下可怕但无法解释的注释：
这些“严重的性能影响”是什么？他们是否证明了手册的推荐理由？ 解决方法
它可能是也可能不是手册所暗示的,但是一个上下文中,启用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()调用),这样做实际上是有用的. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |