DEV Community

Cover image for SoapUI Langsame Leistung: Ursachen und Lösungen
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

SoapUI Langsame Leistung: Ursachen und Lösungen

TL;DR

Die langsame Leistung von SoapUI resultiert aus dem JVM-Start-Overhead, standardmäßig zu niedrigen Speichereinstellungen für große Projekte und Verzögerungen beim WSDL-Parsing. Spezifische Korrekturen (Heap-Größenoptimierung, WSDL-Caching, Projekt-Splitting) können die Geschwindigkeit erheblich verbessern. Wenn Ihr Team ein schnelleres Tool benötigt, das diese Engpässe vollständig vermeidet, läuft Apidog ohne Java-Laufzeitumgebung.

💡Apidog ist eine kostenlose All-in-One-API-Entwicklungsplattform, die in einem Browser oder einer leichtgewichtigen Desktop-App läuft und JVM-Overhead sowie Speichertuning vollständig vermeidet. Testen Sie Apidog kostenlos, keine Kreditkarte erforderlich.

Testen Sie Apidog heute

Einleitung

SoapUI ist langsam. Nach einigen Wochen Nutzung kennen Sie den 30-sekündigen Start, die nicht reagierende Oberfläche beim Parsen großer WSDLs oder das langsame Ausführen umfangreicher Testläufe. Das sind keine Fehler, sondern das Ergebnis der technischen Architektur von SoapUI.

In diesem Leitfaden finden Sie die konkreten technischen Ursachen für die Langsamkeit von SoapUI, praxisnahe Lösungen für jedes Problem und Hinweise, wo die Grenzen liegen. Sie können Vieles optimieren, aber nicht alles – in manchen Fällen hilft nur der Wechsel des Tools.

Grundursache 1: JVM-Start-Overhead

SoapUI ist eine Java-Swing-Anwendung. Beim Start wird eine JVM initialisiert, Hunderte Klassendateien geladen und das Spring-Framework sowie die Benutzeroberfläche gestartet. Selbst auf SSDs dauert das 20–60 Sekunden, auf älteren Systemen noch länger.

Warum passiert das?

Java-Anwendungen verursachen Initialisierungs-Overhead, da die JVM Bytecode interpretieren oder JIT-kompilieren muss. Swing als UI-Framework erhöht die Startzeit weiter.

Lösungen – Schritt für Schritt:

  1. SoapUI geöffnet lassen:

    Schließen Sie SoapUI nicht zwischen den Testruns. Die JVM bleibt im Speicher und die Startzeit entfällt.

  2. Schnelle Festplatte verwenden:

    Falls SoapUI noch auf einer HDD läuft, unbedingt auf eine SSD umziehen – speziell das Laden vieler kleiner Dateien ist auf SSDs deutlich schneller.

  3. Neuere Java-Version nutzen:

    Verwenden Sie Java 11 oder 17 statt 8.

    Prüfen Sie in soapui.bat (Windows) oder soapui.sh (Linux/Mac), welches JDK verwendet wird. Die erste Zeile zeigt den Java-Home-Pfad. Ein Upgrade kann die Startzeit senken.

  4. AppCDS aktivieren:

    Application Class Data Sharing (AppCDS) speichert Klassendaten vorab und verkürzt spätere Starts.

    JVM-Argumente ergänzen:

   -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa
Enter fullscreen mode Exit fullscreen mode

Anleitung zur Einrichtung: JVM-Dokumentation zu AppCDS.

Grundursache 2: Standard-Speichereinstellungen sind zu niedrig

SoapUI wird mit sehr geringen Heap-Einstellungen ausgeliefert, was bei großen Projekten zu ständigen Garbage Collections und Pausen führt.

Standard-Einstellungen (soapui.vmoptions oder soapui.bat):

-Xms128m
-Xmx768m
Enter fullscreen mode Exit fullscreen mode

Das ist auf heutigen Rechnern mit 8–32 GB RAM viel zu wenig.

Heap-Größe erhöhen – so geht’s:

Windows

Datei <SoapUI_Install>/bin/SoapUI.vmoptions anpassen:

