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.

Schaltfläche

Einleitung

SoapUI ist langsam. Wenn Sie es länger als ein paar Wochen benutzt haben, kennen Sie den 30-sekündigen Start, die nicht reagierende Benutzeroberfläche beim Parsen eines großen WSDL oder den Testlauf, der kriecht, wenn Sie Hunderte von Testschritten haben. Dies sind keine Fehler. Sie sind das natürliche Ergebnis der Art und Weise, wie SoapUI gebaut wurde.

Dieser Leitfaden erklärt die spezifischen technischen Gründe, warum SoapUI langsam ist, gibt Ihnen konkrete Lösungen für jedes Problem und erklärt, wo die Grenzen liegen. Eine gewisse Langsamkeit können Sie beheben. Einige können Sie nicht beheben, ohne die Tools zu wechseln.

Grundursache 1: JVM-Start-Overhead

SoapUI ist eine Java-Swing-Anwendung. Jedes Mal, wenn Sie es starten, startet es eine Java Virtual Machine (JVM), lädt Hunderte von Klassendateien, initialisiert das Spring-Framework, lädt Ihr Projekt und rendert die Swing-Oberfläche. Auf einem modernen Rechner mit SSD dauert dies 20-60 Sekunden. Auf älterer Hardware kann es 90 Sekunden überschreiten.

Warum das passiert: Java-Anwendungen verursachen Startkosten, die native Anwendungen nicht haben. Die JVM muss Bytecode interpretieren oder JIT-kompilieren, bevor die Ausführung beginnt. Die Initialisierung der Swing-Benutzeroberfläche trägt dazu bei.

Lösungen:

Lassen Sie SoapUI geöffnet. Die einfachste Lösung ist, es zwischen den Testläufen nicht zu schließen. Sobald die JVM läuft, bleibt sie warm.

Verwenden Sie eine schnelle Festplatte. Wenn Sie SoapUI von einer rotierenden Festplatte ausführen, verschieben Sie es auf eine SSD. Die Klassenladephase liest viele kleine Dateien, genau hier übertreffen SSDs HDDs.

Verwenden Sie Java 11 oder 17 anstelle von 8. Neuere JVM-Versionen haben verbesserte Startzeiten. Überprüfen Sie, welche JDK SoapUI in soapui.bat (Windows) oder soapui.sh (Linux/Mac) konfiguriert ist. Die erste Zeile legt den Java-Home-Pfad fest. Das Wechseln zu einem neueren JDK kann die Startzeit verkürzen.

AppCDS (Application Class Data Sharing) aktivieren. Diese JVM-Funktion speichert Klassenlading-Daten vorab. Sie erfordert eine einmalige Einrichtung, reduziert aber die nachfolgenden Startzeiten. Fügen Sie -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa zu Ihren JVM-Argumenten hinzu.

Grundursache 2: Standard-Speichereinstellungen sind zu niedrig

SoapUI wird mit niedrigen Standard-Heap-Größeneinstellungen ausgeliefert. Das Öffnen eines großen Projekts oder das Ausführen einer langen Testsuite führt dazu, dass die JVM Zeit für die Garbage Collection aufwendet, was die Anwendung pausiert und sie träge erscheinen lässt.

Standardeinstellungen (aus soapui.vmoptions oder soapui.bat):

-Xms128m
-Xmx768m

Das bedeutet, dass SoapUI mit 128 MB Heap startet und maximal 768 MB verwenden kann. Moderne Maschinen haben 8-32 GB RAM. Wenn SoapUI bei 768 MB belassen wird, führt dies bei jedem großen Projekt zu ständigem Garbage-Collection-Druck.

Lösung: Heap-Größe erhöhen

Unter Windows bearbeiten Sie <SoapUI_Install>/bin/SoapUI.vmoptions:

-Xms512m
-Xmx2048m

