SoapUI Lento: Causas e Como Melhorar o Desempenho

Resumo

O desempenho lento do SoapUI provém da sobrecarga de inicialização da JVM, configurações de memória padrão muito baixas para projetos grandes e atrasos na análise de WSDL. Correções específicas (ajuste do tamanho da heap, cache de WSDL, divisão de projetos) podem melhorar significativamente a velocidade. Se sua equipe precisa de uma ferramenta mais rápida que evite esses gargalos por completo, o Apidog funciona sem um ambiente de execução Java.

💡

Apidog é uma plataforma gratuita e completa para desenvolvimento de API que funciona em um navegador ou aplicativo de desktop leve, evitando totalmente a sobrecarga da JVM e o ajuste de memória. Experimente o Apidog gratuitamente, sem necessidade de cartão de crédito.

botão

Introdução

O SoapUI é lento. Se você o usou por mais de algumas semanas, já deve ter experimentado a inicialização de 30 segundos, a interface de usuário que não responde enquanto analisa um WSDL grande, ou a execução de testes que se arrasta quando você tem centenas de etapas de teste. Estes não são bugs. São o resultado natural de como o SoapUI foi construído.

Este guia explica as razões técnicas específicas pelas quais o SoapUI é lento, oferece soluções concretas para cada uma delas e explica onde estão os limites. Algumas lentidões você pode corrigir. Outras, não, sem trocar de ferramentas.

Causa raiz 1: Sobrecarga de inicialização da JVM

O SoapUI é um aplicativo Java Swing. Cada vez que você o inicia, ele inicializa uma Java Virtual Machine (JVM), carrega centenas de arquivos de classe, inicializa o framework Spring, carrega seu projeto e renderiza a interface Swing. Em uma máquina moderna com SSD, isso leva de 20 a 60 segundos. Em hardware mais antigo, pode exceder 90 segundos.

Por que isso acontece: Aplicativos Java pagam um custo de inicialização que aplicativos nativos não pagam. A JVM precisa interpretar ou compilar JIT o bytecode antes que a execução comece. A inicialização da interface de usuário Swing adiciona a isso.

Soluções:

Mantenha o SoapUI aberto. A solução mais simples é não fechá-lo entre as execuções de teste. Uma vez que a JVM está em execução, ela permanece "quente".

Use um disco rápido. Se você está executando o SoapUI a partir de um disco rígido giratório, mova-o para um SSD. A fase de carregamento de classes lê muitos arquivos pequenos, e é exatamente onde os SSDs superam os HDDs.

Use Java 11 ou 17 em vez de 8. Versões mais recentes da JVM têm tempos de inicialização melhorados. Verifique qual JDK o SoapUI está configurado para usar em soapui.bat (Windows) ou soapui.sh (Linux/Mac). A primeira linha define o caminho do Java home. Mudar para um JDK mais recente pode reduzir o tempo de inicialização.

Habilite o AppCDS (Application Class Data Sharing). Este recurso da JVM pré-armazena em cache os dados de carregamento de classes. Requer uma configuração única, mas reduz os tempos de inicialização subsequentes. Adicione -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa aos seus argumentos da JVM.

Causa raiz 2: Configurações de memória padrão são muito baixas

O SoapUI vem com configurações de tamanho de heap padrão baixas. Abrir um projeto grande ou executar uma longa suíte de testes faz com que a JVM gasta tempo com a coleta de lixo, o que pausa o aplicativo e o torna lento.

Configurações padrão (de soapui.vmoptions ou soapui.bat):

-Xms128m
-Xmx768m

Isso significa que o SoapUI inicia com 128 MB de heap e pode usar um máximo de 768 MB. Máquinas modernas têm de 8 a 32 GB de RAM. Deixar o SoapUI em 768 MB causa pressão constante da coleta de lixo em qualquer projeto grande.

Solução: aumentar o tamanho da heap

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

-Xms512m
-Xmx2048m

No macOS, edite o SoapUI.app/Contents/vmoptions.txt ou encontre soapui.sh:

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

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

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

Recomendações:

Defina -Xms (heap inicial) para 512 MB ou mais, se você tiver RAM de sobra. Isso evita a expansão gradual da heap.
Defina -Xmx (heap máxima) para 2 GB para projetos médios, 4 GB para projetos grandes. Não o defina para mais da metade da sua RAM disponível.
Adicione -XX:+UseG1GC se você estiver usando Java 9+. O G1GC reduz os tempos de pausa em comparação com o coletor de lixo padrão.
Adicione -XX:MaxMetaspaceSize=512m para evitar que o metaspace (metadados de classe) cresça sem limites.

