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.

Essayez Apidog dès aujourd'hui

💡 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.

Introduction

SoapUI est lent. Si vous l'utilisez depuis un certain temps, vous avez déjà subi ses 30 secondes de démarrage, l'interface figée à l'analyse de gros WSDL, ou l'exécution de tests interminable avec des centaines d'étapes. Ce n'est pas un bug, mais le résultat de l'architecture SoapUI.

Ce guide détaille les causes techniques de la lenteur de SoapUI, propose des correctifs actionnables pour chaque problème, et précise leurs limites. Certaines lenteurs sont contournables, d'autres non sans changer d'outil.

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

SoapUI est une application Java Swing. À chaque lancement, la JVM démarre, charge des centaines de classes, initialise Spring, charge le projet, puis affiche l'interface Swing. Sur une machine moderne avec SSD, comptez 20 à 60 secondes. Sur du matériel ancien, plus de 90 secondes.

Pourquoi ?

Les applications Java ont un coût de démarrage lié à la JVM (interprétation/compilation JIT du bytecode) absent des applications natives. L'initialisation Swing ajoute à ce délai.

Correctifs pratiques :

Laissez SoapUI ouvert : Ne fermez pas l'appli entre deux jeux de tests, la JVM reste ainsi "chaude".
Utilisez un SSD : Déplacez SoapUI sur un disque SSD pour accélérer le chargement de classes (nombreuses lectures de petits fichiers).
Passez à Java 11 ou 17 : Les JVM récentes démarrent plus vite. Modifiez la ligne JAVA dans soapui.bat (Windows) ou soapui.sh (Linux/Mac) pour pointer vers un JDK récent.
Activez AppCDS (Application Class Data Sharing) : Prémets en cache le chargement de classes. Ajoutez à la JVM :

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

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

Par défaut, SoapUI utilise un tas (heap) très réduit, ce qui, pour de gros projets ou de longues suites de tests, provoque une collecte des déchets fréquente et des pauses.

Paramètres classiques (soapui.vmoptions ou soapui.bat) :

-Xms128m
-Xmx768m

Sur une machine moderne, c'est insuffisant.

Optimisation recommandée :

Sous Windows : modifiez <Installation_SoapUI>/bin/SoapUI.vmoptions
```
-Xms512m
-Xmx2048m
```
Sous macOS : modifiez SoapUI.app/Contents/vmoptions.txt ou soapui.sh
```
JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"
```
Sous Linux : modifiez <Installation_SoapUI>/bin/soapui.sh
```
JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"
```

Recommandations :

-Xms (heap initial) : 512 Mo minimum.
-Xmx (heap max) : 2 Go pour projets moyens, 4 Go pour gros projets (pas plus de la moitié de la RAM totale).
-XX:+UseG1GC : Active le garbage collector G1 pour Java 9+.
-XX:MaxMetaspaceSize=512m : Limite la croissance du metaspace.

Vérification :

Après redémarrage, ouvrez Aide → Propriétés du système pour confirmer la prise en compte. Surveillez la RAM utilisée dans le gestionnaire de tâches.

Cause première 3 : Fichiers de projet volumineux

SoapUI stocke tout dans un unique fichier XML. Plus il grossit (suites, gros corps de requête, binaires), plus l'ouverture et la sauvegarde sont lentes.

Signes :

Pause de plusieurs secondes à la sauvegarde (Ctrl+S)
Fichier projet > 1 Mo sur disque
Ouverture > 10 secondes avec SoapUI déjà lancé

Correctifs à appliquer :

Divisez vos projets : Activez les projets composites via Projet → Paramètres → Projet Composite. Chaque suite devient un XML distinct, pour un chargement/sauvegarde plus rapide.
Nettoyez les cas de test : Supprimez ou archivez les cas obsolètes.
Externalisez les gros corps de requête : Utilisez des fichiers externes via la source de données de SoapUI plutôt que d'inclure de gros XML/JSON en ligne.
Désactivez la sauvegarde automatique à la fermeture : Dans Préférences → Paramètres UI, désactivez "enregistrer à la sortie" pour éviter des écritures inutiles.

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

Si SoapUI référence des WSDL (locaux ou distants), il les réanalyse au démarrage ou à l’expansion de l’interface. Un WSDL volumineux ou distant crée un délai notable.

Signes :

Blocage ou roue de chargement à l’expansion de l’interface
Tests échouant pour timeout avant même de démarrer
Différence de vitesse selon la machine (dépendance réseau)

Correctifs concrets :

