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

TL;DR

SoapUI’s slow performance comes from JVM startup overhead, default memory settings that are too low for large projects, and WSDL parsing delays. Specific fixes (heap size tuning, WSDL caching, project splitting) can meaningfully improve speed. If your team needs a faster tool that avoids these bottlenecks entirely, Apidog runs without a Java runtime.

💡

Apidog is a free, all-in-one API development platform that runs in a browser or lightweight desktop app, avoiding JVM overhead and memory tuning entirely. Try Apidog free, no credit card required.

button

Introduction

SoapUI is slow. If you have used it for more than a few weeks, you have experienced the 30-second startup, the unresponsive UI while parsing a large WSDL, or the test run that crawls when you have hundreds of test steps. These are not bugs. They are the natural result of how SoapUI was built.

This guide explains the specific technical reasons SoapUI is slow, gives you concrete fixes for each, and explains where the limits are. Some slowness you can fix. Some you cannot without switching tools.

Root cause 1: JVM startup overhead

SoapUI is a Java Swing application. Every time you launch it, it starts a Java Virtual Machine (JVM), loads hundreds of class files, initializes the Spring framework, loads your project, and renders the Swing interface. On a modern machine with an SSD, this takes 20-60 seconds. On older hardware, it can exceed 90 seconds.

Why this happens: Java applications pay a startup cost that native applications do not. The JVM needs to interpret or JIT-compile bytecode before execution begins. Swing UI initialization adds to that.

Fixes:

Keep SoapUI open. The simplest fix is to not close it between test runs. Once the JVM is running, it stays warm.

Use a fast disk. If you are running SoapUI from a spinning hard disk, move it to an SSD. The class-loading phase reads many small files, which is exactly where SSDs outperform HDDs.

Use Java 11 or 17 instead of 8. Newer JVM versions have improved startup times. Check which JDK SoapUI is configured to use in soapui.bat (Windows) or soapui.sh (Linux/Mac). The first line sets the Java home path. Switching to a newer JDK can reduce startup time.

Enable AppCDS (Application Class Data Sharing). This JVM feature pre-caches class loading data. It requires a one-time setup but reduces subsequent startup times. Add -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa to your JVM arguments.

Root cause 2: default memory settings are too low

SoapUI ships with low default heap size settings. Opening a large project or running a long test suite causes the JVM to spend time on garbage collection, which pauses the application and makes it feel sluggish.

Default settings (from soapui.vmoptions or soapui.bat):

-Xms128m
-Xmx768m

This means SoapUI starts with 128 MB of heap and can use a maximum of 768 MB. Modern machines have 8-32 GB of RAM. Leaving SoapUI at 768 MB causes constant garbage collection pressure on any large project.

Fix: increase heap size

On Windows, edit <SoapUI_Install>/bin/SoapUI.vmoptions:

-Xms512m
-Xmx2048m

On macOS, edit the SoapUI.app/Contents/vmoptions.txt or find soapui.sh:

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

On Linux, edit <SoapUI_Install>/bin/soapui.sh:

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

Recommendations:

Set -Xms (initial heap) to 512 MB or higher if you have RAM to spare. This avoids gradual heap expansion.
Set -Xmx (max heap) to 2 GB for medium projects, 4 GB for large ones. Do not set it to more than half your available RAM.
Add -XX:+UseG1GC if you are using Java 9+. G1GC reduces pause times compared to the default garbage collector.
Add -XX:MaxMetaspaceSize=512m to prevent metaspace (class metadata) from growing unbounded.

Verifying the fix: After restarting SoapUI, open the Help > System Properties dialog. You should see the updated heap values. Monitor task manager to confirm SoapUI is using the new allocation.

Root cause 3: large project files

SoapUI stores everything in a single XML file. Projects with many test suites, large request bodies, or inline binary data bloat this file. Opening and saving a 10 MB project file is noticeably slower than a 500 KB one.

Signs of this problem:

SoapUI pauses for several seconds when you save (Ctrl+S)
The project file on disk is several megabytes
Opening the project takes more than 10 seconds after SoapUI is already running

Fixes:

Split large projects. SoapUI supports composite projects that store test suites as separate XML files in a directory. Enable this in Project > Settings > Composite Project. This allows partial loading and faster saves.

Remove unused test cases. Archive or delete test cases that are no longer relevant. Each test case with scripts and request data adds to the XML size.

Externalize large request bodies. If your test steps use large XML or JSON bodies inline, consider parameterizing them and loading from external files using SoapUI’s file-based DataSource.

Disable “save on exit” auto-backup. SoapUI creates backup copies on exit. Disable this in Preferences > UI Settings to avoid the extra disk write on close.

Root cause 4: WSDL parsing delays

