Web应用的性能优化思路——找到瓶颈
来源:互联网 发布:移动巡检软件 编辑:程序博客网 时间:2024/05/19 19:44
瓶颈是什么?
一条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网站优化三部曲:应用程序优化、
- Web应用的性能优化思路——找到瓶颈
- Web应用的性能优化思路——找到瓶颈
- Web应用的性能优化思路——找到瓶颈
- Web应用的性能优化思路——找到瓶颈
- Web应用的性能优化思路——找到瓶颈(转载自OSCHINA)
- Web应用性能优化思路
- React 应用的性能优化思路
- .Net+SQL Server企业应用性能优化笔记2——查找瓶颈
- .Net+SQL Server企业应用性能优化笔记4——精确查找瓶颈
- .Net+SQL Server企业应用性能优化笔记—精确查找瓶颈
- 性能测试主要是找到性能的瓶颈和原因
- Web 应用性能优化
- 性能测试:瓶颈定位思路
- Web性能的几个常见瓶颈
- Web app的性能瓶颈分析
- 用python的profile模块找到程序性能瓶颈
- 系统性能优化分析—总体思路
- 解决单机RDBMS的性能瓶颈问题的几个思路
- 两数组求交集元素-C描述
- 解决IntelliJ IDEA 报编译错误Error:(36, 74) java: diamond operator is not supported in -source 1.5 (use -s
- 我一个程序员的工作日作息时间表
- 关键字自动的Python自动化测试书籍
- Linux netstat命令详解
- Web应用的性能优化思路——找到瓶颈
- iOS开发--第三方框架导入方法之CocoaPods
- 消息中间件剖析
- 树上倍增的写法和应用(详细讲解,新手秒懂)
- C# 列表视图
- Windows性能计数器解释
- 欢迎使用CSDN-markdown编辑器
- zookeeper Lilux部署问题
- xshell拖动上传文件至linux服务器