选择soapUI做性能测试，这就是悲剧的开始

      网上也有不少资料提到了作为接口测试工具的soapUI也可以做性能测试。的确如此，soapUI可以模拟多个请求并发，用过循环反复执行，达到了给系统压力传递的目的。不过比起传统的性能测试工具，还是有天然的不足，最明显的就是对于性能测试结果，必须手工做统计。这还是可以克服的，一般比较关注的请求相应时间，可以通过程序中记录请求发出时间和收到相应时间做统计，然后还可以算出系统的吞吐量。还有一个不太好的，就是难以精确控制请求的并发数，像其他性能测试软件，可以精确地控制每秒发出的请求数，而soapUI这点是难以做到的，幸好有时候这并不是非常重要。

      可以说，对测试程序做一系列的加工后，soapUI还是可以作为性能测试工具的，但这只是悲剧的开始。测试过程中，发现系统的某一段时间内，相应特别慢，而监控显示系统资源使用没有什么异常，处理线程也是空闲状态。于是，又查了数据库的监控，系统资源正常，缓存命中率正常，SQL语句正常，等待事件正常，确实是没有问题。

      其实，问题就是出在soapUI本身。soapUI本身也是可以用JVM的监控工具进行监控的，比如jdk自带的jvisualVM，jconsole、jstat等工具。发现soapUI的full gc特别频繁，增加了jvm的内存，可内存最大值又上不去，还是那么多的full gc，这必然导致系统变慢。后来，又发现系统响应慢的那段时间，soapUI的并发线程出现了大量的资源竞争，虽然不是死锁，但大部分的执行线程都处于blocked状态，或许soapUI的线程管理不怎么样吧，经不起大并发量的考验。

      总之soapUI做性能测试有很多先天不足，还是要选专业的性能测试工具才靠谱。