When SoapUI opens a project that references WSDL files, it can re-parse those WSDLs on startup or when you expand the interface tree. If your WSDLs are hosted on a remote server or are large (many operations, complex types), this parsing adds significant delays.

Signs of this problem:

SoapUI hangs or shows a spinning indicator when expanding an interface
Tests fail with connection timeout errors before they start
Different machines load the project at different speeds (network dependency)

Fixes:

Cache WSDLs locally. In SoapUI, right-click on an interface > Update Definition. Change the definition URL to point to a local file copy of the WSDL instead of the remote URL. This eliminates network latency on each load.

Set definition URLs to file:// paths. Once you have a local copy of the WSDL, update the interface definition URL to file:///path/to/your/service.wsdl. SoapUI loads this from disk instantly.

Disable definition auto-update. In Preferences > WS-Security Settings, uncheck options that force WSDL re-validation on startup.

Increase HTTP timeout settings. If network WSDLs are slow to respond, go to Preferences > HTTP Settings and increase the connection timeout. This prevents SoapUI from hanging indefinitely on a slow WSDL server.

Root cause 5: test run performance on large suites

Running a test suite with hundreds of test cases can be slow, especially when each test step has complex Groovy scripts, assertions, or network calls.

Fixes:

Run suites in parallel. SoapUI supports parallel test suite execution. In the TestSuite runner, enable the “Run test cases concurrently” option. Ensure your SOAP service handles concurrent connections.

Disable unnecessary assertions. Each assertion SoapUI evaluates adds processing time. Audit your test steps and remove assertions that are not checking anything meaningful.

Optimize Groovy scripts. Groovy scripts run interpreted in SoapUI. Avoid expensive operations in scripts that run for every test step (string parsing, regex, large object creation). Move shared logic to project-level script libraries.

Use response time assertions carefully. Response SLA assertions wait for the full timeout before failing. If you have tight SLA assertions with long timeouts on unreliable endpoints, they can block the entire suite.

Reduce logging verbosity. SoapUI logs every request and response by default. For large suites, this I/O adds up. Go to Preferences > HTTP Settings and reduce what gets logged during test runs.

What you cannot fix

Some SoapUI performance issues are structural. No amount of tuning changes:

Swing UI rendering. The interface will always feel slower than a native or web app. Swing was state-of-the-art in 2000. It is not now.
JVM startup. You can reduce it. You cannot eliminate it.
Single-threaded WSDL parsing. SoapUI parses WSDLs sequentially. Large, complex WSDLs with many imported schemas take time, and there is no parallelism to configure.
Memory overhead. The JVM, Swing, and the Spring framework together consume memory regardless of project size. 300-400 MB at idle is typical.

When to move on

If you have applied the fixes above and SoapUI is still blocking your workflow, the bottleneck may not be fixable through configuration.

Apidog runs as a web application backed by a Node.js client, not a JVM. It opens in seconds. Test execution does not require a Java runtime on your machine. For teams whose primary bottleneck is SoapUI’s startup time and UI responsiveness, switching tools is more productive than ongoing JVM tuning.

The trade-off: Apidog does not parse WSDL. If you depend on SoapUI’s WSDL import for new service onboarding, you may want to keep SoapUI available for that specific task while running day-to-day testing in Apidog.

FAQ

What is the recommended heap size for SoapUI with a large project (50+ test suites)?Set -Xmx to at least 2 GB, ideally 4 GB if your machine has 16 GB or more of RAM. Set -Xms to 512 MB to 1 GB to avoid gradual heap expansion. Use -XX:+UseG1GC for better garbage collection behavior.

Can I check SoapUI’s current heap usage?Yes. Go to Help > System Properties. This shows JVM arguments including heap settings. You can also add -verbose:gc to the JVM options temporarily to see garbage collection activity in the SoapUI log.

Does switching to a newer JDK improve SoapUI performance?In most cases, yes. JVM startup time and garbage collection have improved in Java 11 and 17 compared to Java 8. Check SoapUI’s release notes for the recommended JDK version, as some newer JDK versions have compatibility issues with older SoapUI releases.

Why does SoapUI slow down after running tests for a few hours?Memory fragmentation and garbage collection overhead increase over time. Closing and reopening SoapUI resets the JVM state. Increasing -Xmx and using G1GC delays this degradation but does not eliminate it.

Does running SoapUI on a server (headless) improve performance?Yes, somewhat. Headless mode (-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false and similar flags) reduces Swing rendering overhead. Use the command-line testrunner for CI/CD instead of the GUI for the best performance.

How does Apidog handle large collections compared to SoapUI?Apidog stores collections in the cloud and loads them on demand. There is no local XML file to parse. Test execution uses a local CLI runner that does not require JVM initialization.

Most SoapUI performance problems have fixes. The heap size change alone often has an immediate, visible effect. Start there before trying more complex solutions.