echo 导致大字符串性能下降答案

【问题标题】：echo causes slow performance with large stringecho 导致大字符串性能下降
【发布时间】：2016-07-05 01:49:23
【问题描述】：

所以基本上我在内部应用程序中有一个部分，允许用户通过Summernote.JS修改/编辑 HTML。

我面临的问题是加载时间很可笑，我似乎只在 Chrome 中遇到过这种情况。

正在编辑的 HTML 内容的长度为 150252，因为有 base64 内联图像。加载时间如下..

Chrome (Version 51.0.2704.106 m):               39.53 seconds
Firefox (Version 43.0.1):                       2.08 seconds (onload: 2.74s) - 629.8KB
Internet Explorer (Version 11.0.9600.17843):   ~2.8 seconds

下图是 Chrome 完全刷新时的加载时间。

有趣的是，当我删除上述内容的回声时，页面加载的瞬间

<textarea id="content" name="content" placeholder="Simply enter the section content below.."><?php echo $this->section->section; ?></textarea>

现在我发现了这个old bug on PHP.net（经过一番认真的搜索，哈哈），它说 PHP 的 echo 处理通过 TCP/IP 缓冲到浏览器的数据非常糟糕，因为 Nagle Algorithm .

没有将内容保存到临时文件并使用readfile() 来获取内容（这会返回原始性能），我还能做些什么来在 chrome 中解决这个问题？分块输出数据？过程不会过于复杂。

【问题讨论】：

你可能会责怪 chrome 的拼写检查器。禁用它（在设置 -> 语言 -> 语言和输入设置 -> 底部的复选框）并告诉性能是否有任何差异？
@zerkms 只是边际性能提升 - 测试从 22 seconds - 34 seconds 变化。
@zerkms 结果是 - 当跨度/字符串长于 2^16 时，这是一个 Chrome 错误，导致它无法很好地转化为视图

标签： php google-chrome

【解决方案1】：

我似乎找到了这个问题的根本原因。经过一些挖掘和内容操作，很明显这是由于 Base64 图像。移除后，页面加载时间恢复正常。

在研究之后，现在详细说明这个问题。事实证明，Chrome 在 Chromium (^{Reference (Issue #69227)}) 中存在此错误已有一段时间了。由于 base64 图像在单行中，因此 Chromium 单行跨度限制为 2^16，我的 base64 图像超出了该值。

在某些字符限制之后将图像在这里和那里分割成新行，设法将加载时间从~34 seconds 降低到~17 seconds。我创建了一个与此类似的函数，它可以适当地拆分字符串：

function __chunk($string, $chunkSize = 40) {
    $splitString = str_split($string, $chunkSize);

    foreach($splitString as $chunk) {
        echo $chunk . "\n";
    }
}

^{显然必须找出一个合适的$chunkSize。}

诀窍是弄清楚如何获取 base64 数据，因为 HTML 内容的其余部分会做它需要做的事情。

另一种替代解决方案是将所述 base64 转换为 blob (^{Reference SO Question})。

您可以通过查看 Atom 中与此确切问题相关的 this bug 来更好地了解此错误。

【讨论】：