-Xms512m
-Xmx2048m
Enter fullscreen mode Exit fullscreen mode

macOS

Datei SoapUI.app/Contents/vmoptions.txt oder in soapui.sh:

JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"
Enter fullscreen mode Exit fullscreen mode

Linux

In <SoapUI_Install>/bin/soapui.sh:

JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"
Enter fullscreen mode Exit fullscreen mode

Empfohlene Einstellungen:

  • -Xms: 512 MB oder höher, um häufige Heap-Erweiterungen zu vermeiden.
  • -Xmx: 2 GB für mittlere, 4 GB für große Projekte (nicht mehr als die Hälfte des RAM).
  • -XX:+UseG1GC: Mit Java 9+ für kürzere Pausenzeiten.
  • -XX:MaxMetaspaceSize=512m: Verhindert Metaspace-Wachstum.

Überprüfen:

Nach Neustart Hilfe > Systemeigenschaften öffnen – Heap-Werte prüfen. Alternativ Task-Manager nutzen.

Grundursache 3: Große Projektdateien

Alle SoapUI-Projektinhalte landen in einer XML-Datei. Viele Testsuiten, große Anforderungsdaten und Binärdaten blähen die Datei auf und verlangsamen Öffnen/Speichern.

Typische Symptome:

  • Speichern (Strg+S) dauert mehrere Sekunden.
  • Projektdatei ist mehrere MB groß.
  • Öffnen dauert über 10 Sekunden.

Optimierung – Schritt für Schritt:

  1. Große Projekte splitten:

    Aktivieren Sie zusammengesetzte Projekte:

    Projekt > Einstellungen > Zusammengesetztes Projekt.

    Testsuiten werden als einzelne XML-Dateien gespeichert – schnelleres Laden und Speichern.

  2. Unbenutzte Testfälle entfernen:

    Löschen oder archivieren Sie nicht mehr benötigte Testfälle, um die Projektgröße zu reduzieren.

  3. Große Anforderungsdaten externalisieren:

    Nutzen Sie file-basierte DataSources und lagern Sie große XML/JSON-Daten aus den Testschritten in externe Dateien aus.

  4. "Beim Beenden speichern" deaktivieren:

    In Einstellungen > UI-Einstellungen deaktivieren, um unnötige Backups beim Schließen zu vermeiden.

Grundursache 4: WSDL-Parsing-Verzögerungen

SoapUI parst beim Öffnen von Projekten alle referenzierten WSDLs. Sind diese groß oder liegen auf langsamen Remote-Servern, steigen die Ladezeiten.

Symptome:

  • SoapUI "hängt" beim Erweitern von Schnittstellen.
  • Tests schlagen mit Verbindungs-Timeouts fehl.
  • Unterschiedliche Ladezeiten auf verschiedenen Rechnern.

Lösungen:

  1. WSDLs lokal cachen:

    Rechtsklick auf Schnittstelle → "Definition aktualisieren" → URL auf lokale Datei umstellen.

  2. Definition-URL auf file://-Pfad setzen:

    Beispiel:

   file:///C:/Users/username/wsdl/service.wsdl
Enter fullscreen mode Exit fullscreen mode

oder

   file:///home/user/wsdl/service.wsdl
Enter fullscreen mode Exit fullscreen mode

  1. Automatisches WSDL-Update deaktivieren:

    In Einstellungen > WS-Security-Einstellungen alle Optionen zur WSDL-Validierung beim Start deaktivieren.

  2. HTTP-Timeout erhöhen:

    In Einstellungen > HTTP-Einstellungen Timeout-Werte erhöhen, um Hänger bei langsamen Servern zu verhindern.

Grundursache 5: Testlaufleistung bei großen Suiten

Testläufe mit Hunderten Testfällen werden langsam, vor allem bei komplexen Groovy-Skripten, vielen Assertions oder langsamen Netzwerkaufrufen.

