简体   繁体   English

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

[英]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.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM