SoapUIのパフォーマンス低下: 原因と解決策

要約

SoapUIの動作が遅い原因は、JVMの起動オーバーヘッド、デフォルトのメモリ設定不足、大規模プロジェクトやWSDL解析の遅延にあります。ヒープサイズの調整、WSDLキャッシュ、プロジェクト分割などを実施することで、パフォーマンスは大幅に向上します。しかし、構造的なボトルネックを根本的に解決したい場合は、Javaランタイム不要のApidogのようなツールへの移行も検討すべきです。

Apidogを無料で試してみませんか

💡 Apidogは、ブラウザまたは軽量デスクトップアプリで動作する無料のオールインワンAPI開発プラットフォームです。JVMのオーバーヘッドやメモリチューニングが不要で、クレジットカード不要で今すぐ始められます。

はじめに

SoapUIは動作が遅いことで知られています。起動に30秒以上かかったり、大規模なWSDL解析中のUIフリーズ、数百ステップのテスト実行遅延など、日常的に遭遇します。これはバグではなく、SoapUIの設計上の制約です。

この記事では、SoapUIの遅さの技術的な原因を解説し、各問題に対する具体的な対策をコードや設定例とともに紹介します。改善できる遅延もありますが、ツール自体を見直すべきケースもあります。

根本原因1：JVM起動のオーバーヘッド

SoapUIはJava Swingアプリケーションです。起動時にはJVMの立ち上げ、数百クラスのロード、Spring初期化、UIレンダリングなどが必要です。SSDでも20〜60秒、HDDでは90秒を超えることも。

主な理由:

• JVMの初期化コスト
• Swing UIの初期化

実践的な対策:

• SoapUIを閉じずに常時起動しておく
  
  JVMを一度起動したままにすることで、再起動の遅延を回避できます。

• 高速なSSDにインストールする
  
  クラスロード時のI/Oを最適化します。

• Java 11または17へアップグレードする
  
  soapui.batまたはsoapui.shの先頭でJAVA_HOMEパスを新しいJDKに設定してください。

• AppCDSを有効化
  
  クラスデータ共有で起動時間短縮。
  
  JVM引数例:
  

  -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa

根本原因2：デフォルトのメモリ設定が低すぎる

初期設定ではヒープサイズが小さく、大規模プロジェクトや長時間の実行でGC遅延が発生します。

デフォルト設定例:

-Xms128m
-Xmx768m

ヒープサイズの推奨設定例:

• Windows: <SoapUI_Install>/bin/SoapUI.vmoptions を編集

  -Xms512m
  -Xmx2048m

• macOS: SoapUI.app/Contents/vmoptions.txt または soapui.sh を編集

  JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"

• Linux: <SoapUI_Install>/bin/soapui.sh

  JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"

設定のポイント:

• RAMに余裕があれば-Xmsを512MB以上、-Xmxは2～4GB推奨
• Java 9以上は-XX:+UseG1GCでGCの一時停止を短縮
• -XX:MaxMetaspaceSize=512mでメタスペース肥大化防止

変更の確認方法:
SoapUI再起動後、[Help] → [System Properties]でヒープ値を確認。

根本原因3：大規模なプロジェクトファイル

SoapUIは単一のXMLに全データを保存するため、ファイルが大きいと読み書き遅延が発生します。

遅延の兆候:

• 保存時に数秒フリーズ
• プロジェクトファイルが数MB以上
• プロジェクトのロードに10秒以上かかる

対策:

• プロジェクト分割（Composite Project）
  
  [Project] → [Settings] → [Composite Project]で有効にし、テストスイートごとに個別XMLへ分割。

• 不要なテストケースの削除
  
  使わないテストは削除またはアーカイブ。

• 大きなリクエストボディの外部化
  
  ファイルベースDataSourceでリクエストデータを外部ファイルから読み込む。

• 自動バックアップ無効化
  
  [Preferences] → [UI Settings]で「終了時に保存」の自動バックアップをオフ。

根本原因4：WSDL解析の遅延

プロジェクト起動時やインターフェース展開時にWSDLを再解析します。リモートWSDLや大規模WSDLでは特に遅延が顕著。

対策:

• WSDLをローカルにキャッシュ
  
  インターフェースを右クリック→[Update Definition]で、ローカルファイルパスに変更。

• 定義URLをfile://パスに設定
  

  file:///path/to/your/service.wsdl

• 定義の自動更新を無効化
  
  [Preferences] → [WS-Security Settings]で自動検証オプションのチェックを外す。

• HTTPタイムアウトの増加
  
  [Preferences] → [HTTP Settings]でタイムアウト値を長めに設定。

根本原因5：大規模スイートでのテスト実行パフォーマンス

数百ケース・複雑なスクリプト・多量のアサーションなどで実行が遅くなります。

対策:

• 並列実行の有効化
  
  TestSuiteランナーで「Run test cases concurrently」をオンに。

• 不要なアサーションの削除
  
  意味のないアサーションや重複チェックを削除。

• Groovyスクリプトの最適化
  
  高コストな処理はプロジェクト共通スクリプトにまとめる。

• 応答時間アサーションの慎重な利用
  
  タイムアウト値が長すぎると全体の実行遅延につながる。

• ログ出力の最適化
  
  [Preferences] → [HTTP Settings]でログ内容を絞り、I/O負荷を下げる。

修正できないこと

以下は構造的な制限で、設定変更では根本解決できません。

• Swing UIのパフォーマンス: ネイティブやWebアプリより描画が遅い
• JVMの起動: 完全にゼロにはできない
• シングルスレッドのWSDL解析: 複数スキーマでも並列化不可
• 固定メモリオーバーヘッド: JVM・Swing・Springで一定のメモリ消費

移行を検討する時期

上記対策でもパフォーマンスが不十分な場合、設定での改善には限界があります。

ApidogはNode.jsベースのWebアプリで、JVM不要・数秒で起動し、テスト実行も高速です。SoapUIの起動やUI応答に悩むチームは、JVMのチューニングよりもツール切り替えのほうが効果的です。

注意: ApidogはWSDL解析ができません。WSDLインポートが必要な場合はSoapUIを併用してください。

よくある質問

Q: 大規模プロジェクト（50以上のテストスイート）向けのヒープサイズ推奨は？

A: RAM16GB以上なら、-Xmxは最低2GB、理想は4GB。-Xmsは512MB～1GB。-XX:+UseG1GCも推奨。

Q: 現在のヒープ使用量の確認方法は？

A: [Help]→[System Properties]でJVM引数を確認。-verbose:gcを追加しGCログで状況把握も可能。

Q: JDKを新しくすると性能は上がる？

A: 多くの場合向上します（起動・GC）。ただしSoapUIのバージョンとJDK互換性は要確認。

Q: 長時間テスト後に遅くなるのはなぜ？

A: メモリ断片化やGCオーバーヘッドが増加。-Xmx増加/G1GC利用で緩和し、再起動でリセット。

Q: サーバーモード（ヘッドレス）での実行は効果あり？

A: Swingレンダリング負荷が減り、コマンドラインランナー利用推奨。

Q: ApidogはSoapUIと比較して大規模コレクションをどう処理？

A: クラウド保存とオンデマンドロード、JVM不要のCLIランナーで高速実行。

---

ヒープサイズの見直しだけでも即効性のある改善が見込めます。まずはそこから着手し、必要に応じてその他の最適化やツール移行を検討してください。