網上也有不少資料提到了作為接口測試工具的soapUI也可以做性能測試。的確如此，soapUI可以模擬多個請求並發，用過循環反復執行，達到了給系統壓力傳遞的目的。不過比起傳統的性能測試工具，還是有天然的不足，最明顯的就是對於性能測試結果，必須手工做統計。這還是可以克服的，一般比較關注的請求相應時間，可以通過程序中記錄請求發出時間和收到相應時間做統計，然后還可以算出系統的吞吐量。還有一個不太好的，就是難以精確控制請求的並發數，像其他性能測試軟件，可以精確地控制每秒發出的請求數，而soapUI這點是難以做到的，幸好有時候這並不是非常重要。
可以說，對測試程序做一系列的加工后，soapUI還是可以作為性能測試工具的，但這只是悲劇的開始。測試過程中，發現系統的某一段時間內，相應特別慢，而監控顯示系統資源使用沒有什么異常，處理線程也是空閑狀態。於是，又查了數據庫的監控，系統資源正常，緩存命中率正常，SQL語句正常，等待事件正常，確實是沒有問題。
其實，問題就是出在soapUI本身。soapUI本身也是可以用JVM的監控工具進行監控的，比如jdk自帶的jvisualVM，jconsole、jstat等工具。發現soapUI的full gc特別頻繁，增加了jvm的內存，可內存最大值又上不去，還是那么多的full gc，這必然導致系統變慢。后來，又發現系統響應慢的那段時間，soapUI的並發線程出現了大量的資源競爭，雖然不是死鎖，但大部分的執行線程都處於blocked狀態，或許soapUI的線程管理不怎么樣吧，經不起大並發量的考驗。
總之soapUI做性能測試有很多先天不足，還是要選專業的性能測試工具才靠譜。