SoapUI Performance Lente: Causes et Solutions

En bref

La lenteur de SoapUI provient de la surcharge au démarrage de la JVM, de paramètres de mémoire par défaut trop bas pour les grands projets et des retards d'analyse WSDL. Des correctifs spécifiques (optimisation de la taille du tas, mise en cache du WSDL, division des projets) peuvent améliorer significativement la vitesse. Si votre équipe a besoin d'un outil plus rapide qui évite entièrement ces goulots d'étranglement, Apidog fonctionne sans runtime Java.

💡

Apidog est une plateforme de développement API tout-en-un gratuite qui fonctionne dans un navigateur ou une application de bureau légère, évitant entièrement la surcharge JVM et l'optimisation de la mémoire. Essayez Apidog gratuitement, aucune carte de crédit requise.

button

Introduction

SoapUI est lent. Si vous l'avez utilisé pendant plus de quelques semaines, vous avez expérimenté le démarrage de 30 secondes, l'interface utilisateur qui ne répond pas lors de l'analyse d'un grand WSDL, ou l'exécution de test qui traîne lorsque vous avez des centaines d'étapes de test. Ce ne sont pas des bugs. C'est le résultat naturel de la façon dont SoapUI a été construit.

Ce guide explique les raisons techniques spécifiques pour lesquelles SoapUI est lent, vous donne des correctifs concrets pour chacune et explique les limites. Une certaine lenteur peut être corrigée. Une autre ne peut pas l'être sans changer d'outil.

Cause première 1 : Surcharge au démarrage de la JVM

SoapUI est une application Java Swing. Chaque fois que vous la lancez, elle démarre une machine virtuelle Java (JVM), charge des centaines de fichiers de classe, initialise le framework Spring, charge votre projet et rend l'interface Swing. Sur une machine moderne avec un SSD, cela prend 20 à 60 secondes. Sur du matériel plus ancien, cela peut dépasser 90 secondes.

Pourquoi cela se produit : Les applications Java subissent un coût de démarrage que les applications natives n'ont pas. La JVM doit interpréter ou compiler JIT le bytecode avant que l'exécution ne commence. L'initialisation de l'interface utilisateur Swing s'ajoute à cela.

Correctifs :

Gardez SoapUI ouvert. Le correctif le plus simple est de ne pas le fermer entre les exécutions de test. Une fois la JVM en marche, elle reste "chaude".

Utilisez un disque rapide. Si vous exécutez SoapUI à partir d'un disque dur mécanique, déplacez-le sur un SSD. La phase de chargement des classes lit de nombreux petits fichiers, ce qui est précisément là où les SSD surpassent les HDD.

Utilisez Java 11 ou 17 au lieu de 8. Les versions plus récentes de la JVM ont des temps de démarrage améliorés. Vérifiez quel JDK SoapUI est configuré pour utiliser dans soapui.bat (Windows) ou soapui.sh (Linux/Mac). La première ligne définit le chemin d'accès à Java. Le passage à un JDK plus récent peut réduire le temps de démarrage.

Activez AppCDS (Application Class Data Sharing). Cette fonctionnalité de la JVM pré-met en cache les données de chargement des classes. Elle nécessite une configuration unique mais réduit les temps de démarrage ultérieurs. Ajoutez -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa à vos arguments JVM.

Cause première 2 : Les paramètres de mémoire par défaut sont trop bas

SoapUI est livré avec des paramètres de taille de tas (heap) faibles par défaut. L'ouverture d'un grand projet ou l'exécution d'une longue suite de tests oblige la JVM à passer du temps à la collecte des déchets (garbage collection), ce qui met l'application en pause et la rend lente.

Paramètres par défaut (à partir de soapui.vmoptions ou soapui.bat) :

-Xms128m
-Xmx768m

Cela signifie que SoapUI démarre avec 128 Mo de tas et peut utiliser un maximum de 768 Mo. Les machines modernes ont 8 à 32 Go de RAM. Laisser SoapUI à 768 Mo provoque une pression constante de la collecte des déchets sur tout grand projet.

Correctif : augmenter la taille du tas

Sous Windows, modifiez <Installation_SoapUI>/bin/SoapUI.vmoptions :

-Xms512m
-Xmx2048m

Sous macOS, modifiez SoapUI.app/Contents/vmoptions.txt ou trouvez soapui.sh :

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

Sous Linux, modifiez <Installation_SoapUI>/bin/soapui.sh :

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

Recommandations :

Définissez -Xms (tas initial) à 512 Mo ou plus si vous avez de la RAM disponible. Cela évite une expansion progressive du tas.
Définissez -Xmx (tas maximal) à 2 Go pour les projets de taille moyenne, 4 Go pour les grands projets. Ne le définissez pas à plus de la moitié de votre RAM disponible.
Ajoutez -XX:+UseG1GC si vous utilisez Java 9+. G1GC réduit les temps de pause par rapport au ramasse-miettes par défaut.
Ajoutez -XX:MaxMetaspaceSize=512m pour empêcher le metaspace (métadonnées de classe) de croître de manière illimitée.

