Rendimiento Lento de SoapUI: Causas y Soluciones

TL;DR

El rendimiento lento de SoapUI se debe a la sobrecarga del inicio de la JVM, configuraciones de memoria predeterminadas que son demasiado bajas para proyectos grandes y retrasos en el análisis de WSDL. Correcciones específicas (ajuste del tamaño del heap, almacenamiento en caché de WSDL, división de proyectos) pueden mejorar significativamente la velocidad. Si su equipo necesita una herramienta más rápida que evite estos cuellos de botella por completo, Apidog se ejecuta sin un tiempo de ejecución de Java.

Introducción

SoapUI es lento. Si lo ha usado durante más de unas pocas semanas, ha experimentado el inicio de 30 segundos, la interfaz de usuario que no responde mientras analiza un WSDL grande, o la ejecución de prueba que se arrastra cuando tiene cientos de pasos de prueba. Estos no son errores. Son el resultado natural de cómo se construyó SoapUI.

Esta guía explica las razones técnicas específicas por las que SoapUI es lento, le brinda soluciones concretas para cada una y explica dónde están los límites. Parte de la lentitud se puede solucionar. Otra parte no, sin cambiar de herramienta.

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

SoapUI es una aplicación Java Swing. Cada vez que la inicia, inicia una Máquina Virtual de Java (JVM), carga cientos de archivos de clase, inicializa el framework Spring, carga su proyecto y renderiza la interfaz Swing. En una máquina moderna con un SSD, esto lleva de 20 a 60 segundos. En hardware antiguo, puede superar los 90 segundos.

Por qué sucede esto: Las aplicaciones Java pagan un costo de inicio que las aplicaciones nativas no. La JVM necesita interpretar o compilar JIT el código de bytes antes de que comience la ejecución. La inicialización de la interfaz de usuario de Swing se suma a eso.

Soluciones:

Mantenga SoapUI abierto. La solución más simple es no cerrarlo entre ejecuciones de prueba. Una vez que la JVM está en funcionamiento, permanece activa.

Use un disco rápido. Si está ejecutando SoapUI desde un disco duro giratorio, muévalo a un SSD. La fase de carga de clases lee muchos archivos pequeños, que es exactamente donde los SSD superan a los HDD.

Use Java 11 o 17 en lugar de 8. Las versiones más nuevas de JVM han mejorado los tiempos de inicio. Verifique qué JDK está configurado para usar SoapUI en soapui.bat (Windows) o soapui.sh (Linux/Mac). La primera línea establece la ruta de inicio de Java. Cambiar a un JDK más nuevo puede reducir el tiempo de inicio.

Habilite AppCDS (Application Class Data Sharing). Esta característica de la JVM pre-cachea los datos de carga de clases. Requiere una configuración única, pero reduce los tiempos de inicio posteriores. Agregue -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa a sus argumentos de la JVM.

Causa raíz 2: La configuración de memoria predeterminada es demasiado baja

SoapUI se distribuye con configuraciones de tamaño de heap predeterminadas bajas. Abrir un proyecto grande o ejecutar un conjunto de pruebas largo hace que la JVM dedique tiempo a la recolección de basura, lo que pausa la aplicación y la hace sentir lenta.

Configuración predeterminada (de soapui.vmoptions o soapui.bat):

-Xms128m
-Xmx768m

Esto significa que SoapUI comienza con 128 MB de heap y puede usar un máximo de 768 MB. Las máquinas modernas tienen de 8 a 32 GB de RAM. Dejar SoapUI en 768 MB causa una presión constante de recolección de basura en cualquier proyecto grande.

Solución: aumentar el tamaño del heap

En Windows, edite <SoapUI_Install>/bin/SoapUI.vmoptions:

-Xms512m
-Xmx2048m

En macOS, edite SoapUI.app/Contents/vmoptions.txt o encuentre soapui.sh:

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

En Linux, edite <SoapUI_Install>/bin/soapui.sh:

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

Recomendaciones:

• Establezca -Xms (heap inicial) en 512 MB o más si tiene RAM de sobra. Esto evita la expansión gradual del heap.
• Establezca -Xmx (heap máximo) en 2 GB para proyectos medianos, 4 GB para proyectos grandes. No lo establezca en más de la mitad de su RAM disponible.
• Agregue -XX:+UseG1GC si está usando Java 9+. G1GC reduce los tiempos de pausa en comparación con el recolector de basura predeterminado.
• Agregue -XX:MaxMetaspaceSize=512m para evitar que el metaspace (metadatos de clase) crezca sin límites.

