深入了解性能优化

影响一个系统性能的方方面面

一个web应用不是一个孤立的个体，它是一个系统的部分，系统中的每一部分都会影响整个系统的性能

 

常用的性能评价/测试指标

响应时间

提交请求和返回该请求的响应之间使用的时间，一般比较关注平均响应时间。

常用操作的响应时间列表：

操作	响应时间
打开一个站点	几秒
数据库查询一条记录（有索引）	十几毫秒
机械磁盘一次寻址定位	4毫秒
从机械磁盘顺序读取1M数据	2毫秒
从SSD磁盘顺序读取1M数据	0.3毫秒
从远程分布式换成Redis读取一个数据	0.5毫秒
从内存读取1M数据	十几微妙
Java程序本地方法调用	几微妙
网络传输2Kb数据	1微妙

 

并发数

同一时刻，对服务器有实际交互的请求数。

和网站在线用户数的关联：1000个同时在线用户数，可以估计并发数在5%到15%之间，也就是同时并发数在50~150之间。

吞吐量

对单位时间内完成的工作量(请求)的量度

关系

系统吞吐量和系统并发数以及响应时间的关系：

理解为高速公路的通行状况：

吞吐量是每天通过收费站的车辆数目（可以换算成收费站收取的高速费），

并发数是高速公路上的正在行驶的车辆数目，

响应时间是车速。

车辆很少时，车速很快。但是收到的高速费也相应较少；随着高速公路上车辆数目的增多，车速略受影响，但是收到的高速费增加很快；

随着车辆的继续增加，车速变得越来越慢，高速公路越来越堵，收费不增反降；

如果车流量继续增加，超过某个极限后，任务偶然因素都会导致高速全部瘫痪，车走不动，当然后也收不着，而高速公路成了停车场（资源耗尽）。

 

常用的性能优化手段

避免过早优化

不应该把大量的时间耗费在小的性能改进上，过早考虑优化是所有噩梦的根源。

所以，我们应该编写清晰，直接，易读和易理解的代码，真正的优化应该留到以后，等到性能分析表明优化措施有巨大的收益时再进行。

但是过早优化，不表示我们应该编写已经知道的对性能不好的的代码结构。如《4、编写高效优雅Java程序》中的《15、当心字符串连接的性能》所说的部分。

进行系统性能测试

所有的性能调优，都有应该建立在性能测试的基础上，直觉很重要，但是要用数据说话，可以推测，但是要通过测试求证。

寻找系统瓶颈，分而治之，逐步优化

性能测试后，对整个请求经历的各个环节进行分析，排查出现性能瓶颈的地方，定位问题，分析影响性能的的主要因素是什么？内存、磁盘IO、网络、CPU，还是代码问题？架构设计不足？或者确实是系统资源不足？

 

前端优化常用手段

浏览器/App

减少请求数；

使用客户端缓冲；

启用压缩

资源文件加载顺序

减少Cookie传输

CDN加速

反向代理缓存

WEB组件分离

 

应用服务性能优化

 

缓存

网站性能优化第一定律：优先考虑使用缓存优化性能

 

Mark老师的推论：缓存离用户越近越好

缓存的基本原理和本质

 

合理使用缓冲的准则

 

分布式缓存与一致性哈希

 

异步

同步和异步，阻塞和非阻塞

 

常见异步的手段

 

Servlet异步

 

多线程

 

消息队列

 

集群

 

程序

 

代码级别

选择合适的数据结构

 

选择更优的算法

 

编写更少的代码

 

并发编程

充分利用CPU多核，

尽量使用线程池，合理设置线程数量，尽量使用JDK提供的各种并发框架和工具

 

实现线程安全的类，避免线程安全问题

 

同步下减少锁的竞争

缩小锁的范围，减少锁的粒度，锁分段，替换独占锁，读写锁，CAS代替锁，ThreadLocal等等

资源的复用

 

 

减少开销很大的系统资源的创建和销毁

 

单例模式

 

池化技术

JVM

与JIT编译器相关的优化

 

热点编译的概念

 

选择编译器类型

 -server，-client，-XX:+TieredCompilation

 

代码缓存相关

 –XX:ReservedCodeCacheSize=N

 

编译阈值

 

编译线程

 

方法内联

 

逃逸分析

GC调优

 

目的

 

调优的原则和步骤

 

学会阅读GC日志

 

其他与GC相关的参数

 

推荐策略

 

 

调优实战

不同的内存大小

 

不同的GC回收器

 

存储性能优化

尽量使用SSD

 

定时清理数据或者按数据的性质分开存放

 

结果集处理