一个 web 应用不是一个孤立的个体,它是一个系统的部分,系统中的每一部分都会影响整个系统的性能,而并发量就是这个系统最重要的组成部分之一,它最大程度的影响着用户体验度,就像是一条高速公路,在这条高速上奔跑的汽车最关心的不就是这条高速是否会堵车啊,所以在高速设计(系统开发)的时候就要着手考虑这件事,尤其是现在的生活中,很多的朋友在面试的时候也经常被问到一个问题:JVM调优,那不清楚应该怎么处理怎么办,没关系,我来了,看完这篇文章,哪怕你从来没有调优经验也可以和面试官扯皮
个人公众号:Java架构师联盟,每日更新技术好文
话不多说,看重点
1. 常用的性能评价/测试指标
在调优之前,起码你要清楚你再进行调优的时候都要有哪些关注点吧,知己知彼才能百战不殆啊,那我们就来看一下都有哪些常用的性能测试指标
1.1 响应时间
提交请求和返回该请求的响应之间使用的时间,一般比较关注平均响应时间。 常用操作的响应时间列表:
1.2 并发数
同一时刻,对服务器有实际交互的请求数。
和网站在线用户数的关联:1000 个同时在线用户数,可以估计并发数在 5%到 15%之间, 也就是同时并发数在 50~150 之间。
1.3 吞吐量
对单位时间内完成的工作量(请求)的量度
1.4 关系
系统吞吐量和系统并发数以及响应时间的关系:
以高速公路的通行状况:
吞吐量是每天通过收费站的车辆数目(可以换算成收费站收取的高速费), 并发数是高速公路上的正在行驶的车辆数目,响应时间是车速。
车辆很少时,车速很快。但是收到的高速费也相应较少;随着高速公路上车辆数目的增多, 车速略受影响,但是收到的高速费增加很快;
随着车辆的继续增加,车速变得越来越慢,高速公路越来越堵,收费不增反降;
如果车流量继续增加,超过某个极限后,任何偶然因素都会导致高速全部瘫痪,车走不动, 当然后也收不着,而高速公路成了停车场(资源耗尽)。
2. 常用的性能优化手段
在知道了常用的性能优化测评的指标之后,那我们看一下平时的时候都会有哪些相应的优化手段,这样,两方进行结合,就是我们的最佳的优化手段
2.1 避免过早优化
不应该把大量的时间耗费在小的性能改进上,过早考虑优化是所有噩梦的根源。
所以,我们应该编写清晰,直接,易读和易理解的代码,真正的优化应该留到以后,等到性能分析表明优化措施有巨大的收益时再进行。
但是过早优化,不表示我们应该编写已经知道的对性能不好的的代码结构。
2.2 进行系统性能测试
所有的性能调优,都有应该建立在性能测试的基础上,直觉很重要,但是要用数据说话,可 以推测,但是要通过测试求证。
2.3 寻找系统瓶颈,分而治之,逐步优化
性能测试后,对整个请求经历的各个环节进行分析,排查出现性能瓶颈的地方,定位问题, 分析影响性能的的主要因素是什么?内存、磁盘 IO、网络、CPU,还是代码问题?架构设计不足?或者确实是系统资源不足?
2.4 前端优化常用手段
2.4.1 浏览器/App
1、减少请求数;
2、合并 CSS,Js,图片使用客户端缓冲;
3、静态资源文件缓存在浏览器中,有关的属性 Cache-Control 和 Expires
4、如果文件发生了变化,需要更新,则通过改变文件名来解决。 启用压缩
5、减少网络传输量,但会给浏览器和服务器带来性能的压力,需要权衡使用。 资源文件加载顺序
6、css 放在页面最上面,js 放在最下面减少 Cookie 传输
7、cookie 包含在每次的请求和响应中,因此哪些数据写入 cookie 需要慎重考虑给用户一个提示,有时候在前端给用户一个提示,就能收到良好的效果。毕竟用户需要的是不要不理他。
2.4.2 CDN 加速
CDN,又称内容分发网络,本质仍然是一个缓存,而且是将数据缓存在用户最近的地方。 无法自行实现 CDN 的时候&#