Java Web Services: Desempenho de Metro versus Axis2

Veja como o Metro se sai em relação ao desempenho do Axis2, ambos com e sem WS-Security

A pilha de serviços da Web Metro oferece a mesma funcionalidade da pilha Axis2, mas, apesar do uso opcional de JAXB e JAX-WS em Axis2, usa implementações completamente diferentes das tecnologias envolvidas. Neste artigo, Dennis Sosnoski dá continuidade à sua série de colunas de serviços da Web Java com uma comparação de desempenho entre as pilhas Metro e Axis2, ambas com e sem WS-Security.

Dennis Sosnoski, Architecture Consultant and Trainer, Sosnoski Software Solutions, Inc.

Author photoDennis Sosnoski é consultor e instrutor especializado em serviços de XML e Web baseados em Java. Possui experiência profissional de mais de 30 anos como desenvolvedor de software, tendo focado seu trabalho nos últimos 10 anos em tecnologias XML e Java no lado do servidor. Dennis é o desenvolvedor principal da estrutura de software livre JiBX XML Data Binding e da estrutura de serviços da Web associada JiBX/WS. Também é "committer" (pessoa autorizada a modificar o código fonte de um determinado software) na estrutura de serviços Web Apache Axis2. Também foi um dos membros do Expert Group para as especificações JAX-WS 2.0 e JAXB 2.0.



19/Jan/2010

A pilha de serviços da Web Metro é baseada nas implementações de referência da ligação de dados JAXB 2.x e dos padrões de serviços da Web JAX-WS 2.x, mas usa componentes adicionais para fornecer recursos além do suporte básico definido por JAX-WS. WS-Security e outras tecnologias de extensão SOAP são implementadas pelo projeto Web Services Interoperability Technologies (WSIT), com o processamento de WS-Security real implementado por outro componente adicionado: o XML and WebServices Security Project (XWSS) (consulte Recursos).

Sobre esta série

Os serviços de Web são uma parte crucial do papel desempenhado pela tecnologia Java na computação empresarial. Nesta série de artigos, o consultor de serviços de XML e Web Dennis Sosnoski cobre as principais estruturas e tecnologias importantes para desenvolvedores Java que utilizam serviços de Web. Acompanhe a série para manter-se informado com relação aos mais recentes desenvolvimentos da área e saber como utilizá-los para auxiliá-lo em seus projetos de programação.

Axis2 baseia em tecnologias completamente diferentes, incluindo a implementação da ligação de dados Axis2 Data Binding (ADB) padrão, o próprio mecanismo Axis2 e o módulo Rampart combinado com o Web Services Security for Java (WSS4J) para suporte de WS-Security. Um artigo anterior nesta série, "O Alto Custo de (WS-)Security", que mostrou o impacto do processamento de WS-Security no processamento da pilha de serviços da Web Axis2.

"Apresentando o Metro" e "WS-Security com Metro" mostraram como as duas pilhas são diferentes em termos de instalação, configuração e uso real. Este artigo observa as diferenças de desempenho entre os dois, incluindo as diferenças quando WS-Security é usado.

Observando o desempenho

Assim como "O Alto Custo de (WS-)Security", este artigo usa a abordagem de medição do tempo necessário para executar uma determinada sequência de solicitações quando o cliente e o servidor estão em execução em um único sistema. Essa abordagem faz o excelente trabalho de comparar o custo adicional de processamento dos serviços da Web, já que o impacto das latências de rede e o custo adicional são eliminados a partir dos resultados de tempo. Considerando que o código do cliente não é tão mais lento que o servidor, os dados são também boas representações do desempenho real do servidor sob carga.

Este artigo usa o mesmo aplicativo de teste do artigo anterior, um serviço de recuperação de dados sísmicos. O serviço usa um banco de dados real de mais de 93.000 terremotos que ocorreram no mundo todo em um período de vários anos. As solicitações do serviço especificam um intervalo de tempo e um intervalo de coordenadas geográficas, e o serviço retorna todos os terremotos dentro do intervalo especificado. Consulte "O Alto Custo de (WS-)Security" para detalhes completos e um par de mensagens de solicitação-resposta de amostra.

Assim como o artigo anterior, dois conjuntos de sequências de solicitações foram usados para os testes de desempenho. O primeiro conjunto usou 1000 solicitações, com parâmetros de consulta ajustados para corresponder a uma pequena porção de todo o banco de dados de terremotos (retornando apenas 816 terremotos correspondentes para as 1000 solicitações). O segundo conjunto usou 100 solicitações, ajustadas para corresponder a uma porção maior do banco de dados (retornando 176.745 terremotos correspondentes para as 100 solicitações). Cada sequência de solicitação foi executada várias vezes em diferentes configurações de segurança, com apenas o melhor tempo para cada configuração mantida nos resultados.

Os testes foram executados em um sistema Linux de 64 bits Mandriva 2009.1 com um processador Athlon X2 5400+ e 4 GB de RAM, usando uma JVM de 32 bits Sun Java 1.6.0_13 (que proporcionou um desempenho levemente melhor em relação à JVM de 64 bits para um determinado tamanho de heap). O código do servidor foi executado em Tomcat 6.0.20, configurado para usar 1024 MB do heap, com o código do cliente usando 512 MB de heap. As versões de pilha do serviço da Web foram Metro 1.5 (que contém WSIT e XWSS) e Axis2 1.5.1 com um build atual do código Rampart (visto que não existe ainda nenhum release de Rampart correspondente ao código de Axis2 1.5.x). Se quiser tentar os testes em seu próprio hardware e sua própria JVM, faça o download do código.