Verificación de la solución: Después de reiniciar SoapUI, abra el cuadro de diálogo Ayuda > Propiedades del sistema. Debería ver los valores de heap actualizados. Monitoree el administrador de tareas para confirmar que SoapUI está utilizando la nueva asignación.

Causa raíz 3: Archivos de proyecto grandes

SoapUI almacena todo en un único archivo XML. Los proyectos con muchos conjuntos de pruebas, cuerpos de solicitud grandes o datos binarios en línea inflan este archivo. Abrir y guardar un archivo de proyecto de 10 MB es notablemente más lento que uno de 500 KB.

Señales de este problema:

• SoapUI se pausa durante varios segundos al guardar (Ctrl+S)
• El archivo del proyecto en el disco es de varios megabytes
• Abrir el proyecto tarda más de 10 segundos después de que SoapUI ya esté en ejecución

Soluciones:

Divida proyectos grandes. SoapUI admite proyectos compuestos que almacenan conjuntos de pruebas como archivos XML separados en un directorio. Habilite esto en Proyecto > Configuración > Proyecto Compuesto. Esto permite la carga parcial y guardados más rápidos.

Elimine casos de prueba no utilizados. Archive o elimine los casos de prueba que ya no sean relevantes. Cada caso de prueba con scripts y datos de solicitud aumenta el tamaño del XML.

Externalice cuerpos de solicitud grandes. Si sus pasos de prueba utilizan cuerpos XML o JSON grandes en línea, considere parametrizarlos y cargarlos desde archivos externos usando el DataSource basado en archivos de SoapUI.

Deshabilite la copia de seguridad automática "guardar al salir". SoapUI crea copias de seguridad al salir. Deshabilite esto en Preferencias > Configuración de la interfaz de usuario para evitar la escritura adicional en disco al cerrar.

Causa raíz 4: Retrasos en el análisis de WSDL

Cuando SoapUI abre un proyecto que hace referencia a archivos WSDL, puede volver a analizar esos WSDLs al inicio o cuando expande el árbol de la interfaz. Si sus WSDLs están alojados en un servidor remoto o son grandes (muchas operaciones, tipos complejos), este análisis agrega retrasos significativos.

Señales de este problema:

• SoapUI se cuelga o muestra un indicador de carga al expandir una interfaz
• Las pruebas fallan con errores de tiempo de espera de conexión antes de comenzar
• Diferentes máquinas cargan el proyecto a diferentes velocidades (dependencia de red)

Soluciones:

Almacene los WSDLs en caché localmente. En SoapUI, haga clic derecho en una interfaz > Actualizar Definición. Cambie la URL de la definición para que apunte a una copia local del archivo WSDL en lugar de la URL remota. Esto elimina la latencia de red en cada carga.

Establezca las URL de definición en rutas file://. Una vez que tenga una copia local del WSDL, actualice la URL de la definición de la interfaz a file:///ruta/a/su/servicio.wsdl. SoapUI lo carga desde el disco al instante.

Deshabilite la actualización automática de definición. En Preferencias > Configuración de WS-Security, desmarque las opciones que fuerzan la revalidación de WSDL al inicio.

Aumente la configuración del tiempo de espera HTTP. Si los WSDL de red tardan en responder, vaya a Preferencias > Configuración HTTP y aumente el tiempo de espera de conexión. Esto evita que SoapUI se quede colgado indefinidamente en un servidor WSDL lento.

Causa raíz 5: Rendimiento de la ejecución de pruebas en suites grandes

Ejecutar un conjunto de pruebas con cientos de casos de prueba puede ser lento, especialmente cuando cada paso de prueba tiene scripts Groovy complejos, aserciones o llamadas de red.

Soluciones:

Ejecute suites en paralelo. SoapUI admite la ejecución paralela de suites de prueba. En el ejecutor de TestSuite, habilite la opción "Ejecutar casos de prueba concurrentemente". Asegúrese de que su servicio SOAP maneje conexiones concurrentes.

Deshabilite aserciones innecesarias. Cada aserción que SoapUI evalúa agrega tiempo de procesamiento. Audite sus pasos de prueba y elimine las aserciones que no verifican nada significativo.

Optimice los scripts Groovy. Los scripts Groovy se ejecutan interpretados en SoapUI. Evite operaciones costosas en scripts que se ejecutan para cada paso de prueba (análisis de cadenas, expresiones regulares, creación de objetos grandes). Mueva la lógica compartida a bibliotecas de scripts a nivel de proyecto.