Unter macOS bearbeiten Sie SoapUI.app/Contents/vmoptions.txt oder suchen Sie soapui.sh:

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

Unter Linux bearbeiten Sie <SoapUI_Install>/bin/soapui.sh:

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

Empfehlungen:

Setzen Sie -Xms (anfänglicher Heap) auf 512 MB oder höher, wenn Sie genügend RAM haben. Dies vermeidet eine schrittweise Heap-Erweiterung.
Setzen Sie -Xmx (maximaler Heap) auf 2 GB für mittlere Projekte, 4 GB für große. Stellen Sie ihn nicht auf mehr als die Hälfte Ihres verfügbaren RAM ein.
Fügen Sie -XX:+UseG1GC hinzu, wenn Sie Java 9+ verwenden. G1GC reduziert die Pausenzeiten im Vergleich zum Standard-Garbage-Collector.
Fügen Sie -XX:MaxMetaspaceSize=512m hinzu, um zu verhindern, dass der Metaspace (Klassenmetadaten) unbegrenzt wächst.

Die Lösung überprüfen: Nach dem Neustart von SoapUI öffnen Sie das Dialogfeld Hilfe > Systemeigenschaften. Sie sollten die aktualisierten Heap-Werte sehen. Überwachen Sie den Task-Manager, um zu bestätigen, dass SoapUI die neue Zuweisung verwendet.

Grundursache 3: Große Projektdateien

SoapUI speichert alles in einer einzigen XML-Datei. Projekte mit vielen Testsuiten, großen Anforderungstexten oder eingebetteten Binärdaten blähen diese Datei auf. Das Öffnen und Speichern einer 10 MB großen Projektdatei ist merklich langsamer als das einer 500 KB großen Datei.

Anzeichen dieses Problems:

SoapUI pausiert mehrere Sekunden, wenn Sie speichern (Strg+S)
Die Projektdatei auf der Festplatte ist mehrere Megabyte groß
Das Öffnen des Projekts dauert nach dem Start von SoapUI länger als 10 Sekunden

Lösungen:

Große Projekte aufteilen. SoapUI unterstützt zusammengesetzte Projekte, die Testsuiten als separate XML-Dateien in einem Verzeichnis speichern. Aktivieren Sie dies unter Projekt > Einstellungen > Zusammengesetztes Projekt. Dies ermöglicht partielles Laden und schnellere Speicherungen.

Unbenutzte Testfälle entfernen. Archivieren oder löschen Sie Testfälle, die nicht mehr relevant sind. Jeder Testfall mit Skripten und Anfragedaten erhöht die XML-Größe.

Große Anforderungstexte externalisieren. Wenn Ihre Testschritte große XML- oder JSON-Texte inline verwenden, ziehen Sie in Betracht, diese zu parametrisieren und mithilfe der dateibasierten DataSource von SoapUI aus externen Dateien zu laden.

Automatische Sicherung "Beim Beenden speichern" deaktivieren. SoapUI erstellt beim Beenden Sicherungskopien. Deaktivieren Sie dies in den Einstellungen > UI-Einstellungen, um das zusätzliche Schreiben auf die Festplatte beim Schließen zu vermeiden.

Grundursache 4: WSDL-Parsing-Verzögerungen

Wenn SoapUI ein Projekt öffnet, das auf WSDL-Dateien verweist, kann es diese WSDLs beim Start oder wenn Sie den Schnittstellenbaum erweitern, neu parsen. Wenn Ihre WSDLs auf einem Remote-Server gehostet werden oder groß sind (viele Operationen, komplexe Typen), führt dieses Parsen zu erheblichen Verzögerungen.

Anzeichen dieses Problems:

SoapUI hängt oder zeigt einen rotierenden Indikator an, wenn eine Schnittstelle erweitert wird
Tests schlagen mit Verbindungs-Timeout-Fehlern fehl, bevor sie starten
Verschiedene Maschinen laden das Projekt mit unterschiedlichen Geschwindigkeiten (Netzwerkabhängigkeit)

