Web应用的性能优化思路——找到瓶颈
文章链接:http://www.oschina.net/question/12_8639
http://www.oschina.net/question/205650_89077
瓶颈是什么？
一条4车道的公路，运行非常顺畅，突然出了点事故，事故车导致某个地方只剩下1车道，然后就开始堵车，因为四辆车同时塞向一个车道里。把这个事故清除了，故障车拖走了，道路会开始恢复了通畅。
这个道理谁都懂，但偏偏有些傻瓜交警去把4车道变成8车道，但却不清理事故路段。
一个Web应用，不管是何种语言开发，粗略的结构无非是三层：
1. 页面模板
可以是JSP、ASP、PHP等页面技术，根据数据生成最终的HTML页面，性能关键指标只有一个，页面的渲染速度。综合各种页面技术而言，渲染速度相差不会太大，10倍以内。
2. 业务逻辑
用于根据业务需要将数据库中的数据读取到内存中，以便通过页面模板渲染成HTML页面。这里面可能还包括缓存、连接池等技术。
3. 数据库
就是数据库，负责执行SQL查询并返回查询结果。
我们假设用户访问一个页面，也就是请求一个URL地址，然后得到内容，所需要的时间是3秒钟。其中大部分时间可能用在网络传输上，而真正页面执行并生成HTML内容所需的时间是很小的，这里假设需要100毫秒。
相当于用户花了两秒多钟在传输数据上，这部分时间如果能缩减，可以大大提升访问的速度，但是这部分一般也难以提升了，因为取决于用户本身的网络情况，服务器的网络情况以及中间整个路由的情况。对于一个网站来说，能做的就是尽可能的提升服务器的带宽，或者使用CDN来减少中间路由环节，很不幸的是，这个成本很高。
好吧，前面提到的更多是非技术因素，假设你已经耗费巨资解决了这个问题，然后突然发现网络太快了，可是服务器顶不住了，生成一个页面居然要100毫秒，才几十个并发用户就差点要把服务器搞崩溃了。
于是来到了本文的重点部分——找出应用的性能瓶颈。
前面我们提到的结构中的三层：页面模板，业务逻辑和数据库，根据经验值，在这100毫秒中，三个部分占用的时间差不多为：页面模板(5%)、业务逻辑+数据库(95%)。
几个准则：
1. 没必要去优化页面模板，这都是一些很成熟的技术，就算你好不容易提升了10%的性能，这10%在整个页面的执行过程中只占了0.5%的比例，微乎其微，等于是前面例子中的4车道变8车道的傻瓜，我们不要去充当傻瓜。
2. 一般瓶颈所在以及相应处理办法
简简单单的三条，里面却包含了很深的功夫，特别是在数据库查询优化上。
你必须在充分解决了这些应用程序所属的性能瓶颈之后，再去考虑系统级别的优化。
一些常用系统级别优化包括：
1. 静态文件和动态页面分开处理
2. 应用服务器的集群
3. 数据库的集群
不要本末倒置，一个性能很差的应用程序，你就算集群了100个节点，也不会有什么效果。
所以Web网站优化三部曲：应用程序优化、系统结构优化、网络优化。
本文适合菜鸟阅读，因为我也是菜鸟。
不说了，等待拍砖。
