5. METODE
5.5 I NNHOLD I SPØRREUNDERSØKELSEN
Devido `a dificuldade de acesso a um dispositivo real com o sistema operacional Android para a execu¸c˜ao dos prot´otipos desenvolvidos neste trabalho, avaliamos outras alter- nativas. A tabela 6.6 descreve o estudo realizado sobre a compatibilidade de recursos em navegadores Web para dispositivos m´oveis. O principal objetivo deste estudo ´e prover um dispositivo real capaz de executar o servi¸co DECS utilizando tecnologias Web para o desenvolvimento de aplica¸c˜oes. Neste estudo, consideramos as plataformas
6.3. An´alise de Desempenho e Escalabilidade 157
Tabela 6.6. Compatibilidade de navegadores Web para a execu¸c˜ao do DECS.
NavegadorWeb WebView Opera Mobile Skyfire Web Browser for
S60
Plataforma Google An-
droid
Sun JavaME S60/Symbian OS, Windows Mobile
S60/Symbian OS Tipo de avalia¸c˜ao Emulado via
SDK
Dispositivo real Dispositivo real Dispositivo real M´aquina de leiaute WebKit Presto Propriet´aria WebKit Renderiza¸c˜ao por servidor remoto N˜ao Opera Bi- nary Markup Language (OBML) [39] Gecko Runtime Environment N˜ao
Tipo de sa´ıda JavaScript e HTML
OBML Imagem Imagem
Suporte aGMaps Sim N˜ao Sim N˜ao
Suporte a
JavaScript
Limitado Limitado Sim limitado
Suporte a Adobe Flash
N˜ao N˜ao Sim N˜ao
Android, JavaME e Symbian OS e navegadores Web em cada uma das plataformas para os testes. Para os testes reais, utilizamos um dispositivo Nokia E65 com acesso a redes WLAN contendo as plataformas S60/Symbian e JavaME.
De todos os navegadores apresentados na tabela 6.6, o primeiro prot´otipo DECS foi capaz de ser executado apenas no navegador Skyfire instalado no dispositivo Nokia E65. Apesar da menor resolu¸c˜ao de tela em compara¸c˜ao a um dispositivo da plataforma Android, o dispositivo real foi capaz de acessar a aplica¸c˜ao Web localizada no servidor em nuvem e prover os recursos ass´ıncronos de eventos e mensagens.
Em rela¸c˜ao ao segundo prot´otipo do servi¸co DECS, a aplica¸c˜ao cliente n˜ao ex- ecutou em nenhum dos navegadores apresentados. Uma das principais raz˜oes que acreditamos estar relacionada a este fator est´a no fato de utilizarmos uma quantidade muita grande de recursos do GWT. O GWT converte o c´odigo desenvolvido inicial- mente em Java para JavaScript.
6.3
An´alise de Desempenho e Escalabilidade
O objetivo desta se¸c˜ao ´e apresentar a avalia¸c˜ao do desempenho e escalabilidade do servidor de eventos proposto neste trabalho. A avalia¸c˜ao foi realizada em termos da capacidade de gerenciamento de um n´umero consider´avel de usu´arios m´oveis concor- rentes (5 a 1000, 5000). Os testes de desempenho tˆeem como meta avaliar o tempo de resposta das principais opera¸c˜oes definidas e realizadas pelo servidor de eventos, enquanto os testes de escalabilidade de carga possuem como meta avaliar a escalabili- dade do servidor em situa¸c˜oes de aumento de carga. T´ınhamos o desejo de avaliar um n´umero maior de interfaces definidas no servidor, por´em isto n˜ao foi poss´ıvel devido
Quotas Quota Gratuita Quota Paga
Recurso Limite Di´ario Taxa M´axima Limite Di´ario Taxa M´axima
Requisi¸c˜oes 1.3M reqs/dia 7.4K reqs/min 43M reqs/dia 30K reqs/min
Dados transmiti-
dos
1 GB 7.4 GB/min 1 TB 10 GB/min
Dados recebidos 1 GB 56 MB/min 1 TB 10 GB/min
Tempo de CPU 6.5 CPU horas 15 CPU-
mins/min
1729 CPU horas 72 CPU-
mins/min
Tabela 6.7. As quotas providas pela infraestrutura do servidor em nuvem.
`as limita¸c˜oes impostas pelo plano gratuito de quota dispon´ıvel no servidor em nuvem1.
Sendo assim, fomos capazes de avaliar um subconjunto de todas as interfaces definidas e dispon´ıveis pelo servidor de eventos. A Tabela 6.7 apresenta as limita¸c˜oes impostas pela quota gratuita utilizada neste trabalho.
Na gest˜ao do consumo de recursos de aplica¸c˜oes em nuvem, o servidor em nuvem utiliza um conjunto predefinido de vari´aveis. Estes recursos est˜ao sujeitos `as quotas, e em casos em que eles s˜ao totalmente consumidos, o servidor em nuvem paralisa2 os
servi¸cos utilizados na aplica¸c˜ao por clientes Web. Al´em da quota gratuita, o servidor em nuvem fornece quotas pagas para o provimento adicional de recursos `as aplica¸c˜oes em nuvem. De todas as vari´aveis e recursos dispon´ıveis no servidor, consideramos os seguintes recursos para os nossos testes:
• Requisi¸c˜oes: O n´umero total de requisi¸c˜oes processadas pela aplica¸c˜ao e o tempo de resposta das requisi¸c˜oes.
• Largura de banda: A quantidade de dados enviados e recebidos pela aplica¸c˜ao nas requisi¸c˜oes.
• Tempo de CPU: O tempo total de processamento da CPU no servidor no pro- cessamento de requisi¸c˜oes, incluindo o tempo gasto pela aplica¸c˜ao e em opera¸c˜oes no DataStore. O DataStore ´e respons´avel por gerir opera¸c˜oes de dados (CRUD3,
requisi¸c˜oes SQL) sobre o SGBD utilizado pelo servidor.
• Tempo de execu¸c˜ao de ciclos: O tempo m´edio, m´ınimo e m´aximo de execu¸c˜ao dos ciclos de testes em clientes.
• Timeouts: A quantidade m´edia de timeouts ocorridos nos clientes em fun¸c˜ao de erros ocorridos no servidor.
• Eventos publicados e consumidos: O n´umero total de eventos publicados e consumidos pela thread cliente.
1
Informa¸c˜oes de Quota: http://code.google.com/appengine/docs/quotas.html
2
Nega¸c˜ao de quota ou ’quota denial ”
3
6.3. An´alise de Desempenho e Escalabilidade 159
• Nega¸c˜ao de quotas e erros: O n´umero total de erros ocorridos no servidor devido a nega¸c˜oes de quota ou erros internos.
Apesar de utilizarmos o plano gratuito de quotas, fomos capazes de avaliar o desempenho de uma boa parte das interfaces no servidor de eventos proposto neste trabalho. Dependendo dos tipos de testes realizados, os clientes foram capazes de consumir o limite di´ario imposto pelo plano em poucas horas. Isto nos obrigou a realizar os testes em intervalos regulares em diferentes dias, j´a que as limita¸c˜oes de quota s˜ao renovadas a cada 24 horas. Definimos neste trabalho trˆes principais testes:
• Teste 1: Avalia¸c˜ao de desempenho das opera¸c˜oes providas pelo servidor de even- tos.
• Teste 2: Avalia¸c˜ao da escalabilidade de carga na publica¸c˜ao de eventos por clientes m´oveis.
• Teste 3: Avalia¸c˜ao da escalabilidade no provimento de acesso por m´ultiplos clientes m´oveis.
Para o provimento dos clientes m´oveis nos testes acima, utilizamos a cria¸c˜ao e execu¸c˜ao de threads de processamento concorrente contendo as funcionalidades avali- adas. Estas threads foram acionadas a partir de um ´unico computador a fim de garantir as caracter´ısticas ´unicas do ambiente de testes tais como a disponibilidade de banda, condi¸c˜oes de tr´afego de rede, caracter´ısticas e desempenho de hardware/software. Nos clientes de teste, utilizamos um computador quad-core 2.8 GHz CPU com 3GB de RAM e uma conex˜ao de rede Ethernet de 1GB. A Figura 6.21 apresenta um diagrama descrevendo a configura¸c˜ao definida nos testes de desempenho e escalabilidade.