关于web系统的瓶颈几点记录

所谓找出瓶颈，就是找出程序中费时最多的部分。要查看各个时间段，从请求进入到我们网络的边界开始，直到响应离开。
 Donald Knuth: 在条件不成熟的情况下贸然进行优化是程序设计中所有罪恶的源泉。如果只是想着要重构X,就能加快这儿的速度，而不去实际测试系统并确认X处于关键路径中，那就是在浪费时间和精力。

关于CPU:
  在不成熟的观察者看来，cpu时间是每个应用程序的主要瓶颈，而实际上，这种情况很少发生，影响程序的主要性能的真正原因是 IO.什么是IO?IO包括了所有的数据移动，数据移动的本质上就是应用程序中所做的一切。和大家的观点相反，cpu处理速度基本上从来不是web应用程序中的瓶颈。如果发现主要瓶颈在cpu,那很有可能在基本设计层面存在问题.(那些少数cpu密集任务除外，如处理图像，视频，音频，加密大段数据等)
  top命令的%CPU列显示每个进程占用cpu的情况，也可以用uptime看一下当前系统的平均负载。

代码性能测试:
  捕捉运行中代码的运行信息用，识别代码中最费时的部分有利于代码的优化。比较简单直接的做法不是在函数运行之前记下当前时间戳，到了函数运行之后再记一下时间，两个时间相差就可以算出当前函数花费时间。对于php程序员来说用xdebug(http://xdebug.org)是一个好的选择,安装了xdebug之后在脚本运行之前调用xdebug_start_profiling(),在脚本调用结束后运行xdebug_dump_function_trace()就可以以html来输出性能测试数据的表格。大家可以一试，很不错。测试代码会大大降低执行速度，如果有一个负载均衡池，可以让一部份的生产流量流经剖析工具。

提高代码运行的速度:
  1.操作码缓存： 在cgi模式下，每执行一次脚本都要编译源代码。可以借助一些工具把源码编码成OPCODE做存起来多次运行,APC缓存是一个好的方案
  2.提高模板反应速度： 与opcode相同的原理，多次编译是浪费时间，模板可以保存编译结果多次调用。在调用时默认会查看源模板文件，如果有更新就重新编译。在很多时候可以关闭检查模板是否更新的开关，减少文件IO.提高反应速度:$smarty->compile_check=0.

关于I/O
  1.磁盘IO:可以通过系统的一些工具更好的了解磁盘的IO情况，可以用iostat查看当前的系统的磁盘IO值.这装命令:sudo apt-get install sysstat
  2.网络IO:网络上的能够达到的带宽受限于当网络中速度最慢的设备。netstat是最好的查看网络状态的命令。网络配置上好的做法是根据网络的用途，为机配置多个子网，这样能提高网络IO的速度，当然这样就要装多个网卡，在简单的web服务器与数据库服务器安装中，可以建一个内部数据流通访问的子网，比如访问数据库。如果有主从复制数据库，也可以单为主从提供一个子网，在一般的系统中好像没有这个必要。
  3.内存IO:内存IO基本不可再提高，不过内存的带宽是线性扩展的，最好的增加内存吞量的办法就是增加更多机器.还有一点要注意的是在选硬件的时候。由于AMD64体系结构在内存DIMM和每个处理器之间都提供一个独立的总线，能够为内存传输提供更多的并行能力。在谈内存的时候不能不谈的一个名字是swap,swap是当操作系统没有足够的空闲物理内存的时候，它将内存的一页交换到磁盘来释放更多的物理内存，当下次需要交换内容时，它被换回物理内存。但是swap是十分缓慢，会影响机器处理的速度。可以用free 或者 vmstat查看机器上swap的使用情况。为了避免使用swap两种比较直接的方案就是提供更多的内存或者少分配一些内存，让一台机器做更少的事情。比如有1G的内存，系统需要100M,如果你运行mysql,你应该在运行时把mysql的运行内存设置成850M就可以了。还有一种比较极端的方案就是禁用swap.

关于数据库：
  在web应用程序中，你往往会发现最大的瓶颈是数据库的吞吐量。数据库的优化是一个很深的学问，在这里就不多说了，等自己研究明白之时与大家分享。
 
 

更新： xdebug_start_profiling xdebug_dump_function_trace，这两个方法只有xdebug1.0支持。2。0之后只输出profiling数据。供其它分析工具用。