Web应用的性能优化思路——找到瓶颈
瓶颈是什么?
一条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网站优化三部曲:应用程序优化、系统结构优化、网络优化。
本文适合菜鸟阅读,因为我也是菜鸟。
不说了,等待拍砖。