Lösungen:

  1. Testsuiten parallel ausführen:

    Im TestSuite-Runner "Testfälle gleichzeitig ausführen" aktivieren.

    Hinweis: Der SOAP-Server muss parallele Verbindungen unterstützen.

  2. Unnötige Assertions deaktivieren:

    Entfernen Sie nicht benötigte Assertions in jedem Testschritt.

  3. Groovy-Skripte optimieren:

    Vermeiden Sie in Skripten teure Operationen (z.B. große Regex, String-Parsing, Objektallokationen).

    Gemeinsame Logik in Projektbibliotheken verschieben.

  4. Antwortzeit-Asserts mit Bedacht nutzen:

    SLA-Asserts blockieren die Suite, wenn lange Timeouts gesetzt sind. Verwenden Sie diese sparsam.

  5. Protokollierung reduzieren:

    In Einstellungen > HTTP-Einstellungen überflüssige Logging-Optionen deaktivieren – insbesondere bei großen Suiten.

Was Sie nicht beheben können

Einige SoapUI-Probleme sind architekturbedingt:

  • Swing-UI-Rendering:

    Bleibt immer träger als native oder Web-UIs.

  • JVM-Start:

    Nur reduzierbar, nicht eliminierbar.

  • Sequentielles WSDL-Parsing:

    Keine Parallelisierung möglich, große WSDLs kosten Zeit.

  • Speicher-Overhead:

    JVM, Swing und Spring benötigen selbst im Leerlauf 300–400 MB RAM.

Wann es Zeit ist, weiterzuziehen

Wenn Sie alle Optimierungen umgesetzt haben und SoapUI trotzdem den Workflow ausbremst, ist der Wechsel das Mittel der Wahl.

Apidog läuft als Webanwendung mit Node.js-Backend, komplett ohne JVM. Es startet in Sekunden, benötigt keine lokale Java-Laufzeitumgebung. Besonders bei Startzeit- und UI-Problemen ist ein Toolwechsel effektiver als ständiges JVM-Tuning.

Beachten:

Apidog parst keine WSDL – für das Onboarding neuer SOAP-Dienste ggf. SoapUI weiterhin für den Import nutzen, tägliche Tests aber in Apidog durchführen.

FAQ

Was ist die empfohlene Heap-Größe für SoapUI bei großen Projekten (über 50 Testsuiten)?

Setzen Sie -Xmx auf mindestens 2 GB, idealerweise 4 GB bei 16+ GB RAM. -Xms auf 512 MB bis 1 GB. Nutzen Sie -XX:+UseG1GC für bessere Garbage Collection.

Wie prüfe ich die aktuelle Heap-Nutzung von SoapUI?

Gehen Sie zu Hilfe > Systemeigenschaften. Dort werden JVM-Argumente inkl. Heap gezeigt. Alternativ temporär -verbose:gc zu den Optionen hinzufügen, um GC-Logs im SoapUI-Log zu sehen.

Verbessert ein neueres JDK die SoapUI-Performance?

Ja, meist schon. Startzeit und Garbage Collection sind in Java 11/17 besser als in 8. Prüfen Sie aber die SoapUI-Kompatibilität zur JVM.

Warum wird SoapUI nach langer Nutzung langsamer?

Mit der Zeit steigen Speicherfragmentierung und GC-Overhead. Neustart von SoapUI setzt den JVM-Status zurück. Mehr -Xmx und G1GC helfen, beseitigen das Problem aber nicht ganz.

Bringt SoapUI-Headless-Modus mehr Performance?

Ja, etwas. Mit Flags wie -Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false wird weniger UI gerendert. Für CI/CD immer den Kommandozeilen-Testrunner statt der GUI nutzen.

Wie handhabt Apidog große Sammlungen im Vergleich zu SoapUI?

Apidog speichert Sammlungen in der Cloud und lädt sie bedarfsgesteuert. Das Testen läuft über einen lokalen CLI-Runner ohne JVM-Initialisierung.

Fazit:

Viele SoapUI-Performance-Probleme lassen sich durch Anpassung der Heap-Größe und Konfiguration beheben. Beginnen Sie immer mit der Heap-Anpassung, bevor Sie komplexere Maßnahmen umsetzen.

Top comments (0)