DEV Community

Preecha
Preecha

Posted on

SoapUI Slow Performance: Why It Happens and How to Fix It

#api #performance #testing #tooling

TL;DR

SoapUI’s slow performance is primarily due to JVM startup overhead, low default memory settings, and delays when parsing large WSDLs. You can address these issues by tuning heap size, enabling WSDL caching, and splitting large projects. However, some bottlenecks, like Swing UI rendering and JVM startup, are inherent. If you need a faster alternative, Apidog operates without a Java runtime.

Try Apidog today

Introduction

SoapUI can be frustratingly slow: 30-second startups, UI freezes when parsing large WSDLs, and sluggish test runs with complex projects. These issues are not bugs—they’re the result of architectural choices.

This guide breaks down why SoapUI is slow, actionable steps to improve performance, and what remains unfixable. For some limits, switching tools is the only way forward.

Root Cause 1: JVM Startup Overhead

SoapUI is a Java Swing app. Launching it means starting a JVM, loading hundreds of class files, initializing Spring, and rendering the UI. Even on modern SSD hardware, expect 20–60 seconds to launch, longer on older disks.

Why:

Java apps incur startup costs: JVM initialization, bytecode interpretation/JIT, and Swing UI setup.

Actionable Fixes:

  • Keep SoapUI Open: Don’t close it between runs; the JVM stays warm.
  • Run from SSD: Move SoapUI to an SSD for faster class loading.
  • Upgrade Java Version: Use Java 11 or 17 instead of Java 8 for improved startup times.
    • Check the JAVA_HOME path in soapui.bat (Windows) or soapui.sh (Linux/Mac).

  • Enable AppCDS (Class Data Sharing):

    Add these JVM args:

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

AppCDS requires a one-time setup but speeds up subsequent launches.

Root Cause 2: Default Memory Settings Are Too Low

SoapUI’s default heap settings are minimal, causing the JVM to spend excessive time on garbage collection for large projects.

Defaults:

-Xms128m
-Xmx768m
Enter fullscreen mode Exit fullscreen mode

This is insufficient for modern machines and large projects.

How to Increase Heap Size:

  • Windows:

    Edit <SoapUI_Install>/bin/SoapUI.vmoptions

    -Xms512m
-Xmx2048m

  • macOS:

    Edit SoapUI.app/Contents/vmoptions.txt or locate soapui.sh

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

  • Linux:

    Edit <SoapUI_Install>/bin/soapui.sh

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

Recommendations:

  • Set -Xms (initial heap) to 512 MB+.
  • Set -Xmx (max heap) to 2 GB (medium projects) or 4 GB (large projects), but never more than half your RAM.
  • Add -XX:+UseG1GC (Java 9+) for reduced pause times.
  • Add -XX:MaxMetaspaceSize=512m to cap metaspace growth.

Verify:

  • Restart SoapUI.
  • Check Help > System Properties for updated heap values.
  • Use your OS task manager to confirm increased RAM usage.

Root Cause 3: Large Project Files

SoapUI stores projects as single XML files. Large numbers of test suites, big request bodies, or inline binary data can bloat these files, making open/save operations slow.

Symptoms:

  • Long pauses when saving (Ctrl+S)
  • Project file size is several MBs
  • Opening the project takes >10 seconds after SoapUI is running

How to Optimize:

  • Split large projects:

    Use composite project mode.

    Project > Settings > Composite Project

    This stores each test suite as a separate XML file for faster loading/saving.

  • Remove unused test cases:

    Archive or delete obsolete cases to shrink XML.

  • Externalize large request bodies:

    Move big XML/JSON bodies to external files and use SoapUI’s file-based DataSource.

  • Disable auto-backup:

    Preferences > UI Settings

    Turn off “save on exit” auto-backup to avoid extra disk writes.

Root Cause 4: WSDL Parsing Delays

SoapUI re-parses WSDL files on startup or interface expansion. Large or remote-hosted WSDLs cause slowdowns.

Symptoms:

  • Hanging or spinning indicator when expanding an interface
  • Connection timeouts before tests start
  • Project loads at different speeds on different networks

How to Fix:

  • Cache WSDLs locally:

    • Right-click interface > Update Definition
    • Change the definition URL to a local file path

  • Use file:// URLs:

    • Update WSDL definition to file:///path/to/your/service.wsdl for disk-based loading

  • Disable definition auto-update:

    • Preferences > WS-Security Settings
    • Uncheck options that force WSDL re-validation on startup

  • Increase HTTP timeouts:

    • Preferences > HTTP Settings
    • Raise connection timeout to prevent hangs on slow servers

Root Cause 5: Slow Test Runs on Large Suites

Large suites with many test cases, heavy scripts, or lots of assertions can run slowly.

Actionable Steps:

  • Enable parallel execution:

    • In the TestSuite runner, check “Run test cases concurrently”
    • Make sure your backend supports parallel connections

  • Audit assertions:

    • Remove unnecessary assertions to reduce evaluation time

  • Optimize Groovy scripts:

    • Minimize expensive operations (e.g., avoid heavy regex in tight loops)
    • Move shared logic to project-level script libraries

  • Review response time assertions:

    • Avoid long SLA assertions on unreliable endpoints, as they can block the suite

  • Reduce logging:

    • Preferences > HTTP Settings
    • Lower logging verbosity to decrease I/O overhead

What You Cannot Fix

Some SoapUI performance issues are architectural:

  • Swing UI rendering: The interface is inherently slower than modern native/web UIs.
  • JVM startup overhead: Can be reduced, not eliminated.
  • Single-threaded WSDL parsing: No parallelism; large WSDLs will always take time.
  • Base memory consumption: JVM, Swing, and Spring framework use 300–400 MB at idle.

When to Move On

If after all optimizations SoapUI still blocks your workflow, consider switching tools.

Apidog is a web application backed by a Node.js client—no JVM required, fast startup, and responsive UI. Test execution does not depend on Java. If startup and UI lag are your main issues, switching is more productive than continued JVM tuning.

Note: Apidog does not parse WSDL. If you rely on SoapUI’s WSDL import for onboarding new services, keep SoapUI available for that purpose while using Apidog for daily testing.

FAQ

Q: What heap size is recommended for large SoapUI projects (50+ test suites)?

A: Set -Xmx to at least 2 GB (4 GB if you have 16 GB+ RAM). -Xms should be 512 MB–1 GB. Use -XX:+UseG1GC for improved GC.

Q: How can I check SoapUI’s current heap usage?

A: Use Help > System Properties to view JVM arguments and heap settings. For GC activity, add -verbose:gc to JVM args to log garbage collection events.

Q: Does using a newer JDK improve performance?

A: Usually, yes. Java 11/17 provide better startup and GC performance than Java 8. Always check SoapUI’s compatibility notes for your version.

Q: Why does SoapUI slow down after hours of testing?

A: Memory fragmentation and GC overhead can build up. Restarting SoapUI resets the JVM. Higher -Xmx and G1GC help but do not fully prevent this.

Q: Is SoapUI faster in headless/server mode?

A: Somewhat. Headless mode reduces Swing overhead. For CI/CD, prefer the command-line testrunner over the GUI.

Q: How does Apidog handle large collections compared to SoapUI?

A: Apidog stores collections in the cloud and loads them on demand. No local XML parsing; test execution uses a local CLI runner without JVM startup.

Most SoapUI performance issues can be improved with heap size tuning and project organization. Start with heap changes for immediate gains, then address project and WSDL management as needed. For persistent UI and startup delays, consider modern alternatives like Apidog.

Top comments (0)