Vérification du correctif : Après avoir redémarré SoapUI, ouvrez la boîte de dialogue Aide > Propriétés du système. Vous devriez voir les valeurs du tas mises à jour. Surveillez le gestionnaire de tâches pour confirmer que SoapUI utilise la nouvelle allocation.

Cause première 3 : Fichiers de projet volumineux

SoapUI stocke tout dans un seul fichier XML. Les projets avec de nombreuses suites de tests, de grands corps de requêtes ou des données binaires intégrées alourdissent ce fichier. L'ouverture et la sauvegarde d'un fichier de projet de 10 Mo sont nettement plus lentes que celles d'un fichier de 500 Ko.

Signes de ce problème :

SoapUI se met en pause pendant plusieurs secondes lorsque vous sauvegardez (Ctrl+S)
Le fichier de projet sur le disque fait plusieurs mégaoctets
L'ouverture du projet prend plus de 10 secondes après que SoapUI soit déjà en cours d'exécution

Correctifs :

Divisez les grands projets. SoapUI prend en charge les projets composites qui stockent les suites de tests sous forme de fichiers XML distincts dans un répertoire. Activez cette option dans Projet > Paramètres > Projet Composite. Cela permet un chargement partiel et des sauvegardes plus rapides.

Supprimez les cas de test inutilisés. Archivez ou supprimez les cas de test qui ne sont plus pertinents. Chaque cas de test avec des scripts et des données de requête augmente la taille du XML.

Externalisez les grands corps de requêtes. Si vos étapes de test utilisent de grands corps XML ou JSON en ligne, envisagez de les paramétrer et de les charger à partir de fichiers externes en utilisant la source de données basée sur des fichiers de SoapUI.

Désactivez la sauvegarde automatique "enregistrer à la sortie". SoapUI crée des copies de sauvegarde à la sortie. Désactivez cette option dans Préférences > Paramètres de l'interface utilisateur pour éviter l'écriture sur disque supplémentaire à la fermeture.

Cause première 4 : Délais d'analyse WSDL

Lorsque SoapUI ouvre un projet qui référence des fichiers WSDL, il peut réanalyser ces WSDL au démarrage ou lorsque vous développez l'arborescence de l'interface. Si vos WSDL sont hébergés sur un serveur distant ou sont volumineux (nombreuses opérations, types complexes), cette analyse ajoute des retards significatifs.

Signes de ce problème :

SoapUI se bloque ou affiche un indicateur de chargement rotatif lors de l'expansion d'une interface
Les tests échouent avec des erreurs de délai d'attente de connexion avant de démarrer
Différentes machines chargent le projet à des vitesses différentes (dépendance réseau)

Correctifs :

Mettez les WSDL en cache localement. Dans SoapUI, cliquez avec le bouton droit sur une interface > Mettre à jour la définition. Modifiez l'URL de définition pour qu'elle pointe vers une copie locale du fichier WSDL au lieu de l'URL distante. Cela élimine la latence réseau à chaque chargement.

Définissez les URL de définition sur des chemins file://. Une fois que vous avez une copie locale du WSDL, mettez à jour l'URL de définition de l'interface vers file:///chemin/vers/votre/service.wsdl. SoapUI le charge instantanément depuis le disque.

Désactivez la mise à jour automatique de la définition. Dans Préférences > Paramètres WS-Security, décochez les options qui forcent la revalidation du WSDL au démarrage.

Augmentez les paramètres de délai d'attente HTTP. Si les WSDL réseau sont lents à répondre, allez dans Préférences > Paramètres HTTP et augmentez le délai d'attente de connexion. Cela empêche SoapUI de se bloquer indéfiniment sur un serveur WSDL lent.

Cause première 5 : Performances d'exécution des tests sur de grandes suites

L'exécution d'une suite de tests avec des centaines de cas de test peut être lente, surtout lorsque chaque étape de test contient des scripts Groovy complexes, des assertions ou des appels réseau.

Correctifs :

Exécutez les suites en parallèle. SoapUI prend en charge l'exécution parallèle des suites de tests. Dans le lanceur de TestSuite, activez l'option "Exécuter les cas de test simultanément". Assurez-vous que votre service SOAP gère les connexions concurrentes.

Désactivez les assertions inutiles. Chaque assertion évaluée par SoapUI ajoute du temps de traitement. Auditez vos étapes de test et supprimez les assertions qui ne vérifient rien de significatif.

Optimisez les scripts Groovy. Les scripts Groovy s'exécutent interprétés dans SoapUI. Évitez les opérations coûteuses dans les scripts qui s'exécutent pour chaque étape de test (analyse de chaînes, expressions régulières, création de grands objets). Déplacez la logique partagée vers des bibliothèques de scripts au niveau du projet.

