Análise de desempenho entre serviços web SOAP e RESTful utilizando a ferramenta Apache jmeter

Transcrição

1 ISSN T.I.S. São Carlos, v. 4, n. 1, p , jan-abr 2015 Tecnologias, Infraestrutura e Software Análise de desempenho entre serviços web SOAP e RESTful utilizando a ferramenta Apache jmeter 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 São Carlos SP Brasil Autor para correspondência: leandroperesphp@gmail.com, reinaldo@ufscar.br

2 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 52

3 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

4 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 54

5 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

6 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: 56

7 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 para processar as requisições, enquanto que o SOAP teve o maior tempo de 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

8 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 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 JMETER, A.. Aplicação desktop projetada para testes de carga e medidas de performance. Technical report, Apache Software Foundation. Disponível em: < Acesso em: 21 ago FIELDING, R. T. Architectural styles and the design of network-based software architectures. Tese de Doutorado, University Of California, Irivine, SHI, X. Sharing service semantics using SOAP-based and REST Web services. IT Professional THOMAS, E. SOA Principles of Service Design. New York. Prentice Hall, WEBBER, J., PARASTATIDIS, S., ROBINSON, I. REST in Practice. Sebastopol: O'Reilly, W3C. Web Services Architecture Disponível em < Acesso em: 27 jul W3SCHOOLS. SOAP TUTORIAL, Informações sobre padrões Web. Disponível em: < Acesso em: 23 agosto 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