作为一个行走江湖多年的老中医,今天受命去解决一例前端页面展现缓慢的问题。问题页的情况如下:
- apache + php
- 使用smarty模板输出内容
- 页面最终输出内容较大,80k+
- 页面执行时间在500ms以上
祭出法宝xhprof对问题页面做了细致检查,发现页面的瓶颈竟然是模板(编译后的)中的一个echo语句,这个echo语句输出的字符串比较大,大概是50k+字节,花费时间为400多毫秒,占整个页面执行时间的80%。这样的echo输出在站点首页中其实是很常见的事情,没有数据库操作,按道理执行时间不应该这么长。
于是猛力使用搜索技能,最终在php手册的echo部分找到了一些蛛丝马迹,早在2003年就有前辈认为通过echo输出大字符串到客户端会引起服务器的性能问题,据我测试,在这个场景下使用print其实也是一样的慢。建议的解决办法是把字符串切割成更小的字符串输出,展现速度会有提升,输出函数如下:
<?php
function echobig($string, $bufferSize = 8192) {
$splitString = str_split($string, $bufferSize);
foreach($splitString as $chunk)
echo $chunk;
}
?>
但是上面的处方不太对症,整个echobig的输出时间仍然在400毫秒左右,没有太大改善。
考虑到是输出大量内容到客户端比较慢,于是检查了apache的配置,原来还没打开deflate进行压缩,遂启用之。再次使用xhprof进行检查,这条echo的输出时间降低到5ms左右。
400ms到5ms,一个配置问题会产生80倍的差距,还真是省老钱了。这个故事告诉我们,压缩输出真的很重要。
Update
实际上这个问题也可以通过调整webserver的output buffer来解决一部分,参考:
13 responses to “php的echo为什么这么慢”
没明白,apache 开始压缩的时候 PHP 已经结束了吧?并不能影响 PHP 的执行,还要额外花 CPU 内存去压缩。我怎么觉得是你网慢……
总之 50k 花了 400ms,瓶颈绝对不可能是在 echo 上
我的理解是这样的,如果没有启用压缩,那么echo输出应该是直接丢给客户端的,如果我网慢也可能会成为一个很大的原因。
但是如果启用了压缩,输出的内容先交给apache进行压缩,这中间受网络因素影响应该会很小,然后再丢给客户端。由于内容已经压缩,网慢的影响会减少,另外这部分时间可能转嫁给了apache
看完以后,觉得自己还太菜~博主用的工具我都没听说过~呵呵
不过日后有机会了一定要注意echo的问题~再次谢谢博主啊
直接使用FASTCGI,没有问题,和ECHO没得关系。
写了一个简单的程序测试, 并不能重现博主提到的问题. 在我机器上(mod_php, mod_deflate未启用)的一个典型的测试结果:
strlen: 81920
time: 1.22594833374 ms
这个情况下比较容易重现:
没启用 ob?
不管是否启用ob,当时都一样的慢。所以可以排除ob的缘故。
这个办法加重了cpu的负担,不过应该还是在合理范围内
碰到了同样的问题:echo慢。至今也不知道是怎么回事。
测试代码很简单:
记录时间microtime
echo 一个 160000 个a构成的字符串 其实也就150多k。
记录时间,计算差值。
这个已经和网络毫无关系了。
然后俺碰到一个服务器,echo时间用了1.5秒!!俺自己的破机器(amd sempron2800+)上,基本上都是0.0n乃至0.00n,也没开压缩。
而那台服务器,4核cpu,4G内存……俺也奇怪得很,不知道哪里出毛病了
后来按楼主说的,加了压缩,强了很多,但是这个问题依然是让俺莫明其妙中。
我觉得可能和HTTP的传输模式有关。
HTTP1.1里面有个Content-Encoding叫Chunked,传输模式是间断的数据。也就是说如果apache没有开启deflate,可能造成php输出成为chunked数据(这个和在php里面用flush()函数一样)。
不好意思说错了。。是不是content-encoding,而是Transfer-Encoding
我分析了一下,详见
http://www.longbill.cn/blog/php_echo/