随行付微服务测试.docx

: .
随行付微服务测试之性能测试案例
背景
传统性能测试更多的是以事务为核心更多的是由单个或者多个事。业务优化不包括业务流程本身，还包活实现业务的代码逻辑，此优化场景多用于跑批业务。
微服务架构下分析系统瓶颈下面我将分享在性能测试中，常用的具体分析系统瓶颈的几个方法。
应用系统从性能角度分为CPU密集型应用和10密集型应用，调优的目标是让硬件达到瓶颈而不是软件达到瓶颈，最直观的体现就是TPS上升和监控到的CPU和IObusy使用率达到100%。除非有特殊要求，否则尽可能使硬件使用率高。
CPU不饱和原因有很多，最常用的分析手段是查看线程信息。
1、jps命令查看java进程pid
Lastlog-in:ThuDec611:10:$jps
B004Jps'
5599bpm-
2、jstack-l5599>，这里后缀txt也可以，我习惯用jvisualvm打开，所以后缀是tdumpkjk$jstack-1559?>
3、
[app^test-fkjk$
4、打开文件，查看线程信息，有三种情况：
. 如果线程都是RUNNABLE状态，此时CPU利用率依然不高，说明线程池业务线程数量少，加大线程池线程数量。
. 如果线程状态是BLOCKED，要查该线程等待的锁编号。
. 根据锁编号找到持有锁的线程，再根据信息分析代码问题并优化。
此应用CPU利用率上不去的原因是因为需要压缩的文件过大，压缩时间长，导致其他线程都在等待该线程释放锁，CPU同时间只能处理这一个线程，所以利用率低。
5、如果线程状态是WAITING,要分析是什么原因导致线程等待：
这个线程是因为logback为同步线程锁，线程等待日志写入硬盘，导致CPU利用率上不去，只要把logback改成异步就可以了。
6、IO的问题有两种情况,一种是CPU等待IO；一种是单个磁盘IObusy达到100%，其他磁盘空闲。第一种情况可以采用缓存、异步的方式去解决，这样能解决大部分性能问题。这里主要介绍第二种情况，第二种情况可以进行业务层面的IO分散来保证。就是把写入一个磁盘的文件分散写到多个磁盘上，这样就可以缓解单个磁盘的压力。对于性能人员来说，要定位到具体是哪个文件导致的IO繁忙程度高。在代码的逻辑清晰的情况下，是完全可以知道哪些文件是频繁读写的。但是对性能分析人员，通常是面对一个不是自己编写的系统，有时还是多个团队合作产生的系统。如果可以迅速地把问题到一个段具体的代码，到一个具体的文件，那就可以提高沟通的效率。
iostat命令可以发现IO异常。iotop可以定位具体哪个进程导致io异常。但要定位到具体文件，我们需要先了解一个文件的重要属性：inode。
理解inode，要从文件储存说起。文件储存在硬盘上，硬盘的最小存储单位叫做扇区"（Sector）。每个扇区储存512字节（）。操