Use las aserciones de tiempo de respuesta con cuidado. Las aserciones de SLA de respuesta esperan el tiempo de espera completo antes de fallar. Si tiene aserciones de SLA ajustadas con tiempos de espera largos en puntos finales poco confiables, pueden bloquear toda la suite.

Reduzca la verbosidad del registro. SoapUI registra cada solicitud y respuesta de forma predeterminada. Para suites grandes, esta E/S se acumula. Vaya a Preferencias > Configuración HTTP y reduzca lo que se registra durante las ejecuciones de prueba.

Lo que no se puede arreglar

Algunos problemas de rendimiento de SoapUI son estructurales. Ninguna cantidad de ajustes cambia:

• Renderizado de la interfaz de usuario Swing. La interfaz siempre se sentirá más lenta que una aplicación nativa o web. Swing era de vanguardia en el año 2000. Ahora no lo es.
• Inicio de la JVM. Puede reducirlo. No puede eliminarlo.
• Análisis de WSDL de un solo hilo. SoapUI analiza los WSDLs secuencialmente. Los WSDLs grandes y complejos con muchos esquemas importados tardan tiempo, y no hay paralelismo para configurar.
• Sobrecarga de memoria. La JVM, Swing y el framework Spring juntos consumen memoria independientemente del tamaño del proyecto. 300-400 MB en inactivo es típico.

Cuándo seguir adelante

Si ha aplicado las soluciones anteriores y SoapUI sigue bloqueando su flujo de trabajo, el cuello de botella podría no ser solucionable mediante la configuración.

Apidog se ejecuta como una aplicación web respaldada por un cliente Node.js, no una JVM. Se abre en segundos. La ejecución de pruebas no requiere un tiempo de ejecución de Java en su máquina. Para los equipos cuyo principal cuello de botella es el tiempo de inicio de SoapUI y la capacidad de respuesta de la interfaz de usuario, cambiar de herramienta es más productivo que el ajuste continuo de la JVM.

La contrapartida: Apidog no analiza WSDL. Si depende de la importación de WSDL de SoapUI para la incorporación de nuevos servicios, es posible que desee mantener SoapUI disponible para esa tarea específica mientras realiza las pruebas diarias en Apidog.

Preguntas frecuentes

¿Cuál es el tamaño de heap recomendado para SoapUI con un proyecto grande (más de 50 suites de prueba)?Establezca -Xmx en al menos 2 GB, idealmente 4 GB si su máquina tiene 16 GB o más de RAM. Establezca -Xms en 512 MB a 1 GB para evitar la expansión gradual del heap. Use -XX:+UseG1GC para un mejor comportamiento de la recolección de basura.

¿Puedo verificar el uso actual del heap de SoapUI?Sí. Vaya a Ayuda > Propiedades del sistema. Esto muestra los argumentos de la JVM, incluida la configuración del heap. También puede agregar -verbose:gc a las opciones de la JVM temporalmente para ver la actividad de recolección de basura en el registro de SoapUI.

¿Cambiar a un JDK más nuevo mejora el rendimiento de SoapUI?En la mayoría de los casos, sí. El tiempo de inicio de la JVM y la recolección de basura han mejorado en Java 11 y 17 en comparación con Java 8. Consulte las notas de la versión de SoapUI para conocer la versión de JDK recomendada, ya que algunas versiones más nuevas de JDK tienen problemas de compatibilidad con versiones anteriores de SoapUI.

¿Por qué SoapUI se ralentiza después de ejecutar pruebas durante unas horas?La fragmentación de la memoria y la sobrecarga de la recolección de basura aumentan con el tiempo. Cerrar y volver a abrir SoapUI restablece el estado de la JVM. Aumentar -Xmx y usar G1GC retrasa esta degradación, pero no la elimina.

¿Ejecutar SoapUI en un servidor (sin interfaz gráfica) mejora el rendimiento?Sí, en cierta medida. El modo sin interfaz gráfica (-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false y banderas similares) reduce la sobrecarga de renderizado de Swing. Use el ejecutor de pruebas de línea de comandos para CI/CD en lugar de la GUI para obtener el mejor rendimiento.

¿Cómo maneja Apidog las colecciones grandes en comparación con SoapUI?Apidog almacena las colecciones en la nube y las carga bajo demanda. No hay un archivo XML local que analizar. La ejecución de pruebas utiliza un ejecutor CLI local que no requiere la inicialización de la JVM.

La mayoría de los problemas de rendimiento de SoapUI tienen soluciones. El cambio en el tamaño del heap por sí solo a menudo tiene un efecto visible e inmediato. Comience por ahí antes de probar soluciones más complejas.