Mettez les WSDL en cache localement : Clic droit sur l’interface → Mettre à jour la définition, puis remplacez l’URL distante par une version locale.
Passez les URL de définition en file:// :
```
file:///chemin/vers/votre/service.wsdl
```
Désactivez la mise à jour automatique des définitions : Préférences → WS-Security, décochez les revalidations WSDL au démarrage.
Augmentez les timeouts HTTP : Préférences → HTTP, augmentez les délais pour éviter les blocages sur WSDL lent.

Cause première 5 : Exécution lente de grandes suites de tests

Des suites de tests contenant des centaines de cas, des scripts Groovy lourds ou de nombreuses assertions ralentissent l’ensemble.

Optimisations à mettre en place :

Exécution parallèle : Activez "exécuter les cas de test simultanément" dans le lanceur de TestSuite. Vérifiez que l’API cible supporte la concurrence.
Désactivez les assertions inutiles : Auditez chaque étape, supprimez les assertions non critiques.
Optimisez les scripts Groovy : Évitez les traitements lourds ou les boucles inutiles dans chaque étape. Placez la logique partagée dans des bibliothèques au niveau projet.
Attention aux assertions de temps de réponse : Les assertions SLA attendent le timeout complet ; réduisez leur usage ou raccourcissez les délais pour éviter de bloquer toute la suite.
Réduisez la verbosité des logs : Préférences → HTTP, limitez l’enregistrement des requêtes/réponses pour diminuer l’I/O sur de gros tests.

Ce que vous ne pouvez pas corriger

Certaines limites de performance sont liées à l’architecture SoapUI :

Rendu de l’UI Swing : Toujours plus lent qu’une app native ou web.
Démarrage JVM : Réductible mais inévitable.
Analyse WSDL mono-thread : SoapUI analyse les WSDL séquentiellement, pas de parallélisation possible.
Surcharge mémoire structurelle : JVM, Swing et Spring consomment 300 à 400 Mo au repos, peu importe la taille du projet.

Quand passer à autre chose

Si, après avoir appliqué ces correctifs, SoapUI reste un goulet d’étranglement, c’est probablement structurel.

Apidog fonctionne comme une application web (backend Node.js, pas de JVM). Il s'ouvre en quelques secondes, et l’exécution des tests ne dépend pas de Java. Pour les équipes pénalisées par la lenteur de démarrage et de l’UI de SoapUI, le changement d’outil sera plus rentable que d’optimiser la JVM.

Limite : Apidog n’analyse pas les WSDL. Si vous avez besoin de l’import WSDL pour l’intégration initiale, gardez SoapUI pour cette tâche, mais réalisez les tests quotidiens dans Apidog.

FAQ

Quelle taille de heap recommander pour SoapUI avec un gros projet (50+ suites de tests) ?

Définissez -Xmx à 2 Go minimum, 4 Go si vous avez 16 Go de RAM ou plus. -Xms à 512 Mo ou 1 Go. Ajoutez -XX:+UseG1GC.

Comment vérifier l'utilisation du heap SoapUI ?

Aide → Propriétés du système, pour voir les arguments JVM et la mémoire allouée. Ajoutez temporairement -verbose:gc pour voir la collecte des déchets dans le log.

Passer à un JDK plus récent améliore-t-il les performances ?

Oui dans la majorité des cas : démarrage JVM et gestion mémoire sont meilleurs en Java 11/17 qu'en Java 8. Vérifiez la compatibilité de votre version SoapUI avec le JDK choisi.

Pourquoi SoapUI ralentit-il après plusieurs heures de tests ?

La fragmentation mémoire et la surcharge de la collecte des déchets s’accroissent. Fermer/réouvrir SoapUI réinitialise la JVM. Augmenter -Xmx et utiliser G1GC retardent le problème.

Exécution SoapUI sur serveur (mode sans tête) : gain de performance ?

Partiellement. Le mode sans tête (-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false) réduit la charge UI. Pour le CI/CD, privilégiez le lanceur CLI plutôt que l’interface graphique.

Comment Apidog gère-t-il les grandes collections comparé à SoapUI ?

Apidog stocke les collections dans le cloud et les charge à la demande. Pas de gros XML local à parser. Les tests s’exécutent via un exécuteur CLI local (pas besoin de JVM).

En résumé : la majorité des problèmes de performance de SoapUI sont liés à la mémoire. Augmenter la taille du tas donne souvent un résultat immédiat. Commencez par là avant de tester des optimisations plus poussées.