1、高性能指标

1.1 并发连接数

1.2 响应时间

1.3 吞吐量

1.4 响应时间&并发数&吞吐量之间的关系

2、JMeter压力测试

3、系统实时性能

4、性能优化基本原则

4.1 避免过早优化

4.2 进行系统性能测试

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

5、性能优化常用手段

5.1 浏览器/APP优化手段

5.1.1 减少网络请示数

5.1.2 使用压缩

5.1.3 使用客户端缓存

5.1.4 改变资源文件的加载顺序

5.1.5 减少Cookie的传输

5.1.6 用户交互友好提示

5.2 CDN 加速

5.3 反向代理缓存

5.4 WEB服务器端的优化手段

5.4.1 缓存

5.4.2 异步

5.4.3 集群

5.4.4 程序代码单元

5.4.5 并发编程

5.4.6 JVM优化

5.4.7 数据库优化

5.4.8 WEB容器优化

1、高性能指标

高性能指标

1.1 并发连接数

并发连接数是指，在同一时刻，向服务器发出的请示个数，一般是指业务高峰期的一个峰值，它与在线用户数是有一定的关系，一般并发连接数是在线用户数的5%-15%，例如，
一个WEB应用有1000个用户在线，可以估算并发连接数在5%-15%之间，也就是50-150之间，这个并发连接数一般需要结合一些监控工具进行实时监控来获取准确的参考值。

1.2 响应时间

下面表格列出一些常用操作的响应时间，以些来评估系统的响应时间：

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

1.3 吞吐量

吞吐量是指单位时间内完成的业务请示数量，是一个量化指标。通过根据请示的类型又可以细分为：TPS(每秒事务请示数)、QPS(每秒查询请示数)。

1.4 响应时间&并发数&吞吐量之间的关系

首先有一个客观约束条件，系统的负载是有极限的，当系统的并发数接近最大并发数时，此时，增加并发数，会引起响应时间快速增加、吞吐量急剧下降；而当系统的负载比较低或者并发数很小时，响应
时间是比较小的，此时随着并发数的增加，吞吐量是增加的。所以它们之间的关系，要参考当时系统负载是处于一个低水位还是高水位，我们也可以理解为物极必反。

2、JMeter压力测试

使用JMeter进行压测系统，将cpu利用率打到90%，观察系统各指标情况。

3、系统实时性能

磁盘IO、网络IO

响应时间

4、性能优化基本原则

4.1 避免过早优化

不应该把大量的时间耗费在小的性能改进上，过早考虑优化是所有噩梦的根源。所以，我们应该编写清晰，直接，易读和易理解的代码，真正的优化应该留到以后，等到
性能分析表明优化措施有巨大的收益时再进行。但是过早优化，不表示我们应该编写已经知道的对性能不好的的代码结构。

4.2 进行系统性能测试

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

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

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

5、性能优化常用手段

5.1 浏览器/APP优化手段

5.1.1 减少网络请示数

通过合并CSS文件、JS文件，来减少浏览器/APP向服务器发出的网络请示数，从而降低响应时间。

5.1.2 使用压缩

当服务端响应内容比较大，通过超过1MB时，并且网络环境不好，带宽不高时，这个时候，可以考虑启用压缩，但是压缩也会引起另一个问题，对内容压缩是需要消耗一定的CPU时间的，在客户端那边进行内容的解压
也是需要消耗CPU时间的，是否启用压缩是需要进行一定的权衡的。

5.1.3 使用客户端缓存

对于一些静态资源来说，内容不会发生变更，这个时候，可以考虑使用客户端缓存，通过HTTP头部字段：Cache-Control、Expires等相关属性进行控制，通过这种手段，避免每次请示静态资源都需要访问服务器减少
访问服务器的次数来优化响应时间。

5.1.4 改变资源文件的加载顺序

一般前端的资源文件有CSS文件、JS文件，而JS文件中内容一般是用户与界面进行交互时才会使用到的，在页面进行加载时，JS文件中代码是不会执行的，所以我们改变JS文件加载顺序来加快页面的渲染，将CSS文件
最先加载，而JS文件放到最后加载。

5.1.5 减少Cookie的传输

用户的上下文数据，我们一般不要存储到客户端的Cookie中，可以选择存储到LocalStorage中，因为Cookie中的数据，在同域中，每次请示都会携带传输，增加了HTTP请示的负载，特别是Cookie中内容比较大的时候，影响
就更为明显，而存储到LocalStorage中，客户端可以自定义按需发送用户数据，这样就避免每次都需要传输一些无用的数据。

5.1.6 用户交互友好提示

在界面上有一些交互动作响应时间是比较长的，这个时候，界面不要一直等待服务器的响应，这个时候，可以在界面上显示一些模态框，数据正在处理中，用稍等，这样给用户一些比较友好的提示，而不是让用户觉得，
系统死机了，长时间不进行响应。

5.2 CDN 加速

CDN，又称内容分发网络，本质仍然是一个缓存，而且是将数据缓存在用户最近的地方。无法自行实现 CDN 的时候，可以考虑商用 CDN 服务。

5.3 反向代理缓存

将静态资源文件缓存在反向代理服务器上，一般是 Nginx。

5.4 WEB服务器端的优化手段

5.4.1 缓存

网站性能优化第一定律：优先考虑使用缓存优化性能。缓存离用户越近越好
缓存的基本原理和本质：缓存是将数据存在访问速度较高的介质中。可以减少数据访问的时间，同时避免重复计算。
合理使用缓冲的准则：
1、频繁修改的数据，尽量不要缓存，读写比 2:1 以上才有缓存的价值。
2、缓存一定是热点数据。
3、应用需要容忍一定时间的数据不一致。
4、缓存可用性问题，一般通过热备或者集群来解决。
5、缓存预热，新启动的缓存系统没有任何数据，可以考虑将一些热点数据提前加载到缓存系统。
解决缓存击穿：
1、布隆过滤器
2、把不存在的数据也缓存起来，比如有请求总是访问 key = 23 的数据，但是这个 key = 23 的数据在系统中不存在，可以考虑在缓存中构建一个( key=23
value = null)的数据，一般设置一个5分钟的过期时间。

5.4.2 异步

同步与异步本质的区别是发起调用的客户端后续的业务流程是否严格依赖调用的返回结果，如果强依赖，则使用同步，否则可以使用异步实现。
同步：调用方需要主动等待结果的返回
异步：不需要主动等待结果的返回，而是通过其他手段比如，状态通知，回调函数、客户端轮询等
常用的异步实现有：异步Servlet、多线程、MQ。

5.4.3 集群

可以将应用服务器构建为一个应用集群来以外提供服务，可以大大地优化分布式系统的响应时间、并发数、吞吐量。一般有一个计算公式，一台单机的吞吐是T，则
N台机器的吞吐量是N * T * 90%，一般集群是有一定比例的管理损耗的，实际不可能达到100%。

5.4.4 程序代码单元

一个应用的性能归根结底取决于代码是如何编写的。选择合适的数据结构与算法；可以进行资源的复用，充分复用池化技术、单例模式，减少开销很大的系统资源的创建和销毁。

5.4.5 并发编程

充分利用现在计算机系统多核CPU的特性，将任务进行逐步分解成可以独立运行的几个子任务，最后将子任务的执行结果进行合并，可以得到整个任务的执行结果，
则任务的执行时间只依赖于耗时最长的那个子任务的执行时间，这种并发编程的手法一般应用在一个任务可以分解成多个耗时的子任务，如果只有一个耗时比较长的子任务，
则性能优化不明显。此外，并发编程需要考虑多线程的并发资源资源竞争问题、线程通信问题。