Verificando a solução: Após reiniciar o SoapUI, abra a caixa de diálogo Ajuda > Propriedades do Sistema. Você deverá ver os valores de heap atualizados. Monitore o gerenciador de tarefas para confirmar que o SoapUI está usando a nova alocação.

Causa raiz 3: Arquivos de projeto grandes

O SoapUI armazena tudo em um único arquivo XML. Projetos com muitas suítes de teste, corpos de requisição grandes ou dados binários embutidos incham este arquivo. Abrir e salvar um arquivo de projeto de 10 MB é visivelmente mais lento do que um de 500 KB.

Sinais deste problema:

O SoapUI pausa por vários segundos ao salvar (Ctrl+S)
O arquivo de projeto no disco tem vários megabytes
Abrir o projeto leva mais de 10 segundos depois que o SoapUI já está em execução

Soluções:

Divida projetos grandes. O SoapUI suporta projetos compostos que armazenam suítes de teste como arquivos XML separados em um diretório. Habilite isso em Projeto > Configurações > Projeto Composto. Isso permite carregamento parcial e salvamentos mais rápidos.

Remova casos de teste não utilizados. Arquive ou exclua casos de teste que não são mais relevantes. Cada caso de teste com scripts e dados de requisição contribui para o tamanho do XML.

Externalize corpos de requisição grandes. Se suas etapas de teste usam corpos XML ou JSON grandes embutidos, considere parametrizá-los e carregá-los de arquivos externos usando o DataSource baseado em arquivo do SoapUI.

Desabilite o backup automático "salvar ao sair". O SoapUI cria cópias de backup ao sair. Desabilite isso em Preferências > Configurações da UI para evitar a gravação extra no disco ao fechar.

Causa raiz 4: Atrasos na análise de WSDL

Quando o SoapUI abre um projeto que referencia arquivos WSDL, ele pode reanalisar esses WSDLs na inicialização ou quando você expande a árvore da interface. Se seus WSDLs estiverem hospedados em um servidor remoto ou forem grandes (muitas operações, tipos complexos), essa análise adiciona atrasos significativos.

Sinais deste problema:

O SoapUI trava ou mostra um indicador de carregamento ao expandir uma interface
Os testes falham com erros de tempo limite de conexão antes de começarem
Máquinas diferentes carregam o projeto em velocidades diferentes (dependência de rede)

Soluções:

Armazene WSDLs em cache localmente. No SoapUI, clique com o botão direito do mouse em uma interface > Atualizar Definição. Altere a URL de definição para apontar para uma cópia local do arquivo WSDL em vez da URL remota. Isso elimina a latência da rede a cada carregamento.

Defina URLs de definição para caminhos file://. Depois de ter uma cópia local do WSDL, atualize a URL de definição da interface para file:///caminho/para/seu/servico.wsdl. O SoapUI carrega isso do disco instantaneamente.

Desabilite a atualização automática de definição. Em Preferências > Configurações de WS-Security, desmarque as opções que forçam a revalidação de WSDL na inicialização.

Aumente as configurações de tempo limite HTTP. Se os WSDLs de rede demoram para responder, vá para Preferências > Configurações HTTP e aumente o tempo limite da conexão. Isso evita que o SoapUI trave indefinidamente em um servidor WSDL lento.

Causa raiz 5: Desempenho da execução de testes em grandes suítes

Executar uma suíte de testes com centenas de casos de teste pode ser lento, especialmente quando cada etapa de teste possui scripts Groovy complexos, asserções ou chamadas de rede.

Soluções:

Execute suítes em paralelo. O SoapUI suporta a execução paralela de suítes de teste. No executor de TestSuite, habilite a opção “Executar casos de teste concorrentemente”. Certifique-se de que seu serviço SOAP lida com conexões concorrentes.
Desative asserções desnecessárias. Cada asserção que o SoapUI avalia adiciona tempo de processamento. Audite suas etapas de teste e remova as asserções que não verificam nada significativo.
Otimize scripts Groovy. Scripts Groovy são executados de forma interpretada no SoapUI. Evite operações caras em scripts que são executados para cada etapa de teste (análise de strings, regex, criação de objetos grandes). Mova a lógica compartilhada para bibliotecas de scripts de nível de projeto.
Use asserções de tempo de resposta com cuidado. Asserções de SLA de resposta esperam pelo tempo limite completo antes de falhar. Se você tiver asserções de SLA rigorosas com longos tempos limite em endpoints não confiáveis, elas podem bloquear a suíte inteira.
Reduza a verbosidade do log. O SoapUI registra cada requisição e resposta por padrão. Para grandes suítes, essa E/S se acumula. Vá para Preferências > Configurações HTTP e reduza o que é registrado durante as execuções de teste.

O que você não pode corrigir

Alguns problemas de desempenho do SoapUI são estruturais. Nenhuma quantidade de ajustes muda:

Renderização da UI Swing. A interface sempre parecerá mais lenta que um aplicativo nativo ou web. O Swing era o que havia de mais avançado em 2000. Hoje não é.
Inicialização da JVM. Você pode reduzi-la. Você não pode eliminá-la.
Análise de WSDL single-threaded. O SoapUI analisa WSDLs sequencialmente. WSDLs grandes e complexos com muitos esquemas importados levam tempo, e não há paralelismo para configurar.
Sobrecarga de memória. A JVM, o Swing e o framework Spring juntos consomem memória, independentemente do tamanho do projeto. 300-400 MB em repouso é típico.

Quando seguir em frente

Se você aplicou as correções acima e o SoapUI ainda está bloqueando seu fluxo de trabalho, o gargalo pode não ser corrigível por meio de configuração.

O Apidog funciona como um aplicativo web suportado por um cliente Node.js, não por uma JVM. Ele abre em segundos. A execução de testes não requer um ambiente de execução Java em sua máquina. Para equipes cujo principal gargalo é o tempo de inicialização e a responsividade da UI do SoapUI, mudar de ferramenta é mais produtivo do que o ajuste contínuo da JVM.

A desvantagem: o Apidog não analisa WSDL. Se você depende da importação de WSDL do SoapUI para o onboarding de novos serviços, talvez queira manter o SoapUI disponível para essa tarefa específica enquanto executa os testes diários no Apidog.

FAQ

Qual é o tamanho de heap recomendado para o SoapUI com um projeto grande (mais de 50 suítes de teste)?Defina -Xmx para pelo menos 2 GB, idealmente 4 GB se sua máquina tiver 16 GB ou mais de RAM. Defina -Xms para 512 MB a 1 GB para evitar a expansão gradual da heap. Use -XX:+UseG1GC para um melhor comportamento de coleta de lixo.

Posso verificar o uso atual da heap do SoapUI?Sim. Vá para Ajuda > Propriedades do Sistema. Isso mostra os argumentos da JVM, incluindo as configurações de heap. Você também pode adicionar -verbose:gc às opções da JVM temporariamente para ver a atividade de coleta de lixo no log do SoapUI.

Mudar para um JDK mais recente melhora o desempenho do SoapUI?Na maioria dos casos, sim. O tempo de inicialização da JVM e a coleta de lixo melhoraram no Java 11 e 17 em comparação com o Java 8. Verifique as notas de lançamento do SoapUI para a versão do JDK recomendada, pois algumas versões mais recentes do JDK podem ter problemas de compatibilidade com versões mais antigas do SoapUI.

Por que o SoapUI fica lento depois de executar testes por algumas horas?A fragmentação da memória e a sobrecarga da coleta de lixo aumentam com o tempo. Fechar e reabrir o SoapUI redefine o estado da JVM. Aumentar -Xmx e usar o G1GC atrasa essa degradação, mas não a elimina.

Executar o SoapUI em um servidor (headless) melhora o desempenho?Sim, um pouco. O modo headless (-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false e flags semelhantes) reduz a sobrecarga de renderização do Swing. Use o testrunner de linha de comando para CI/CD em vez da GUI para o melhor desempenho.

Como o Apidog lida com grandes coleções em comparação com o SoapUI?O Apidog armazena coleções na nuvem e as carrega sob demanda. Não há arquivo XML local para analisar. A execução de testes usa um executor CLI local que não requer inicialização da JVM.

A maioria dos problemas de desempenho do SoapUI tem soluções. A alteração do tamanho da heap, por si só, geralmente tem um efeito imediato e visível. Comece por aí antes de tentar soluções mais complexas.