伤感星星的天空

   本想写点技术方面的，无奈草稿不在本本上，就随意聊聊了

 朋友的服务器一直还算稳定，安全方面更不需费心，只是前段时间出现的问题确实费了点事，一直对php的概念就是轻量级语言，不像java这种庞大复杂低效的东东，主观上认为其对服务器性能的要求很低，藉这次的问题，技术上的数据让我吃惊，但最大的影响是观念上的。

  一个稳定的平台，需要各方面的保证,一行有Bug的代码，一个不稳定的系统、劣质的硬件，都可能导致灾难性的故障；而一个无性能瓶颈的平台，则是用户获得良好体验的最佳保证，对大网站来说，一台服务器的故障，可能是完全透明的，几秒后用户的访问就被引导到其他的成百上千台服务器中去了，但对小网站来说，一台服务器的故障就是100%的致命故障。

  就这次问题来说　，在线不到2000人，从原有的状态　系统Load 3-16 ， Cpu idle基本 0% (大概数据库30% PHP 60% Web 10%)，ＤＺ论坛页面处理时间为0.7xxx 秒，　经过无数次各种调整，也只能降低一半的Load，离正常的Load 1.0以下还是差很远。

　　到最后，　系统Load为0.xx ,　CPU  Idle 80%以上，DZ论坛页面处理时间降低到0.01xx秒，速度提升了20-50倍左右。

　　说明了两个问题，一个是PHP其实自身本应该集成这种php编译已经代码Cache功能，就如同万能的java一样　（据说php6将要集成一个叫APC的类似eacc的组件进来），这样才能算一个完整的php平台。

　　难怪Zend的商业php平台产品号称提速xxxx%倍的速度，然后拿出来卖钱。

　　另一点说明:　一个小的软件模块或者硬件的瓶颈很可能导致全系统的问题。
   就这个来说：访问请求增加----php进程占用大量CPU-----mysql获得的CPU资源不够----mysql的性能能力下降----php需要更多时间等待mysql-----访问请求更慢完成－－php占用资源无法释放－－－新的访问请求更难获得响应。　仅因为mysql获得的cpu资源不够，而形成恶性循环,性能急剧下降。
　
　　由此可以分析，在CPU和内存等不变的情况下，平台会有一个性能的临界点或者说瓶颈,在这个临界点的前后的性能指标是冰火两重天。

　　在临界点前，所有访问请求都没有瓶颈，平台的每一个部分都以自己最快的速度来处理完毕。

　　在到达临界点后，某个瓶颈部分的的性能下降，同时会导致另一部分的性能下降，互相影响，形成一个急剧下降的整体性能曲线。

　　有了一个缓存后，相当于减少了用户请求，形成一个和上面相反的过程，最终导致整体性能的急剧提升。

由这次的结果来看，这个临界点已被移了很远，不知道下一个瓶颈是在多少访问量？　呵呵


星星一家之言，仅供参考。