Análise de desempenho entre serviços web SOAP e RESTful

ISSN 2316-2872
T.I.S. São Carlos, v. 4, n. 1, p. 51-58, jan-abr 2015
©Tecnologias, Infraestrutura e Software
Análise de desempenho entre serviços web SOAP
e RESTful utilizando a ferramenta Apache jMeter
Leandro Peres Gonçalves, Reinaldo de Oliveira Castro
Resumo: Este artigo apresenta uma análise de desempenho entre web services, mais especificamente comparando as implementações SOAP e
RESTful nos quesitos: tempo médio de resposta de requisição, tempo mínimo de resposta por requisição, tempo máximo de resposta por
requisição, menor desvio padrão por requisição e volume de transferência de dados por segundo para processar requisições. Os resultados
deste trabalho estão direcionados para a análise de desempenho entre serviços web, mais especificamente entre os serviços SOAP e RESTful,
utilizando a ferramenta Apache jMeter.
Palavras Chave: web services, SOAP, RESTful
Analyzing performance between SOAP and RESTful web services using Apache jMeter tool
Abstract: This paper presents a performance analysis of web services, specifically comparing SOAP and RESTful implementations in the
following categories: request average response time, minimum response time per request, maximum response time per request, lower standard
deviation per request and data transfer volume per second to process requests. The results of this work point to the performance analysis
among web services, specifically between SOAP and RESTful services using the Apache jMeter tool. .
Keywords: Web services, SOAP, RESTful
1. INTRODUÇÃO
Com a popularização da internet e a necessidade de
integração entre sistemas de informação, tornou-se necessário
a centralização de informações para serem acessados por
diferentes aplicações. Para esse propósito, foi criada a
tecnologia de web services.
De acordo com W3C (2004), a definição de web services é
descrita da seguinte forma:
Um web service é um sistema de software
desenvolvido para permitir interações máquina-máquina
através de uma rede. É uma interface descrita para ser
consumida por máquinas (WSDL). Outros sistemas
interagem com o Web Service através de mensagens
SOAP, geralmente enviadas através de HTTP em
conjunto com outros padrões relacionados à web.
Os web services permitem que sistemas desenvolvidos em
diferentes linguagens, sendo executados em diferentes
plataformas de hardware, transmitam e recebam informações
entre si, permitindo uma interação de forma distribuída.
Em meados dos anos 2000, a W3C (World Wide Web
Consortium) aceitou a submissão do Simple Object Access
Protocol (SOAP). Este formato de mensagem baseado em
XML estabeleceu uma estrutura de transmissão para
comunicação entre aplicações (ou entre serviços web) via
HTTP. Sendo uma tecnologia independente de fornecedor, o
protocolo SOAP disponibilizou uma alternativa atrativa em
relação aos protocolos proprietários tradicionais da época, tais
como CORBA e DCOM. (THOMAS, 2007). O SOAP
(Simple Object Access Protocol ou Protocolo Simples de
Acesso a Objetos) é um protocolo de comunicação baseado
em XML que possibilita a comunicação de mensagens entre
aplicações por meio de HTTP (Hypertext Transfer Protocol),
e que é normalmente utilizado em web services
(W3SCHOOLS, 2014).
Nos últimos anos, uma nova categoria de serviços web,
denominados serviços web RESTful vem ganhando espaço e
sendo aplicada em empresas de desenvolvimento de software
que necessitam realizar as comunicações entre sistemas
heterogêneos. Os serviços web RESTful são serviços que se
apoiam no estilo arquitetural REST (Representational State
Transfer) e que usam os recursos disponíveis no protocolo
HTTP (FIELDING, 2000).
Serviços web RESTful manipulam recursos que são
qualquer item de informação que pode ser obtido por meio de
um URI (Universal Resource Identifier). Os recursos são
manipulados via transferências de representações entre
clientes e servidores utilizando a interface do protocolo
HTTP. A interface é composta, principalmente, pelos verbos
POST, GET, PUT e DELETE. POST cria um novo recurso;
GET recupera o estado corrente de um recurso em qualquer
representação; PUT modifica o estado de um recurso já
existente; DELETE exclui um recurso (WEBBER,
PARASTATIDIS e ROBINSON, 2010).
Nesse contexto, o objetivo deste trabalho é realizar uma
Departamento de Computação - Universidade Federal de São Carlos (UFSCar)
Caixa Postal 676 – 13.565-905 – São Carlos – SP – Brasil
Autor para correspondência: [email protected], [email protected]
Leandro Peres Gonçalves, Reinaldo de Oliveira Castro
análise de performance entre esses dois protocolos, por meio
da ferramenta jMeter. Com os resultados alcançados pelo
presente trabalho, é possível que profissionais da área de
engenharia de software tomem decisões na escolha da
tecnologia de web service, considerando o contexto do
projeto em que atua ou vai atuar.
O artigo está organizado da seguinte forma: a seção 2
apresenta a ferramenta de teste utilizada; na seção 3, é
apresentado o estudo de caso utilizado para o
desenvolvimento do trabalho; na seção 4, são apresentados os
resultados do presente trabalho; na seção 5, são apresentados
os trabalhos relacionados; e por fim, na seção 6, é
apresentado a conclusão e as considerações finais.
II. F ERRAMENTA DE TESTE
A ferramenta utilizada para testar o desempenho dos web
services no presente trabalho foi o Apache jMeter (Versão
2.11).
O Apache JMeter é uma aplicação desktop projetada para a
realização de testes de desempenho e estresse em aplicações
cliente/servidor, como por exemplo aplicações Web. Ele pode
ser utilizado para simular cargas de trabalho em um servidor,
rede, aplicações ou mesmo em um objeto, testando sua
robustez. O desenvolvedor original do Apache jMeter foi
Stefanno Mazzochi, membro da Apache Software
Foundation. Atualmente a ferramenta, que é Open Source, é
resultado do trabalho de milhares de pessoas (JMETER,
2014).
Na figura 1 é mostrado a tela inicial do jMeter. O arquivo
executável do aplicativo está localizado na pasta bin/jmeter
do local de instalação. O jMeter necessita da máquina virtual
Java instalada para ser executado.
Figura 1. Tela Inicial do Apache jMeter
Na Figura 2 é apresentado um Grupo de Usuários para
Na tela inicial do jMeter é onde configura-se o Plano de
executar
as requisições aos web services.
Teste, que contém todos os elementos de um projeto criado no
jMeter.
Figura 2. Grupo de usuários do Apache jMeter
T.I.S. 2015; 4 (1): 51-58
52
Análise de desempenho entre serviços web SOAP e RESTful utilizando a ferramenta Apache jMeter
tempo que o jMeter leva para inicializar todos os
usuários. Por exemplo, se um período de 5 segundos for
setado, o jMeter vai terminar de iniciar todos os
usuários até o final desses 5 segundos. O valor 0
definido neste campo significa para começar
imediatamente todos os usuários;
Contador de Interação: configura quantas vezes o
teste será repetido. Por exemplo, se for configurado
uma contagem 1, o teste será executado apenas uma
vez.
Alguns parâmetros em Grupo de Usuários foram
configurados para a execução dos testes, sendo (JMETER,
2014):
Nome: descrição do grupo de usuário que está sendo
criado;
Número de Usuários Virtuais (threads): quantidade
de usuários que enviam os pedidos HTTP para os
serviços web;
Tempo de inicialização (em segundos): quantidade de
Figura 3. Requisição HTTP do Apache jMeter.
Na figura 3 é apresentada a interface para configurar uma
onde se localiza o servidor de aplicação;
REQUISIÇÃO HTTP, que foi o tipo de requisição utilizado
Número da Porta: porta do servidor onde se localiza
para o teste do web service RESTful.Os parâmetros
o servidor de aplicação;
configurados na interface em Requisição HTTP (JMETER,
Caminho: URL do web service, que concatenada
2014) foram:
com o Nome do Servidor ou IP forma a URL completa.
Na Figura 4 é apresentado a interface de configuração de
Nome: descrição da Requisição HTTP que está sendo
uma REQUISIÇÃO SOAP/XML-RPC, que foi o tipo
criada;
Nome do servidor ou IP: nome ou o IP do servidor utilizado para o teste do web service SOAP.
Figura 4. Requisição SOAP/XML-RPC do Apache jMeter
Nome: descrição do SOAP/XML-RPC que está
Os parâmetros configurados na interface Requisição
sendo criado;
SOAP/XML-RPC (JMETER, 2014) foram:
53
T.I.S. 2015; 4 (1): 51-58
Leandro Peres Gonçalves, Reinaldo de Oliveira Castro
URL: URL do web service;
Dados SOAP/XML-RPC: requisição SOAP utilizada
para dizer ao serviço web qual o método que ele deve
executar.
Para o entendimento dos resultados deste trabalho, é
apresentado os conceitos sobre o relatório agregado (gráfico).
Segundo JMETER (2014), o relatório agregado cria uma
linha na tabela para cada solicitação com nome diferente.
A cada solicitação é totalizado as informações de resposta e
fornecido a contagem do pedido, o minimo, o máximo, a
média, a taxa de erro, a vazão aproximada (requisição /
segundo) e os kilobytes por segundo de transferência
(JMETER, 2014).
Uma vez que o teste é realizado, o throughput (em
português “rendimento”) é o meio para a realização de todo o
teste. O throughput é calculado a partir do ponto de vista do
alvo de amostragem (por exemplo, o servidor remoto, no caso
de amostras de HTTP) (JMETER, 2014).
Alguns parâmetros do relatório agregado são explicados a
seguir (JMETER, 2014).
Label ou URL: nome do rótulo que está dentro de
Grupo de Usuários;
Amostras: número de amostras com o mesmo nome;
Média: tempo médio, em milissegundos, de um
conjunto de dados;
Desvio: O desvio padrão apresenta os casos em que
amostras se afastam do comportamento médio das
demais amostras utilizadas em razão do tempo de
resposta. Quanto menor for este valor, mais consistente
é o padrão de tempo das amostras coletadas;
Min: menor tempo, em milissegundos, entre todas as
amostras;
Max: maior tempo, em milissegundos, entre todas as
amostras;
Erros: pedidos com erros;
Vazão: taxa de transferência é medida em
solicitações por segundo/minuto/ hora;
KB/s: fluxo medido em kilobytes por segundo.
III. ESTUDO DE CASO: S ISTEMA DE GERENCIAMENTO DE
EVENTO DA UFS CAR
O Sistema de Gerenciamento de Eventos da UFScar tem
por objetivo apresentar um banco de dados de usuários
qualificados para agendar eventos, requisitar áreas de eventos,
entre outras possibilidades. O Sistema permite também o
cadastro de todos os locais de evento com suas características,
portanto possui uma administração do tipo cadastrar, editar,
consultar e deletar.
Figura 5. Diagrama Entidade-Relacionamento do Sistema de Gerenciamento de Eventos da UFSCar
Na Figura 5 é apresentado o diagrama entidaderelacionamento do sistema de gerenciamento de eventos da
UFSCar. A tabela utilizada para os testes de desempenho foi a
local_evento. Essa tabela é responsável por armazenar o
código (único), nome do local, o limite para lotação, se o
evento está disponível, a sigla, o endereço e a cidade onde vai
acontecer o evento.
A configuração da máquina utilizada para o teste de
desempenho é descrita na Tabela 1.
Tabela 1. Configuração da máquina utilizada para o teste de
desempenho
T.I.S. 2015; 4 (1): 51-58
54
Análise de desempenho entre serviços web SOAP e RESTful utilizando a ferramenta Apache jMeter
Para o teste foi utilizado a tabela local_evento com quinze
registros, como é mostrado na Figura 6.
Figura 6. Dados da tabela local_evento
Os serviços web SOAP e RESTful consumiram os dados
A solicitação e a resposta do web service SOAP é
da tabela local_evento, para ter um fator de medição de demonstrado a seguir.
desempenho para a execução dos testes.
Figura 7. Serviço web SOAP
A solicitação do web service RESTful consiste em uma
Na Figura 7 o serviço SOAP solicitou o local do evento
com código 1 (no caso Teatro Paulo Marcos) e retornou um chamada HTTP, como demonstrado na figura 3.
A resposta do web service RESTful é demonstrado a
arquivo XML, contendo os registros referentes ao código
seguir.
solicitado.
Figura 8. Serviço web RESTful
55
T.I.S. 2015; 4 (1): 51-58
Leandro Peres Gonçalves, Reinaldo de Oliveira Castro
Na Figura 8 o serviço RESTful retornou um arquivo JSON,
contendo todos os dados da tabela local_evento.
Com os dois web services funcionando, foi possível
executar o teste por meio da ferramenta jMeter,
separadamente, gerando os gráficos para cada tipo de web
service (SOAP x RESTful).
4. RESULTADOS
Para demonstrar os resultados apresentados pelo presente
trabalho, foi utilizado o relatório agregado em forma de
gráfico.
Na Figura 9 é apresentado o relatório agregado do web
service SOAP.
Figura 9. Relatório agregadodo web service SOAP
Os dados relevantes apresentados na Figura 9 são:
Tabela 2. Dados do relatório agregado do web service SOAP
Na Figura 10 é apresentado o relatório agregado do web
Figura 10. Relatório agregadodo web service RESTful
Os dados relevantes apresentados na Figura 10 são:
T.I.S. 2015; 4 (1): 51-58
56
Análise de desempenho entre serviços web SOAP e RESTful utilizando a ferramenta Apache jMeter
Tabela 3. Dados do relatório agregado do web service RESTful
services para se ter um melhor entendimento dos resultados.
Assim sendo, separamos a tabela dividindo por web
Tabela 4. Dados dos relatórios agregados dos web services SOAP e RESTful
De acordo com a Tabela 4, é possível concluir que o web
service RESTful, tendo o mesmo número de amostras do web
service SOAP, possui uma menor média, um menor desvio,
um menor mínimo, um menor máximo, uma menor vazão e
um maior número de kilobytes por segundo.
Comparando ambos os web services baseando-se na Tabela
4, temos:
Amostras: tanto o web service do tipo RESTful
quanto SOAP possuem o mesmo número de amostras,
no caso 2000;
Média: o web service do tipo RESTful foi superior
em aproximadamente 227,59%, tendo o menor tempo
de resposta em 116 milissegundos, enquanto que o
SOAP teve um maior tempo de resposta em 380
milissegundos;
Desvio: o web service do tipo RESTful foi superior
em aproximadamente 253,93%, tendo o menor desvio
em 89, enquanto que o SOAP teve um maior desvio em
315;
Mínimo: o web service do tipo RESTful foi superior
em aproximadamente 27,27%, tendo o menor tempo de
resposta em 11 milissegundos, enquanto que o SOAP
teve o menor tempo de resposta em 14 milissegundos.
Máximo: o web service do tipo RESTful foi superior
em aproximadamente 161,70%, tendo o maior tempo
de resposta em 470 milissegundos, enquanto que o
SOAP teve o maior tempo de resposta em 1230
milissegundos.
KB/s: o web service do tipo RESTful foi superior
em aproximadamente 163,72%, tendo o menor tempo
de 278.54 para processar as requisições, enquanto que
o SOAP teve o maior tempo de 734.57 para processar
as requisições.
Assim, com os resultados obtidos por este trabalho,
chegou-se a conclusão que o web service RESTful obteve
melhor desempenho em relação ao web service SOAP em
todos os quesitos analisados.
na densidade espacial de pontos; o código-fonte com a parte
prática do trabalho (utilizando a linguagem PHP); a
codificação dos web services, utilizando os recursos da
própria linguagem para criar o serviço RESTful, e, para criar
o serviço SOAP, foi utilizado a biblioteca NUSOAP; por fim,
o resultado aplicado para medir o tempo de execução.
A forma como é medido o tempo de execução no trabalho
de Bigolin (2012) difere da deste trabalho, pois somente mede
o tempo em segundos. Neste trabalho, além das métricas de
tempo (Média, mínimo, máximo), foi medido o desvio, a
vazão e o KB/s, por meio da ferramenta Apache jMeter.
Também foi utilizado dois mil usuários para simular o acesso
real de uma aplicação em produção. Já no trabalho do autor
não se tem nenhuma quantidade de usuários para realizar a
carga sobre os web services.
No trabalho de Shi (2006), o foco é web services
semânticos. É explorado o que SOAP e RESTful têm em
comum. É apresentado um estudo que relaciona os web
services e a web semântica, ambos sobre o protocolo HTTP e
sem a utilização de frameworks, tais como SOAP ou WSDL.
De acordo com o autor, este método viabiliza aos usuários
utilizar e compartilhar serviços por meio da computação
distribuída.
O trabalho de Shi (2006) foca na teoria, explicando as
vantagens e desvantagens de ambos os web services, sem
nenhum dado real para comprovação de tais vantagens e
desvantagens. Neste trabalho, além da teoria, foi apresentado
um estudo de caso de um sistema real, no caso Gerenciamento
de Eventos da UFSCar. Além disso, é realizado testes de
desempenho com a ferramenta Apache jMeter para se ter uma
análise prática dos web services, possibilitando assim uma
análise mais aproximada de uma aplicação em produção.
6. CONCLUSÃO
Cada vez mais existe a necessidade de intercomunicação
entre sistemas distintos, mesmo para aplicações de pequeno
porte. Um exemplo claro é o grande número de aplicativos
que se conectam na rede social Facebook, que, por sua vez,
disponibiliza um conjunto de API's para consumo por parte
dos desenvolvedores.
Essas API's nada mais são do que serviços web
disponibilizados para serem consumidos por aplicações
externas, que precisam de dados que estejam na plataforma
Facebook. Para tanto, fazem o consumo do serviço por meio
de web services, sem acessar diretamente as base de dados da
rede social.
5. TRABALHOS RELACIONADOS
Bigolin (2012) realiza uma análise e implementação de
web services, mais especificamente SOAP e RESTful. São
apresentadas as definições de SOAP e RESTful, abordando os
conceitos das duas tecnologias e realizando um comparativo
entre elas. O trabalho foi estruturado da seguinte forma: uma
contextualização do problema de implementação, que consiste
57
T.I.S. 2015; 4 (1): 51-58
Leandro Peres Gonçalves, Reinaldo de Oliveira Castro
Nesse contexto, com a pesquisa realizada por este trabalho,
foi possível confirmar que o serviço web RESTful é mais
performático que o web service SOAP.
O teste realizado no presente trabalho demonstrou que o
web service RESTful é mais rápido do que o web service
SOAP nos quesitos tempo médio de resposta, desvio padrão,
tempo mínimo de resposta, tempo máximo de resposta,
vazão, e menor tempo em kilobytes para processar as
informações, utilizando o mesmo número de amostras (duas
mil).
Acreditamos que isso acontece por diversos fatores, sendo
eles (MORO et al., 2011):
O RESTful utiliza somente HTTP para transportar
as informações, e SOAP trabalha com envelopes
envolvidos sobre o HTTP. Isso afeta o desempenho,
pois os pacotes SOAP devem sofrer um parse antes de
os dados serem utilizados;
Na comunicação Cliente/Servidor, nenhum estado é
mantido (stateless) no uso de RESTful. Com SOAP, é
possível solicitar os dados de autenticação somente na
primeira requisição, salvando os mesmos na sessão do
servidor. Neste caso, com o RESTful, pode-se ganhar
desempenho, pois diferentemente do SOAP, o
RESTful não precisa armazenar o estado da
requisição.
Mas o principal deles é que web services RESTful são
baseados em JSON, um formato muito leve; em
contrapartida, os web services SOAP são baseados em XML,
um formato mais pesado, que exige um maior esforço da
parte da aplicação e, consequentemente, exige mais recursos
como memória e processamento no servidor.
Como trabalho futuro, pode-se realizar a separação e a
análise de desempenho com conexão (internet) e sem conexão
(local). Este trabalho não se preocupou em realizar a
separação com dois tipos de conexão, e sim focou em uma
análise com conexão local. Além disso, pode ser explorado a
T.I.S. 2015; 4 (1): 51-58
análise de desempenho em diferentes tipos de processadores,
o que resultaria em comparações mais voltadas para a área de
infraestrutura.
REFERÊNCIAS
BIGOLIN, M. Análise e implementação de web services.
Trabalho de Conclusão de Curso, Universidade Federal do
Rio Grande do Sul, Instituto de Informática. 2012.
JMETER, A.. Aplicação desktop projetada para testes de
carga e medidas de performance. Technical report, Apache
Software
Foundation.
Disponível
em:
<http://jakarta.apache.org/jmeter/>. Acesso em: 21 ago.
2014.
FIELDING, R. T. Architectural styles and the design of
network-based software architectures. Tese de Doutorado,
University Of California, Irivine, 2000.
SHI, X. Sharing service semantics using SOAP-based and
REST Web services. IT
Professional. 2006.
THOMAS, E. SOA Principles of Service Design. New York.
Prentice Hall, 2007.
WEBBER, J., PARASTATIDIS, S., ROBINSON, I. REST in
Practice. Sebastopol: O'Reilly, 2010.
W3C. Web Services Architecture. 2004. Disponível em
<http://www.w3.org/TR/2004/NOTE-ws-arch-20040211>.
Acesso em: 27 jul. 2014
W3SCHOOLS. SOAP TUTORIAL, 2014. Informações sobre
padrões
Web.
Disponível
em:
<http://www.w3schools.com/soap/default.asp>. Acesso
em: 23 agosto 2014.
MORO, T. D.; DORNELES, C. F.; REBONATTO, M. T. Web
services WS-* versus Web Services REST. Universidade
de Passo Fundo (UPF), Instituto de Ciências Exatas e
Geociências. 2011.
58