机能优化的常见观念

吞吐量（TPS, QPS）：简朴来说就是每秒钟完成的事务数可能查询数。凡是吞吐量大表白系统单元时间能处理惩罚的请求数越多，所以凡是但愿TPS越高越好
响应时间：即从请求发出去到收到系统返回的时间。响应时间一般不取平均值，而是要去掉不不变的值之后再取均值，劳务派遣管理系统，好比常用的90%响应时间，指的就是去掉了10%不不变的响应时间之后，软件开发，剩下90%的不变的响应时间的均值。从聚类的概念看，其实就是去掉离群点。
错误率：即错误请求数与总请求数之比。跟着压力增加，有大概呈现处理惩罚请求处理惩罚不外来的环境，这时错误数会不绝增加。

三者有极大的关联，任何孤独的数据都不能说明问题。典范的干系是，吞吐量增加时，响应延迟有大概增加，错误率也有大概增加。因此，单拿出一个10w的TPS并不能说明问题。

机能调优的思路

一般环境，调优需要有个前提条件，即无论是用线上的真实流水照旧线下的压力测试让问题扩大化，明明化。
按照这些较量明明的现象去初判问题，收集证据去验证初判功效创立，然后阐明现象发生的原因，并实验办理问题。

1.机能摸底测试

对付新上的系统可能是有过较大代码窜改的系统来说，做一次摸底测试照旧很有须要的。一般来说，期望摸底的测试是一次对单机的压力测试。压力测试可以帮你或许搞清楚系统的极限TPS是几多，在压力上来时有没有袒露一些错误可能问题，系统大抵的资源占用环境是什么，系统大概的机能瓶颈在哪。

如下是一次摸底测试的设置和功效。这是用12000并发用户对10台呆板压测的功效，可以看出，TPS到7w多，平均响应时间为82ms，错误率在2.5%。

从图中还可以获得哪些信息？首先，TPS在后期迅速下落，实际上已经支撑不了如此大的并发量，即进入瓦解区，这里有几个大概，一是系统基础遭受不了如此大的并发量，二是系统中间有问题导致TPS下跌。其次，跟着时间增长，错误率显著增加，说明系统已经处理惩罚不了如此多的请求。团结前面两点以及相对平稳的平均响应时间，大抵可以揣度系统没法遭受如此大的并发。别的，由于是10台呆板，单台的TPS或许在7000多，此后的调优可以以此为依据。
对付应用的特点，也要在这时候阐明出来，即应用大概占用的资源。好比是CPU麋集型应用照旧IO麋集型应用（还可以细分为是磁盘麋集照旧网络 ）

2.界说机能优化的方针

常常听到人说，做本机能优化，吞吐量越高越好；可能做本机能测试，方针TPS是50000。可实际拿到这个信息，可以或许做机能测试吗？这个方针足够清晰吗？
事实上，在我看来，未界说清晰的方针去做机能测试都是耍混混。
机能优化的方针一般是吞吐量到达几多，90%响应时间小于几多，错误率小于几多。同时还需要存眷其他的机能指标，cpu利用环境，内存利用环境，磁盘利用环境，带宽利用环境等。对付摸底测试已经发明问题的，可以针对该问题专门优化，软件开发，好比负载较高，cpu耗损过大，则方针大概是TPS，响应时间以及错误率稳定的环境下低落CPU负载。可能内存增长过快，gc较为频繁，则方针大概是找出大概的内存泄露，可能举办相关的jvm内存调优。总之，方针可以较量机动调解，但必然要明晰。

3.阐明

阐明的进程较为机动，根基上是一千个系统有一千种表示。这里很难一一说明。仅谈谈一些常见的要领，东西以及思路。

针对CPU：

针对cpu的监控，其实linux已经提供了两个较量好用的东西，一个是top，一个是vmstat。关于这两个呼吁就不细说了，参考这里top（http://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/top.html），vmstat（http://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/vmstat.html）
关于cpu主要存眷4个值：us(user), sy(system), wa(wait), id(idle)。理论上他们加起来应该便是100%。而前三个每一个值过高都有大概暗示存在某些问题。

us过高：

a. 代码问题。好比一个耗时的轮回不加sleep，可能在一些cpu麋集计较（如xml理会，加解密，加解压，数据计较）时没处理惩罚好
b. gc频繁。一个较量容易漏掉的问题就是gc频繁时us容易过高，因为垃圾接纳属于大量计较的进程。gc频繁带来的cpu过高常伴有内存的大量颠簸，通过内存来判定并办理该问题更好。
小能力：如何定位us过高的线程并查察它的状态。
a. top呼吁找到耗损us过高的历程pid
b. top -Hp pid找到对应的线程tid
c. printf %x tid转为16进制tid16
d. jstack pid | grep -C 20 tid16 即可查到该线程仓库

sy过高：