Utilisez les assertions de temps de réponse avec prudence. Les assertions SLA de réponse attendent le délai d'expiration complet avant d'échouer. Si vous avez des assertions SLA strictes avec de longs délais d'attente sur des points de terminaison peu fiables, elles peuvent bloquer toute la suite.

Réduisez la verbosité de la journalisation. SoapUI enregistre chaque requête et réponse par défaut. Pour les grandes suites, ces I/O s'accumulent. Allez dans Préférences > Paramètres HTTP et réduisez ce qui est enregistré pendant les exécutions de test.

Ce que vous ne pouvez pas corriger

Certains problèmes de performance de SoapUI sont structurels. Aucune quantité d'optimisation ne changera :

Le rendu de l'interface utilisateur Swing. L'interface semblera toujours plus lente qu'une application native ou web. Swing était à la pointe de la technologie en 2000. Ce n'est plus le cas aujourd'hui.
Le démarrage de la JVM. Vous pouvez le réduire. Vous ne pouvez pas l'éliminer.
L'analyse WSDL à un seul thread. SoapUI analyse les WSDL séquentiellement. Les WSDL volumineux et complexes avec de nombreux schémas importés prennent du temps, et il n'y a pas de parallélisme à configurer.
La surcharge de mémoire. La JVM, Swing et le framework Spring consomment de la mémoire, quelle que soit la taille du projet. 300 à 400 Mo au repos sont typiques.

Quand passer à autre chose

Si vous avez appliqué les correctifs ci-dessus et que SoapUI bloque toujours votre flux de travail, le goulot d'étranglement n'est peut-être pas réparable par la configuration.

Apidog fonctionne comme une application web soutenue par un client Node.js, et non une JVM. Il s'ouvre en quelques secondes. L'exécution des tests ne nécessite pas de runtime Java sur votre machine. Pour les équipes dont le principal goulot d'étranglement est le temps de démarrage et la réactivité de l'interface utilisateur de SoapUI, changer d'outil est plus productif qu'une optimisation continue de la JVM.

Le compromis : Apidog n'analyse pas le WSDL. Si vous dépendez de l'importation WSDL de SoapUI pour l'intégration de nouveaux services, vous pouvez conserver SoapUI disponible pour cette tâche spécifique tout en effectuant les tests quotidiens dans Apidog.

FAQ

Quelle est la taille de tas (heap) recommandée pour SoapUI avec un grand projet (plus de 50 suites de tests) ?Définissez -Xmx à au moins 2 Go, idéalement 4 Go si votre machine dispose de 16 Go ou plus de RAM. Définissez -Xms à 512 Mo à 1 Go pour éviter une expansion progressive du tas. Utilisez -XX:+UseG1GC pour un meilleur comportement de la collecte des déchets.

Puis-je vérifier l'utilisation actuelle du tas de SoapUI ?Oui. Allez dans Aide > Propriétés du système. Cela affiche les arguments de la JVM, y compris les paramètres du tas. Vous pouvez également ajouter -verbose:gc aux options de la JVM temporairement pour voir l'activité de la collecte des déchets dans le journal de SoapUI.

Le passage à un JDK plus récent améliore-t-il les performances de SoapUI ?Dans la plupart des cas, oui. Le temps de démarrage de la JVM et la collecte des déchets ont été améliorés dans Java 11 et 17 par rapport à Java 8. Consultez les notes de version de SoapUI pour la version de JDK recommandée, car certaines versions plus récentes de JDK peuvent avoir des problèmes de compatibilité avec les versions plus anciennes de SoapUI.

Pourquoi SoapUI ralentit-il après avoir exécuté des tests pendant quelques heures ?La fragmentation de la mémoire et la surcharge de la collecte des déchets augmentent avec le temps. Fermer et rouvrir SoapUI réinitialise l'état de la JVM. L'augmentation de -Xmx et l'utilisation de G1GC retardent cette dégradation mais ne l'éliminent pas.

L'exécution de SoapUI sur un serveur (sans tête) améliore-t-elle les performances ?Oui, en partie. Le mode sans tête (-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false et des drapeaux similaires) réduit la surcharge de rendu Swing. Utilisez le lanceur de tests en ligne de commande pour le CI/CD au lieu de l'interface graphique pour les meilleures performances.

Comment Apidog gère-t-il les grandes collections par rapport à SoapUI ?Apidog stocke les collections dans le cloud et les charge à la demande. Il n'y a pas de fichier XML local à analyser. L'exécution des tests utilise un exécuteur CLI local qui ne nécessite pas d'initialisation JVM.

La plupart des problèmes de performance de SoapUI ont des correctifs. Le seul changement de taille du tas a souvent un effet immédiat et visible. Commencez par là avant d'essayer des solutions plus complexes.