O artigo anterior observou apenas o desempenho de Axis2 e incluía texto simples, SSL e várias configurações de WS-Security/WS-SecureConversation. Este usa um conjunto mais limitado de configurações, mas compara diretamente o desempenho de Axis2 e Metro para cada configuração.


Desempenho sem WS-Security

A

Figura 1 os tempos de teste medidos para Axis2 e Metro sem nenhum uso de WS-Security. O gráfico mostra que existe apenas uma pequena diferente entre as duas pilhas. No teste com 1000 solicitações e pequenas respostas, Metro executou a tarefa meio segundo mais rápido do que Axis2. No teste com apenas 100 solicitações, mas maior número de respostas, as duas pilhas executaram a tarefa com igual rapidez (até 0,1 segundo).

Figura 1. Tempos de teste sem segurança
Bar graph of test times without security

Esses resultados de tempo mostram que (para os dados usados pelo aplicativo de teste) Metro é provavelmente um pouco mais rápido do que Axis2 no processamento por solicitação, mas, nas conversões de dados reais, os dois executaram a tarefa lado a lado (ao se usar a ligação de dados ADB padrão com Axis2 — outras ligações de dados podem apresentar resultados diferentes, e a ligação XMLBeans particularmente é conhecida por ser consideravelmente mais lenta).


Desempenho com WS-Security

As duas próximas figuras mostram os tempos de teste relativos para as seguintes configurações de segurança:

  • plain— Nenhuma segurança (os mesmos valores da Figura 1, mas normalizados para o tempo de Axis2)
  • username— Texto simples WS-Security UsernameToken em solicitações
  • sign— Assinatura WS-Security de corpo e cabeçalhos, com registro de data e hora
  • signencr— Assinatura WS-Security de corpo e cabeçalhos, com registro de data e hora e criptografia de corpo

A Figura 2 e a Figure 3 mostram os tempos medidos como múltiplos do tempo simples de Axis2, para facilitar a comparação dos resultados. A Figura 2 mostra os tempos para 1000 solicitações com respostas pequenas:

Figura 2. Teste de resposta pequena
Bar graph of small response test

A

Figura 3 mostra os tempos para 100 solicitações com respostas grandes:

Figura 3. Teste de resposta grande
Bar graph of large response test

Metro é consistentemente mais rápido do que Axis2 para as configurações de WS-Security — em geral, mais de duas vezes mais rápido, e mais de três vezes mais rápido no caso de configurações de nome de usuário e de assinatura para mensagens grandes. Esse é um resultado surpreendente para duas pilhas de serviços da Web no mesmo nível de desenvolvimento.

Rampart tem criação de log de tempo rudimentar integrada com o uso do criador de logs org.apache.rampart.TIME. Ao ativar esse criador de log no nível de DEBUG, você pode descobrir o tempo necessário para várias partes do processamento de Rampart. Estranhamente, quando eu fiz isso para o exemplo de assinaturas, descobri que os tempos de processamento de Rampart eram menos do que a metade do tempo total gasto para o teste. Isso significa que os problemas de desempenho principais com a manipulação de WS-Security de Axis2/Rampart estão fora de Rampart e da implementação de segurança de WSS4J subjacente.

Rampart certamente tem muito espaço ainda para melhorias. Como mencionado em "O Alto Custo de (WS-)Security", Rampart constrói um modelo dentro da memória completo da mensagem sempre que o processamento de WS-Security está envolvido. O custo adicional de criação do modelo dentro da memória é a causa aparente do baixo desempenho de Axis2/Rampart no caso UsernameToken. É possível que o baixo desempenho de Axis2/Rampart em outros cenários de WS-Security também esteja relacionado a esse mesmo tipo de problema de conversão.


Resumindo Metro

Metro pode ser inadequado para uso independente, especialmente devido à documentação limitada disponível (consulte Recursos). Metro também trabalha com a ligação de dados JAXB 2.x e a configuração de serviços da Web JAX-WS 2.x, ao contrário do intervalo maior de ligações de dados e da configuração alternativa suportados por Axis2. Mas Metro oferece desempenho igual a Axis2 para trocas de mensagens de texto simples e desempenho muito melhor do que Axis2 quando se envolve WS-Security. Se estiver usando WS-Security e estiver preocupado com o desempenho, você deverá definitivamente considerar o uso de Metro para o seu aplicativo.

O próximo artigo observa a pilha de serviços da Web CXF, outro projeto da Apache Foundation. CXF usa alguns dos mesmos componentes subjacentes de Axis2, mas um estilo muito diferente para configurar e implementar os serviços da Web. Você verá o básico sobre o uso de CXF e qual a diferença dele para Axis2 e Metro.


Download

DescriçãoNomeTamanho
Sample code for this articlej-jws11.zip3.7MB

Recursos

Aprender

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tecnologia Java
ArticleID=472252
ArticleTitle=Java Web Services: Desempenho de Metro versus Axis2
publish-date=01192010