向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除|赢在IT，Playin' with IT,Focus on Killer Application,Marketing Meets Technology.

早上听群里的兄弟如是说：
莫莫<happy.yin@qq.com>  9:14:43
先关闭MYSQL 后输出数据 的 速度比先输出数据而后 关闭MYSQL 连接的速度快？！！
http://hi.baidu.com/caoz/blog/item/a46234a83b7cc7bacb130cd5.html
莫莫<happy.yin@qq.com>  9:15:43
这家伙吧我搞糊涂了
....
引发一阵讨论热潮。。。
该文章来自：
http://hi.baidu.com/caoz/blog/item/a46234a83b7cc7bacb130cd5.html

评论：
（1）因为php执行阻塞，导致mysql链接无法迅速释放，那么，php为什么会阻塞？ 逐个断点分析发现，原来echo耽误了最多时间。
谁的错，我想不是PHP的错啊，呵呵，可能是Apache的错，这块值得研究。。。（牛奶都是草的错不是，PHP千万不能承认）,
可以看下风雪之隅有一篇文章名字是这样的：PHP是无辜的：http://www.laruence.com/2010/12/17/1833.html ，结论是：最后, PHP真的很无辜, 和它真没关系，呵呵。
（2）发现memcached服务器有不稳定因素，原来是memcached流量过高产生阻塞，php进程等待链接，导致mysql链接大量等待。
试问：这种问题出现了阻塞为什么没有连接超时的机制？Memcache连接超时是可以设置的，再就是从架构上，也就是从Memcahce多加几台机器等方法，或者通过服务器，客户端的一个算法来分流到不同的Memcache机器上，发现不足，同时可以加入新的机器，同时少量内存的迁移即可，这都需要一个算法来实现的。


出两个变态的题目，题目很变态，但是都是实战中遇到的真实案例，

1：我写一个程序，既要使用mysql也要使用memcache，

第一行是 mysql_connect,第二行是memcache_connect

换过来写，第一行是memcache_connect，第二行是mysql_connect

caoz发现实践中这两种写法有很大的区别，区别在哪里？

2：我写一个程序，使用了mysql，生成了一个页面最后用 echo $html; 输出

一种写法是

mysql_close();

echo $html;

另一种是

echo $html;

mysql_close();

caoz发现实践中这两种区别很大，区别在哪里？

两个全是实践中发现并调整的案例。

---------------------------------------------半夜黑眼圈更新博客的分割线--------------------------------

caoz写程序不是追求BT的人，caoz经常和工程师强调，不追求极端的技术体现或者技术炫耀，所以，如果读者认为这里的题目是为了所谓的诸如某个写法比某个写法资源开销小一点或者其他什么，那么这真不是caoz的本意。

这两道题都是真实运营环境中遇到的典型案例，典型在哪里呢？就是当你遇到一个系统故障的时候，你怎么分析，怎么思考，怎么判断多种关联因素的影响，所以这个题目答出答不出并不重要，重要的是怎么思考系统彼此的关系。

一个典型的系统故障是， mysql 连接过多，或者说too many connections，这个问题困扰了我们很久，如果这是因为索引导致的，或者因为数据并发请求导致的，定位到原因并不复杂，但是当上述问题解决后，诡异的现象发生了，数据库几乎没有压力，没有阻塞进程，没有慢查询，但是mysql连接很多，而且都是sleep连接。此时，webserver的链接也很多，换句话说，因为php执行阻塞，导致mysql链接无法迅速释放，那么，php为什么会阻塞？ 逐个断点分析发现，原来echo耽误了最多时间。

这个事情让caoz涨了点经验，之前从来不会认为echo是一个时间阻塞点（如果你在本机测试，你会认为其时间延迟几乎是0），但是实例跟踪发现，echo实际上在我们的工作环境中，代表的网络传输的过程，换言之，会因为路由，带宽的因素而等待，而此时，mysql的链接还在那里没有释放，是的，看到题目每个人都会想到，mysql_close要放在echo后面，但是为什么echo会耽误时间，很少人会想到。当然，这个也与工作环境有关，caoz只知道我们配置的webserver会有这种情况，是不是存在其他的配置模式，caoz没有实测，不敢乱说，但是这里的经验是，mysql_close放到echo前面，大量的sleep链接会迅速减少。

echo并不耗费太多系统资源，但是会等待网络传输，在高并发的网络环境下，注意这一点对数据库很有好处。

这个问题解决后，mysql健康了很多，但是偶然还会出现链接过多的问题，又困扰了很久，直到有一天，根据用户反馈的一些错误信息，发现memcached服务器有不稳定因素，原来是memcached流量过高产生阻塞，php进程等待链接，导致mysql链接大量等待，这是第一个题目的由来，其实这个题目本身没有标准答案，但是应该有一个意识，当你在一个脚本中同时启动A,B两个链接，那么如果你不能保证这两个链接是必然可靠的（通常是无法保障的），那么后者一旦阻塞，就会导致前者大量链接等待，而前者阻塞，通常不会影响后者。所以，这个答案取决于，哪个链接对你的应用更重要，以及哪个链接有更大的并发支撑性。

两道题说到底就是一个意思，当遇到系统问题和故障的时候，多想想一些关联的因素影响，多思考整个架构响应先后过程的逻辑，数据库连接过多，不一定是数据库造成的，web链接过多，也不一定非要去优化webserver，关联因素可能才是根源，解决了根源，表象才会彻底解决。

附录：
PHP的echo为什么这么慢
    作者: Laruence( )
    本文地址: http://www.laruence.com/2010/12/17/1833.html
    转载请注明出处

今天在微薄看到一个转帖, 题目触目惊心《PHP的echo为什么这么慢》,

点进去一看, 大意是说在PHP中echo一个500K的字符串, 会耗时几百ms,

然后作者说打开Apache的压缩以后呢, 速度就快了.

之后, 又看到一个同学, 从HTTP协议入手, 分析了chunked模式和直接传输模式, 意思可能是说, 和分段传输相关…

我在这里不是批评或者驳斥谁, 相关者莫要生气, 我只是害怕误导别人..

echo 一个500K的字符串, 速度慢, 这个和PHP没关系, 也和PHP的实现者C也没关系,, 关系在于IO, IO的速度限制了输出的速度,,

至于说Apache的压缩,,这个,,压缩了, 字符串变小了(字符串的压缩率很大), 自然也就快了(CPU换IO)….

最后, PHP真的很无辜, 和它真没关系..

作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/4892/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！