Lösungen:

WSDLs lokal cachen. Klicken Sie in SoapUI mit der rechten Maustaste auf eine Schnittstelle > Definition aktualisieren. Ändern Sie die Definitions-URL so, dass sie auf eine lokale Dateikopie der WSDL anstelle der Remote-URL zeigt. Dies eliminiert die Netzwerklatenz bei jedem Laden.

Definitons-URLs auf file://-Pfade setzen. Sobald Sie eine lokale Kopie der WSDL haben, aktualisieren Sie die Schnittstellen-Definitions-URL auf file:///path/to/your/service.wsdl. SoapUI lädt dies sofort von der Festplatte.

Definition Auto-Update deaktivieren. Deaktivieren Sie unter Einstellungen > WS-Security-Einstellungen Optionen, die eine erneute WSDL-Validierung beim Start erzwingen.

HTTP-Timeout-Einstellungen erhöhen. Wenn Netzwerk-WSDLs langsam reagieren, gehen Sie zu Einstellungen > HTTP-Einstellungen und erhöhen Sie den Verbindungs-Timeout. Dies verhindert, dass SoapUI bei einem langsamen WSDL-Server unbegrenzt hängt.

Grundursache 5: Testlaufleistung bei großen Suiten

Das Ausführen einer Testsuite mit Hunderten von Testfällen kann langsam sein, insbesondere wenn jeder Testschritt komplexe Groovy-Skripte, Assertions oder Netzwerkaufrufe enthält.

Lösungen:

Suiten parallel ausführen. SoapUI unterstützt die parallele Ausführung von Testsuiten. Aktivieren Sie im TestSuite-Runner die Option "Testfälle gleichzeitig ausführen". Stellen Sie sicher, dass Ihr SOAP-Dienst gleichzeitige Verbindungen verarbeiten kann.

Unnötige Assertions deaktivieren. Jede von SoapUI ausgewertete Assertion erhöht die Verarbeitungszeit. Überprüfen Sie Ihre Testschritte und entfernen Sie Assertions, die nichts Sinnvolles überprüfen.

Groovy-Skripte optimieren. Groovy-Skripte werden in SoapUI interpretiert ausgeführt. Vermeiden Sie teure Operationen in Skripten, die bei jedem Testschritt ausgeführt werden (String-Parsing, Regex, Erstellung großer Objekte). Verschieben Sie gemeinsame Logik in Projekt-Bibliotheken.

Verwenden Sie Antwortzeit-Asserts vorsichtig. Antwort-SLA-Asserts warten auf das vollständige Timeout, bevor sie fehlschlagen. Wenn Sie strenge SLA-Asserts mit langen Timeouts auf unzuverlässigen Endpunkten haben, können diese die gesamte Suite blockieren.

Ausführlichkeit der Protokollierung reduzieren. SoapUI protokolliert standardmäßig jede Anfrage und Antwort. Bei großen Suiten summiert sich dieser E/A-Aufwand. Gehen Sie zu Einstellungen > HTTP-Einstellungen und reduzieren Sie, was während der Testläufe protokolliert wird.

Was Sie nicht beheben können

Einige Leistungsprobleme von SoapUI sind strukturell bedingt. Keine Menge an Optimierung ändert:

Swing-UI-Rendering. Die Oberfläche wird sich immer langsamer anfühlen als eine native oder Web-App. Swing war im Jahr 2000 auf dem neuesten Stand der Technik. Das ist es jetzt nicht mehr.
JVM-Start. Sie können ihn reduzieren. Sie können ihn nicht eliminieren.
Single-threaded WSDL-Parsing. SoapUI parst WSDLs sequentiell. Große, komplexe WSDLs mit vielen importierten Schemata brauchen Zeit, und es gibt keine Parallelisierung zu konfigurieren.
Speicher-Overhead. Die JVM, Swing und das Spring-Framework zusammen verbrauchen Speicher, unabhängig von der Projektgröße. 300-400 MB im Leerlauf sind typisch.

