做完性能测试，多多少少我们都会发现一些问题，那么我们怎样去trouble shooting呢？ 这个也是性能测试中非常重要的一个方面。
废话少说，我们直接来看几个例子吧：
内存泄露
内存泄露是性能测试中很常见的一个点，比如下图，很明显能看到有一个内存上升的趋势，这种情况下很可能就有内存泄露的情况。 但是也有例外，比如是C#或者Java写的代码，因为内存回收是垃圾回收器自己的行为，不像C语言那样需要手动回收，所以即使内存在一段时间内有上升的趋势，但是只要能回到原点，就不存在内存泄露的现象。
内存泄露很多时候并没有很明显的征兆，有一次客户抱怨服务挂掉了，这个服务之前有好几个月都运行的好好的，怎么说挂就挂呢，然后我们对系统日志做了很详细的分析，发现就是内存泄露惹的祸。每天内存泄露一点点，到第三个月的时候才导致服务崩溃，这在短期的性能测试中就很难发现。
下图是当时我们在做性能测试的时候发现的问题，很明显内存在一段时间内直接从200多MB升到了500多MB，很有可能存在内存泄露的情况。怎样trouble shoooting呢？
我们借助了第三方的工具ANTS，最终有下面的结果，很明显Sting类变成了最大的类，高达211MB，这个是什么原因造成的呢？
然后我们在工具上找了String object的调用链，最终发现代码中有一行的判断错误，导致了内存上升，如下，把S2STransactionId改成TransNo，问题得到了解决。
API相应速度慢
这是一个很常见的问题，单单看现象，其实我们并不知道系统是哪里出的问题，有可能是网络慢，有可能是内存出现了瓶颈，也有可能是I/O的问题... 怎样定位呢？
首先我们还是找到相应的apiserver，通过性能测试的报告，我们发现了下面的问题，message queue随着时间的变化增长特别快，这个时候看API server本身的内存和CPU并没有什么问题，那么问题到底处在哪呢？
这个时候其实很容易就联想到是数据库出现了问题，对比两个不同的版本，我们发现我们对数据库的存储过程有所更改，最终发现是存储过程的更改导致了某个索引失效，最终反映到API就是速度明显变慢。添加索引后问题得到了解决。一般来说，当我们在修改数据库的时候一定要特别小心，很可能一个小的改动就会导致系统性能的急剧下降
对于性能测试来说，往往我们发现的问题都是表象上的问题，比如页面反应很慢。但这有可能是多种原因导致的，需要去做深入的分析。这也要求我们在做性能测试时去收集足够的信息，以支撑我们的分析，同时借助一些第三方工具，才能真正定位到问题。
网友评论