Rendimiento Lento de SoapUI: Causas y Soluciones

TL;DR

El bajo rendimiento de SoapUI se debe a la sobrecarga del inicio de la JVM, configuraciones de memoria predeterminadas insuficientes para proyectos grandes y retrasos en el análisis de WSDL. Ajustar el heap, cachear WSDLs y dividir proyectos mejoran la velocidad. Si necesitas una herramienta más rápida sin estos cuellos de botella, Apidog funciona sin Java.

Prueba Apidog hoy mismo

💡 Apidog es una plataforma gratuita de desarrollo de APIs que funciona en el navegador o como app de escritorio ligera, evitando la sobrecarga de la JVM y el ajuste de memoria. Prueba Apidog gratis, sin tarjeta de crédito.

Introducción

SoapUI es lento. Si lo has usado por un tiempo, ya sufriste los 30 segundos de inicio, la UI que no responde al procesar un WSDL grande, o tests que se arrastran con cientos de pasos. No es un bug: es resultado de su arquitectura.

Esta guía explica las razones técnicas de la lentitud de SoapUI, soluciones directas para cada una y los límites que no puedes superar sin cambiar de herramienta.

Causa raíz 1: Sobrecarga de inicio de la JVM

SoapUI es una app Java Swing. Cada vez que la inicias, arranca una JVM, carga cientos de clases, inicializa Spring, carga tu proyecto y renderiza la interfaz. Incluso en SSD modernos, esto toma 20–60 segundos; en hardware antiguo, puede superar 90 segundos.

Por qué ocurre: Las apps Java siempre pagan un coste de arranque. La JVM interpreta o compila el bytecode antes de ejecutar. Swing añade más retraso.

Cómo mitigar:

• Mantén SoapUI abierto: No lo cierres entre ejecuciones de pruebas.
• Usa SSD: Si lo tienes en HDD, muévelo a un disco de estado sólido.
• Actualiza a Java 11 o 17: Las JVM recientes inician más rápido. Verifica el JDK editando soapui.bat (Windows) o soapui.sh (Linux/Mac) y ajusta la ruta.
• Activa AppCDS: Precarga datos de clases para acelerar el arranque. Añade estos flags a la JVM:

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

Causa raíz 2: Configuración de memoria predeterminada insuficiente

SoapUI viene limitado en heap. Proyectos grandes o muchos tests hacen que la JVM pase tiempo recolectando basura, pausando la app.

Default típico en soapui.vmoptions o soapui.bat:

-Xms128m
-Xmx768m

Esto es insuficiente para hardware moderno.

Solución: Eleva el tamaño de heap.

• Windows: Edita <SoapUI_Install>/bin/SoapUI.vmoptions:

  -Xms512m
  -Xmx2048m

• macOS: Edita SoapUI.app/Contents/vmoptions.txt o busca soapui.sh:

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

• Linux: Edita <SoapUI_Install>/bin/soapui.sh:

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

Recomendaciones rápidas:

• -Xms: mínimo 512MB si tienes RAM de sobra.
• -Xmx: 2GB para proyectos medianos, 4GB para grandes (máximo la mitad de tu RAM).
• Añade -XX:+UseG1GC (Java 9+).
• Añade -XX:MaxMetaspaceSize=512m para limitar el metaspace.

Verifica los cambios: Reinicia SoapUI y revisa en Ayuda > Propiedades del sistema los nuevos valores de heap. Usa el administrador de tareas para confirmar.

Causa raíz 3: Archivos de proyecto grandes

SoapUI guarda todo en un XML único. Proyectos con muchos tests, cuerpos grandes o binarios embebidos hinchan el archivo. Abrir o guardar un proyecto de 10MB es mucho más lento que uno de 500KB.

Síntomas:

• SoapUI se pausa varios segundos al guardar (Ctrl+S).
• El archivo de proyecto pesa varios MB.
• Abrir el proyecto tarda más de 10s aunque SoapUI ya esté abierto.

Soluciones prácticas:

• Divide proyectos grandes: Activa “Proyecto Compuesto” en Proyecto > Configuración. Así cada test suite es un XML separado, acelerando carga y guardado.
• Elimina casos de prueba obsoletos: Borra o archiva lo que no uses.
• Externaliza cuerpos grandes: Guarda cuerpos XML/JSON en archivos externos y cárgalos por DataSource.
• Desactiva backup automático al salir: En Preferencias > UI, desactiva “guardar al salir” para evitar escrituras extra en disco.

