性能测试

系统性能定义

1.Throughtput，吞吐量。每秒钟可以处理的请求数，任务数。
2.Latency，系统延迟。系统在处理一个请求或一个任务时的延迟。

image.png

两者的关系：

• throughput越大，Latency越差。因为请求过多，系统繁忙，自然响应速度会降低。
• latency越好，能支持的Throughput越高。latency短说明系统处理速度快，自然便可以处理更多的请求。

---

要说明一个系统的性能，便需要收集系统的Throughput和Latency两个值。

• 首先，需要定义Latency这个值。这个值的意义不是普适性的，需要根据不同的业务来定义，比如一些实时系统，需要的latency便会很短，如5ms。
• 其次，开发性能测试工具。一个用来制造高强度的Throughput，另一个用来监测latency。对一个工具可以用很多现有开源的或者商业的。
  latency可以通过在代码中打日志测量，但是会影响到程序的执行，而且也只能看到代码内部的latency，无法计算到线上系统的。对于网络延迟可以使用一些抓包工具。
• 最后，开始性能测试。不断的调整throughput，观察系统负载，观察latency。找到系统的最大负载并且知道系统的响应延迟是多少。

定位性能瓶颈

当在测试过程中，发现性能有问题时，不用急于去怀疑代码。首先要查看操作系统的报告，查看OS的cpu使用率，内存使用率，查看系统IO和网络的IO，网络连接数。通过观察以上数据，基本可以判断出性能问题出在哪。

1. CPU使用率。如果使用率不高，但是Throughput和latency上不去，说明我们的程序没有忙于计算，而是干了别的事情，比如IO。
2. 然后可以看下IO大不大，IO和CPU一般反着来，CPU利用率高则IO低，IO大则CPU小。IO看三个点，磁盘文件IO，驱动程序的IO，内存换页率。
3. 查看网络带宽状态。
4. 如果CPU不高，IO不高，内存使用不高，网络带宽使用不高，但是系统性能上不去，说明程序可能有问题。比如程序被阻塞，或者是一些数据库的索引未建立。

性能测试结果的分析：
结合jmeter的测试报告

image.png
上图是一个jmeter的测试报告，在报告中，有平均响应时间和90%，95%，99%的响应时间。
首先给结论：平均值不靠谱
再来说说为什么，在进行性能测试时，得到的结果数据不会都一样，而是有高有低。例如测试了10次，有9次都是1ms，但是第十次的时间是2s，那么平均值就是200.9，很明显这个并不能正确反映我们系统的性能。这个2s，应该作为一个异常值去除掉。就好像体育比赛一样，很多项目评委打分时，是需要去掉一个最高分和最低分的。
设备指纹4.x的版本中，js集成在server中，当页面集成了js时，需要先下载js，然后才是使用js拿到设备指纹。第一次下载后，js便会缓存在本地，方便以后调用就不需要每次都去下载js了。
而下载js便会受到网络的影响。在测试时，经常下载js会达到秒级。所以在性能测试时，需要将下载js的这个动作不纳入统计中。
正确的统计是使用百分比分布统计
然后继续看上面的图，99%Line；
这个就是表示99%的请求均小于某值，在测试过程中，应该重点关注这样的数据结果。

常见系统瓶颈

代码调优

• 类型转换。
  之前在3.x的设备指纹中，出现过严重的性能下降问题，后来定位发现，是在类型转换时用了fastjson的一个方法，导致系统时间大量的耗在上面了。
• 异步操作。有些同步操作，会非常影响性能，尤其在网络较差的情况下，很可能阻塞我们的业务。使用异步，可以提升性能但是会带来编码上的复杂性。异步下的状态通知通常是个问题，比如消息事件通知方式，有回调方式等，这些方式同样可能会影响性能。但是通常来说，异步操作会让性能的吞吐率有很大提升（Throughput），但是会牺牲系统的响应时间（latency）。
  现在4.5的设备指纹中，便将以前的同步日志改成了异步写日志。
• IO模型调优
  之前在学习netty的过程中，了解了几种不同的网络IO模型，这个需要根据自己的业务情况选择合适的IO模型。

系统调优

• 多核CPU调优。之前在使用mongo的时候，每次进入mongo shell ，总是会打印几串warning，由于平时是只看error忽略warning的，就没太在意。后来线上性能除了问题，才注意看了那几个warning。其中一个就是NUMA。
  NUMA技术（Non-Uniform Memory Access）。
  NUMA的相关策略：

1. 每个进程（或线程）都会从父进程继承NUMA策略，并分配有一个优先node。如果NUMA策略允许的话，进程可以调用其他node上的资源。
   简单点说，在有多个物理CPU的架构下，NUMA把内存分为本地和远程，每个物理CPU都有属于自己的本地内存，访问本地内存速度快于访问远程内存，缺省情况下，每个物理CPU只能访问属于自己的本地内存。对于MongoDB这种需要大内存的服务来说就可能造成内存不足

网络调优

• TCP调优
  TCP链接一是会占用文件描述符，另一个是会开缓存，一般来说一个系统可以支持的TCP链接数是有限的，TCP链接对系统的开销是很大的。正是因为TCP是耗资源的，所以对于TCP的链接数量需要关注。当过多时，很可能大量消耗资源导致系统无响应。之前线上反馈，服务端的链接数过多，后来排查发现，是因为安卓sdk使用了HTTP1.1，默认开启的是keepalive长连接导致的链接不释放。
  所以，我们要注意配置KeepAlive参数，这个参数的意思是定义一个时间，如果链接上没有数据传输，系统会在这个时间发一个包，如果没有收到回应，那么TCP就认为链接断了，然后就会把链接关闭，这样可以回收系统资源开销。（注：HTTP层上也有KeepAlive参数）对于像HTTP这样的短链接，设置一个1-2分钟的keepalive，这可以在一定程度上防止DoS攻击。
  数据库调优
  传统的关系型数据库不太了解，对于NOSQL数据库，例如mongodb，需要关注索引的情况。之前在测试设备指纹的时候，便出现了系统性能越跑越慢的情况，后来发现是索引建立不全导致的。