Wann es Zeit ist, weiterzuziehen

Wenn Sie die oben genannten Korrekturen angewendet haben und SoapUI Ihren Workflow immer noch blockiert, ist der Engpass möglicherweise nicht durch Konfiguration zu beheben.

Apidog läuft als Webanwendung, die von einem Node.js-Client unterstützt wird, nicht von einer JVM. Es öffnet sich in Sekunden. Die Testausführung erfordert keine Java-Laufzeitumgebung auf Ihrem Computer. Für Teams, deren Hauptengpass die Startzeit und die Reaktionsfähigkeit der Benutzeroberfläche von SoapUI ist, ist der Wechsel des Tools produktiver als das ständige JVM-Tuning.

Der Kompromiss: Apidog parst keine WSDL. Wenn Sie für die Einarbeitung neuer Dienste auf den WSDL-Import von SoapUI angewiesen sind, möchten Sie SoapUI möglicherweise für diese spezifische Aufgabe bereithalten, während Sie tägliche Tests in Apidog durchführen.

FAQ

Was ist die empfohlene Heap-Größe für SoapUI bei einem großen Projekt (über 50 Testsuiten)?Setzen Sie -Xmx auf mindestens 2 GB, idealerweise 4 GB, wenn Ihr Computer 16 GB oder mehr RAM hat. Setzen Sie -Xms auf 512 MB bis 1 GB, um eine schrittweise Heap-Erweiterung zu vermeiden. Verwenden Sie -XX:+UseG1GC für ein besseres Garbage-Collection-Verhalten.

Kann ich die aktuelle Heap-Nutzung von SoapUI überprüfen?Ja. Gehen Sie zu Hilfe > Systemeigenschaften. Dies zeigt JVM-Argumente einschließlich Heap-Einstellungen. Sie können auch -verbose:gc vorübergehend zu den JVM-Optionen hinzufügen, um die Garbage-Collection-Aktivität im SoapUI-Log zu sehen.

Verbessert der Wechsel zu einem neueren JDK die SoapUI-Leistung?In den meisten Fällen ja. Die JVM-Startzeit und die Garbage Collection haben sich in Java 11 und 17 im Vergleich zu Java 8 verbessert. Prüfen Sie die Versionshinweise von SoapUI auf die empfohlene JDK-Version, da einige neuere JDK-Versionen Kompatibilitätsprobleme mit älteren SoapUI-Versionen haben können.

Warum wird SoapUI langsamer, nachdem es mehrere Stunden lang Tests ausgeführt hat?Speicherfragmentierung und Garbage-Collection-Overhead nehmen mit der Zeit zu. Das Schließen und erneute Öffnen von SoapUI setzt den JVM-Status zurück. Eine Erhöhung von -Xmx und die Verwendung von G1GC verzögern diese Verschlechterung, eliminieren sie aber nicht.

Verbessert das Ausführen von SoapUI auf einem Server (headless) die Leistung?Ja, etwas. Der Headless-Modus (-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false und ähnliche Flags) reduziert den Swing-Rendering-Overhead. Verwenden Sie den Kommandozeilen-Testrunner für CI/CD anstelle der GUI für die beste Leistung.

Wie handhabt Apidog große Sammlungen im Vergleich zu SoapUI?Apidog speichert Sammlungen in der Cloud und lädt sie bei Bedarf. Es gibt keine lokale XML-Datei zum Parsen. Die Testausführung verwendet einen lokalen CLI-Runner, der keine JVM-Initialisierung erfordert.

Die meisten Leistungsprobleme von SoapUI haben Lösungen. Allein die Änderung der Heap-Größe hat oft eine sofortige, sichtbare Wirkung. Beginnen Sie dort, bevor Sie komplexere Lösungen ausprobieren.