Causa raíz 4: Retrasos al analizar WSDL

SoapUI reanaliza los WSDLs al abrir proyectos o expandir interfaces. Si los WSDLs son remotos o muy grandes, este análisis puede ser muy lento.

Síntomas:

• SoapUI se cuelga o carga lento al expandir una interfaz.
• Tests fallan con timeouts antes de iniciar.
• Diferente velocidad de carga según la red.

Soluciones concretas:

• Cachea los WSDLs localmente: Haz clic derecho en la interfaz > Actualizar definición y apunta la URL a una copia local.
• Usa rutas file://: Cambia la URL de la interfaz a file:///ruta/a/servicio.wsdl para que cargue desde disco.
• Desactiva actualización automática: En Preferencias > WS-Security, desmarca la opción de revalidar WSDL al inicio.
• Eleva el timeout HTTP: En Preferencias > HTTP, aumenta el timeout para evitar cuelgues con servidores lentos.

Causa raíz 5: Ejecución lenta en suites de pruebas grandes

Ejecutar cientos de tests es lento, más aún si cada paso usa scripts Groovy complejos o muchas aserciones.

Cómo optimizar:

• Ejecuta suites en paralelo: Activa “ejecutar casos concurrentemente” en el ejecutor de TestSuite.
• Deshabilita aserciones innecesarias: Elimina aserciones que no aportan valor.
• Optimiza scripts Groovy: Evita operaciones costosas en scripts ejecutados por test. Centraliza lógica común en bibliotecas de scripts de proyecto.
• Cuida las aserciones de tiempo: Las de SLA esperan el timeout completo. No uses tiempos largos si los endpoints son poco fiables.
• Reduce la verbosidad del log: En Preferencias > HTTP, limita qué se registra para grandes suites.

Lo que no se puede arreglar

Algunos cuellos de botella de SoapUI son estructurales y no se eliminan con ajustes:

• UI Swing: Siempre será más lenta que una app nativa o web.
• Inicio de JVM: Puedes reducirlo, no eliminarlo.
• Análisis WSDL monohilo: Solo analiza WSDLs de uno en uno, sin paralelismo.
• Consumo de memoria base: JVM, Swing y Spring consumen cientos de MB aunque el proyecto sea pequeño.

Cuándo migrar a otra herramienta

Si tras aplicar los ajustes SoapUI sigue bloqueando tu flujo, el cuello de botella puede ser intrínseco.

Apidog es una app web respaldada por un cliente Node.js, sin JVM. Arranca en segundos y no requiere Java para ejecutar pruebas. Si tu problema es el tiempo de inicio o la UI, cambiar de herramienta es más productivo que seguir ajustando JVM.

Nota: Apidog no analiza WSDL. Si dependes de importar WSDLs, quizá necesites mantener SoapUI para esa tarea y usar Apidog para el testing diario.

Preguntas frecuentes

¿Tamaño de heap recomendado para proyectos grandes (>50 suites)?

Establece -Xmx en al menos 2GB, idealmente 4GB si tienes 16GB de RAM o más. Usa -Xms en 512MB–1GB y añade -XX:+UseG1GC para mejor garbage collection.

¿Puedo ver el heap actual de SoapUI?

Sí. Ve a Ayuda > Propiedades del sistema. También puedes añadir -verbose:gc a la JVM para ver la actividad de GC en el log.

¿Actualizar el JDK mejora el rendimiento?

En la mayoría de casos sí. Java 11 y 17 arrancan más rápido y mejoran GC respecto a Java 8. Consulta las notas de versión de SoapUI para compatibilidad.

¿Por qué SoapUI se ralentiza tras horas de pruebas?

La memoria se fragmenta y la GC aumenta su carga. Reinicia SoapUI para limpiar la JVM. Aumentar -Xmx y usar G1GC ayuda pero no lo elimina del todo.

¿Ejecutar SoapUI en modo servidor (sin UI) mejora el rendimiento?

Sí, parcialmente. Usa flags como -Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false y ejecuta pruebas desde CLI en CI/CD.

¿Cómo maneja Apidog las colecciones grandes frente a SoapUI?

Apidog almacena colecciones en la nube y las carga bajo demanda, sin XML local que analizar. Las pruebas se ejecutan con CLI local, sin JVM.

En resumen: la mayoría de problemas de rendimiento de SoapUI tienen solución. Ajustar el heap suele producir mejoras inmediatas. Empieza por ahí antes de pasar a ajustes más avanzados.