UNIVERSIDADE DO ESTADO DO AMAZONAS - UEA ESCOLA SUPERIOR DE TECNOLOGIA ENGENHARIA DE COMPUTA¸ C ˜ AO ANDR ´ E LUIZ DO CANTO PORTELA OTIMIZA ¸ C ˜ AO DE DESEMPENHO DE SISTEMA GIS DE MONITORAMENTO DE SENSORES MICROPROCESSADOS COM A GOOGLE MAPS API Manaus 2011
79
Embed
OTIMIZAC˘AO DE DESEMPENHO DE SISTEMA~ GIS DE MONITORAMENTO DE …tiagodemelo.info/monografias/2011/tcc-andre-portela.pdf · 2018-08-10 · identi car problemas potenciais atrav es
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERSIDADE DO ESTADO DO AMAZONAS - UEA
ESCOLA SUPERIOR DE TECNOLOGIA
ENGENHARIA DE COMPUTACAO
ANDRE LUIZ DO CANTO PORTELA
OTIMIZACAO DE DESEMPENHO DE SISTEMA
GIS DE MONITORAMENTO DE SENSORES
MICROPROCESSADOS COM A GOOGLE MAPS
API
Manaus
2011
ANDRE LUIZ DO CANTO PORTELA
OTIMIZACAO DE DESEMPENHO DE SISTEMA GIS DE
MONITORAMENTO DE SENSORES MICROPROCESSADOS COM A
GOOGLE MAPS API
Trabalho de Conclusao de Curso apresentado
a banca avaliadora do Curso de Engenharia
de Computacao, da Escola Superior de
Tecnologia, da Universidade do Estado do
Amazonas, como pre-requisito para obtencao
do tıtulo de Engenheiro de Computacao.
Orientador: Prof. M. Sc. Andre Luiz Printes
Manaus 2011
ii
Universidade do Estado do Amazonas - UEA
Escola Superior de Tecnologia - EST
Reitor:
Jose Aldemir de Oliveira
Vice-Reitor:
Marly Guimaraes Fernandes da Costa
Diretor da Escola Superior de Tecnologia:
Mario Augusto Bessa de Figueiredo
Coordenador do Curso de Engenharia de Computacao:
Danielle Gordiano Valente
Coordenador da Disciplina Projeto Final:
Raimundo Correa de Oliveira
Banca Avaliadora composta por: Data da Defesa: 22 / 12 /2011.
Prof. M.Sc. Andre Luiz Printes (Orientador)
Prof. M.Sc. Edgard Luciano Oliveira da Silva
Prof. M.Sc. Tiago Eugenio de Melo
CIP - Catalogacao na Publicacao
P832o PORTELA, Andre
Otimizacao de desempenho de sistema GIS de monitoramento de sensores
microprocessados com a Google Maps API / Andre Portela; [orientado por]
Prof. MSc. Andre Luiz Printes - Manaus: UEA, 2011.
65 p.: il.; 30cm
Inclui Bibliografia
Trabalho de Conclusao de Curso (Graduacao em Engenharia de Computa-
cao). Universidade do Estado do Amazonas, 2011.
CDU: 004
iii
ANDRE LUIZ DO CANTO PORTELA
OTIMIZACAO DE DESEMPENHO DE SISTEMA GIS DE
MONITORAMENTO DE SENSORES MICROPROCESSADOS COM A
GOOGLE MAPS API
Trabalho de Conclusao de Curso apresentado
a banca avaliadora do Curso de Engenharia
de Computacao, da Escola Superior de
Tecnologia, da Universidade do Estado do
Amazonas, como pre-requisito para obtencao
do tıtulo de Engenheiro de Computacao.
Aprovado em: 22 / 12 /2011BANCA EXAMINADORA
Prof. Andre Luiz Printes, Mestre
UNIVERSIDADE DO ESTADO DO AMAZONAS
Prof. Edgard Luciano Oliveira da Silva, Mestre
UNIVERSIDADE DO ESTADO DO AMAZONAS
Prof. Tiago Eugenio de Melo, Mestre
UNIVERSIDADE DO ESTADO DO AMAZONAS
iv
v
Agradecimentos
Ao finalizar este trabalho, apos quase tres
anos, tive o prazer de contar com a amizade
e o incentivo de pessoas que tornaram mais
suave este caminho. A elas, agradeco:
A minha “famılia”, que ficou privada de mi-
nha companhia diversas vezes, mas sempre
me incentivou e apoiou.
Aos meus colegas de faculdade, e professores,
com quem pude dividir alegrias e angustias
durante o tempo em que fiquei na faculdade
e as pessoas que trabalham ou trabalharam
comigo e me apoiaram fortemente a concluir
esta etapa da minha vida profissional.
vi
Resumo
O objetivo deste trabalho e tratar problemas caracterısticos de desempenho atraves de
otimizacao e quantificar as alteracoes destas caracterısticas pos-otimizacao. Uma abor-
dagem estruturada e sistematica e utilizada para caracterizar elementos de desempenho,
identificar problemas potenciais atraves de testes, definir e implementar estrategias de
otimizacao e realizar uma analise comparativa pos-otimizacao em sistema computacional
Mashup chamado de SGT. Sistema este que utiliza a Google Maps API para atribuir
caracterısticas de sistemas de informacao geografica (GIS ) ao monitoramento remoto de
sensores microprocessados, cuja finalidade e aferir parametros eletricos de transformadores
de energia em uma rede de distribuicao.
Palavras Chave: otimizacao de desempenho, testes de desempenho, Mashup, SGT,
Google MAPS API, GIS.
vii
Abstract
This work’s objective is to handle performance problems through tuning and to
quantify changes in the post-optimization characteristics. A structured and systematic
approach is used to characterize performance elements, identify potential problems through
tests, define and implement tuning strategies and make a post-optimization comparative
analysis in a Mashup computational system called SGT. This system uses Google Maps
API to provide geographic information systems (GIS) characteristics to remote monitoring
of microprocessed sensors which have the purpose of assess eletrical parameters of power
As propriedades qualitativas exibidas na tabela 2.1 possuem uma granularidade maior
do que categorias mais abragentes como desempenho. Esse aumento de granularidade e
necessario para permitir a analise de propriedades que podem interferir umas nas outras.
Um exemplo disto e a possibilidade de melhorias na escalabilidade do sistema impactarem
negativamente na sua latencia ou na sua seguranca.
E importante frisar que interferencias entre propriedades dos sistemas e um problema
antigo e tambem um dos maiores desafios do desenvolvimento de software. Projetistas pre-
cisam analisar o custo-benefıcio de propriedades conflitantes com o compromisso de atender
os requisitos dos usuarios. Usualmente este custo-benefıcio e alcancado atraves do controle
de varias propriedades, o que leva a um melhor comportamento geral do software. A figura
Técnicas arquiteturais para selecionar elementos de desempenho 9
2.1 exibe um modelo para representar o conflito de escolha de propriedades qualitativas
em sistemas computacionais.
Figura 2.1: Balanceamento de propriedades qualitativas [BLKW95]
2.2 Tecnicas arquiteturais para selecionar elementos
de desempenho
Como dito anteriormente, boas praticas em disciplinas de engenharia sao extremamente
importantes para consolidar as metodologias envolvidas em seus projetos. Reconhecendo
esta importancia, em 1995 um grupo de planejamento arquitetural de software formado por
membros do Institute of Electrical and Electronic Engineers (IEEE ) comecou a trabalhar
em um conjunto de boas praticas que posteriormente foi chamado de padrao IEEE-STD-
1471-20001, tambem conhecido como ”Recommended Practice for Architectural Description
of Software-Intensive Systems”.
O objetivo do IEEE-1471 foi definir a direcao para a incorporacao de consideracoes
arquiteturais de software aos padroes do instituto, estabelecer um framework conceitual e
vocabulario proprio para consideracoes de arquitetura em sistemas computacionais, iden-
tificar e promover praticas arquiteturais promissoras e permitir a evolucao destas praticas
1A partir de agora referenciado apenas como IEEE-1471.
Técnicas arquiteturais para selecionar elementos de desempenho 10
acompanhando a evolucao das tecnologias relevantes.
O IEEE-1471 e um tipo de padrao IEEE conhecido como pratica ”recomendada” pelo
instituto e uma dada organizacao tem a completa responsabilidade de decidir quando e
como empregar as praticas contidas no padrao. Ele se aplica aos interesses arquiteturais de
projetos de software e considera que descricoes arquitetonicas podem estar em conformidade
com estas praticas. Porem, sistemas, processos, organizacoes, metodos e ferramentas nao
podem pois estas praticas foram construıdas em torno de conhecimento empırico utilizando
termos como ”deve”, ”deveria”e ”pode” [Soc00].
Uma tecnica largamente utilizada por arquitetos de software e particionar os requisitos
do software em visoes ou views2 separadas, porem co-relacionadas de modo que cada view
descreve um aspecto separado da arquitetura e todas as visoes juntas descrevem o sistema
inteiro. Uma view e uma representacao parcial da estrutura do sistema que analisa os
aspectos relevantes aos interesses de determinados stakeholders [RW05].
O IEEE criou um padrao a partir desta tecnica propondo o conceito de ”ponto de
vista”ou viewpoint. Viewpoints sao colecoes de modelos, princıpios e convencoes para cons-
trucao de uma visao. Em outras palavras, sao um framework para capturar conhecimento
arquitetonico reutilizavel.
Porem, a criacao de views e viewpoints precisa ser guiada por perspectivas mais
amplas para que a soma de todas as views seja consistente. E exatamente por isso que
o [Soc00] define o conceito de perspectivas arquiteturais. Estas perspectivas sao colecoes
de atividades e taticas utilizadas para garantir que o sistema exibe um conjunto particular
de propriedades qualitativas e sao aplicadas nas views considerando-se limitacoes de
tempo e recursos para analisar e modificar uma dada arquitetura para que esta atenda a
propriedades definidas pelas views como mostra figura 2.2.
2Ao longo deste trabalho, esta terminologia sera utilizada apenas para se adequar a termino-logia encontrada nas obras de referencia.
Técnicas arquiteturais para selecionar elementos de desempenho 11
Figura 2.2: Aplicando perspectivas as views [RW05]
2.2.1 Descricao arquitetural
Uma descricao arquitetural e uma colecao de artefatos que documentam uma ar-
quitetura de uma forma independente de notacao e tem como objetivo definir termos e
conceitos para as consideracoes arquiteturais, servir de base para a evolucao de um aspecto
arquitetural onde exista pouco terminologia comum e prover os meios para consideracoes
arquitetonicas no contexto dos stakeholders do sistema, ciclo de vida e usos das descricoes
arquiteturais. A figura 2.3 a seguir exibe uma representacao deste framework conceitual.
Técnicas arquiteturais para selecionar elementos de desempenho 12
Figura 2.3: Framework Conceitual IEEE1471 [Soc00]
A partir deste modelo, podemos identificar alguns elementos-chave das descricoes
arquiteturais que sao os stakeholders, as views e os viewpoints que se relacionam direta e
indiretamente com a arquitetura de um dado sistema.
2.2.2 Views de desempenho
A utilizacao de views tem como premissa a consideracao de alguns pontos tais como
quem sao os stakeholders a quem a view se destina, quanto de entendimento tecnico estes
stakeholders possuem, quais sao os interesses dos stakeholders que a view pretende tratar,
entre outras [RW05].
Técnicas arquiteturais para selecionar elementos de desempenho 13
As views que tratam sobre desempenho, focam exclusivamente nas propriedades qua-
litativas correspondentes que sao latencia, vazao, eficiencia, escalabilidade, entre outras.
Sua meta e possibilitar a previsibilidade da operacao do sistema de acordo com o perfil
de desempenho tracado para o sistema e tratar o aumento dos volumes de processamento
de dados pelo mesmo. Estas views se aplicam a quaisquer sistemas complexos, com pro-
jecoes de significativas expansoes futuras, com requisitos de desempenho ambiciosos ou
simplesmente pouco claros e ate mesmo inexistentes [RW05].
2.2.3 Perspectivas arquiteturais
Atividades frequentemente envolvidas na criacao de perspectivas arquiteturais e con-
solidacao das views sao a captura dos requisitos de desempenho do sistema, criacao de
modelos de desempenho, conducao de testes praticos, avaliacao dos resultados contra os
requisitos levantados e retrabalho na arquitetura para atender estes requisitos (tambem
conhecido como otimizacao do desempenho do sistema) [Fai10].
Estas atividades podem ser encadeadas de acordo com a metodologia do ciclo fechado
de iteracao (Closed Loop cycle) como mostra a figura 2.4. O ciclo fechado de iteracao
pressupoe a definicao clara dos requisitos de desempenho e inicia-se com a coleta dos dados
de desempenho do sistema. Em seguida, esses dados sao analisados para que problemas
possam ser identificados. Baseando-se nos problemas identificados sao criadas estrategias e
implementacoes alternativas para tratar estas questoes. Por fim, os elementos selecionados
sao testados novamente para que se possa decidir por iniciar um novo ciclo ou encerrar as
iteracoes de otimizacao.
Seleção de elementos de desempenho 14
Figura 2.4: Ciclo fechado de iteracao [Vec08]
2.2.4 Armadilhas arquiteturais
Causas comuns de insucesso no emprego destas tecnicas sao algumas armadilhas no
momento de empregar perspectivas para a criacao e definicao de views. Para evitar tais
armadilhas ha a necessidade de consideracoes cuidadosas para que as perspectivas tratem
de um conjunto pequeno, fechado e intimamente relacionado de interesses em propriedades
qualitativas, entender que frequentemente haverao conflitos entre solucoes sugeridas por
diferentes perspectivas e e necessario balancea-las de acordo com uma priorizacao das
propriedades mais importantes para o sistema (com a ajuda dos stakeholders) [RW05].
2.3 Selecao de elementos de desempenho
Idealmente, todo software de aplicacao crıtica deveria possuir um conjunto completo,
consistente e factıvel de requisitos de desempenho e escalabilidade, porem, na pratica estes
Seleção de elementos de desempenho 15
requisitos sao muitas vezes tratados com uma prioridade menor do que os requisitos fun-
cionais do software, pois estes sao definidos em termos de negocio significativos aos seus
usuarios. Requisitos como ser capaz de lidar com a gerencia de ate 3000 transformadores
em uma rede de distribuicao de energia sao uteis pois definem as necessidades reais de
stakeholders, porem precisam ser quebrados em objetivos mais especıficos e quantitativos
para que em cima dos quais seja possıvel realizar testes e analises [RW05].
2.3.1 Identificacao e priorizacao de stakeholders
Na ausencia da especificacao de requisitos ”extra-funcionais” detalhados para questoes
de desempenho no sistema, serao identificados stakeholders principais para estas proprie-
dades, isto auxiliara na determinacao e priorizacao de interesses na perspectiva de desem-
penho.
Tomemos a figura 2.5 como exemplo:
Figura 2.5: Elementos do SGT
De forma imediata podemos identificar os operadores do sistema que o acessarao atra-
Seleção de elementos de desempenho 16
ves de brownsers como importantes stakeholders do mesmo, os operadores precisam ter
condicoes de opera-lo de forma adequada mesmo nas situacoes de grande volume de moni-
toramento para que o sistema possua valor agregado.
Por conta disto, e factıvel definir os operadores do sistema como stakeholders que pos-
suem interesse nas propriedades de desempenho do sistema. Outros possıveis stakeholders
seriam os analistas de dados que podem agregar os dados gerados pelo sistema de monito-
racao para inferir informacoes de negocios de grande valor para a organizacao como tempo
de vida util medio, plano de capacidade, necessidade de manutencoes preventivas, etc.
Ao identificar dois possıveis stakeholders, precisamos definir como propriedades de de-
sempenho impactam nos interesses de ambos para que seja possıvel priorizar algumas pers-
pectivas.
Analistas de dados podem estar mais interessados em propriedades de desempenho
do banco de dados para que possam realizar suas analises de forma a nao comprometer
o funcionamento geral do sistema e ainda assim atender a janelas de tempo necessarias
para que suas analises sejam valiosas para a organizacao. Operadores do sistema, por
outro lado, estao mais interessados no desempenho do front-end, pois o utilizam direta e
frequentemente para administrar o sistema, esta administracao dos recursos monitorados
e crıtica para a operacao do sistema, cujo principal objetivo e fornecer informacoes em
tempo habil para a tomada de decisao a cerca dos ativos monitorados [MFB+07].
De posse destas informacoes e possıvel priorizar os esforcos arquiteturais de desempenho
para tratar as questoes mais crıticas e/ou importantes do sistema, limitando-as por tempo
e recursos disponıveis para tal. Como a operacao direta do sistema para detectar eventuais
ameacas ao patrimonio da organizacao, a princıpio, e mais crıtica do que a extracao de
informacoes gerenciais que serao utilizados no medio e longo prazo, e razoavel concentrar
os esforcos arquiteturais de desempenho primeiramente nos interesses dos operadores do
sistema [MFB+07].
Sendo assim, apesar de existirem diversas questoes passıveis de preocupacoes de oti-
mizacao, como o desempenho do software executado em cada sensor microprocessado, a
comunicacao dos sensores com a aplicacao de sensoriamento, a interacao desta aplicacao
com o banco de dados e a operacao do proprio banco de dados, os esforcos de desempe-
nho neste trabalho se restringirao a experiencia de utilizacao do sistema por parte de seus
Seleção de elementos de desempenho 17
operadores e administradores.
2.3.2 Particionamento de interesses dos stakeholders seleciona-
dos
Novamente, mesmo com esta restricao, ainda existe uma gama enorme de consideracoes
possıveis e novamente e necessario quebra-las em partes menores e prioriza-las para que seja
possıvel trata-las. Em resumo, pode-se analisar todos os funcionais da aplicacao web do
sistema e particiona-los em grupos menores com objetivos e propriedades de desempenho
diferentes e prioriza-los [MFB+07].
Os requisitos funcionais desta aplicacao podem ser basicamente divididos em 3 grandes
grupos:
1. A representacao visual dos dados monitorados que utiliza mapas para apresentar a
distribuicao geografica destes dados;
2. A representacao tabular dos mesmos dados;
3. A administracao coletiva e individual de unidades remotas;
Representacao visual de dados monitorados
Este grupo de requisitos trata da exibicao grafica de dados no mapa e da interacao
dos operadores com o mesmo. Tem como caracterıstica a criticidade em desempenho de
operacao, pois pode potencialmente lidar com milhares de unidades remotas em uma mesma
tela e isto e um risco a boa operacao do sistema.
Representacao tabular de dados monitorados
Este grupo de requisitos trata da exibicao textual dos dados em tabelas e interacao
dos operadores com o mesmo. Tambem e crıtica para a operacao do sistema, pois tambem
precisa disponibilizar informacao para tomada de decisao em tempo habil. Difere do grupo
anterior pela natureza das aplicacoes web que ja possuem metodos bem consolidados de
tratar questoes de desempenho de tabelas promovendo por exemplo o uso de paginacao
dos dados.
Seleção de elementos de desempenho 18
Administracao coletiva e individual de unidades remotas
Este grupo de requisitos trata da insercao de comandos coletivos ou individuais das
unidades remotas, bem como a manutencao de seu cadastro. Caracteriza-se pelo envio de
comandos dos operadores do sistema as unidades remotas e manutencao cadastral das mes-
mas. Sua criticidade de desempenho e diretamente proporcional a quantidade de usuarios
simultaneos do sistema que irao gerar stress nos seus recursos funcionais.
2.3.3 Priorizacao de requisitos funcionais
Para priorizar estes grupos de requisitos pode-se levar em consideracao o ambiente no
qual o sistema esta inserido, a quantidade de usuarios simultaneos tende a ser baixa com
picos estimados em 25 usuarios (informacao proveniente da empresa), portanto, a estima-
tiva de carga para o stress das funcionalidades de administracao das unidades remotas e
baixa o que justifica sua baixa priorizacao frente aos demais grupos funcionais.
Por outro lado, a estimativa de carga de dados para representacao visual e alta. De
acordo com a tabela 1.1, em 2007 foram instalados 105.173 transformadores na rede de
distribuicao de energia eletrica apenas para a regiao norte. Portanto, e possıvel tratar com
prioridade os dois primeiros grupos de requisitos funcionais (representacao visual e tabular
dos dados monitorados). Sendo que o primeiro, por exibir maior valor funcional e por
apresentar potencial tecnico maior de problemas de desempenho relacionados sera o grupo
funcional escolhido como alvo das analises propostas neste trabalho.
2.3.4 Consolidacao de requisitos extra-funcionais
Para os requisitos funcionais selecionados, existem requisitos extra-funcionais direta-
mente relacionados com as propriedades qualitativas de interesse dos stakeholders. Requi-
sitos extremamente comuns na literatura e proporcionalmente importantes como a “regra
dos 8 segundos” e a velocidade de interacao na operacao do sistema podem ser tomados
como pontos de partida para avaliar propriedades qualitativas de interesse [ZR99].
A regra dos 8 segundos diz que a maioria dos usuarios espera no maximo 8 segundos para
um determinado web site carregar [Sav00], a partir deste espaco de tempo a experiencia dos
Seleção de elementos de desempenho 19
usuarios se torna ruim o suficiente para que eles pensem em tomar alguma outra decisao
como ilustra a figura 2.6. Obviamente este tempo e influenciado por um numero muito
grande de variaveis tais como tamanho da pagina a ser carregada, potenciais gargalos de
desempenho no servidor web, velocidade da conexao nos dois pontos (brownser e servidor
web) e etc, porem como estas variaveis estao intimamente relacionadas, a melhoria de uma
delas causa uma melhoria no aspecto geral desta questao.
Figura 2.6: Experiencia de utilizacao do web-site [Sav00]
A figura 2.7 mostra a porcentagem de usuarios que tendem a abandonar a utilizacao
de servicos de web-site baseando-se no tempo de resposta.
Seleção de elementos de desempenho 20
Figura 2.7: Porcentagem de usuarios que abandonam web-sites [Sav00]
A tabela 2.2 exibe estimativa de perdas financeiras anuais devido a violacao da regra
dos 8 segundos.
Tabela 2.2: Perdas anuais devido a violacao da regra dos 8 segundos [Sub06]Industria Perdas em vendas em milhoes de dolares
Seguros $40Turismo e viagens $34
Imprensa $14Alimentos $9
Financas Pessoais $5Musica $4
Recibos de escritorio $3Textil $3
A velocidade de interacao do sistema pode ser definida como a quao rapido o sistema
responde a interacoes realizadas por seus usuarios e e representada na tabela 2.3.
Seleção de elementos de desempenho 21
Tabela 2.3: Ponto de vista dos usuarios no tempo de resposta [Sub06]Tempo de resposta Ponto de vista do usuario
< 0.1 segundo Sensacao de reacao instantanea do sistema< 1.0 segundo Sensacao pequena de atraso, porem o
usuario continua focado no web site< 10 segundos Tempo maximo que o usuario fica focado
no web site, sua atencao ja esta na zona de distracao> 10 segundos Grande probabilidade do usuario ser distraıdo
do atual web site e perder interesse
Para o sistema, a zona de distracao significa que o usuario pode potencialmente consi-
derar outras alternativas funcionais da aplicacao web na tentativa de atingir suas intencoes.
Em outras palavras, se os mesmos dados podem ser exibidos nas formas graficas e textual e
uma delas apresentar elevado tempo de exibicao, e grande a probabilidade de que o usuario
tente utilizar a fonte de dados alternativa.
No escopo deste trabalho, serao considerados os seguintes requisitos de desempenho:
• Regra dos 8 segundos (as telas que exibem dados no mapa deverao carregar em tempo
menor ou igual a 8 segundos);
• Velocidade de interacao (o usuario deve possuir no maximo uma pequena sensacao
de atraso ao interagir com o sistema mesmo durante a monitoracao de 3000 unidades
remotas);
Estes itens sao diretamente afetados pelas propriedades de latencia, vazao, eficiencia
e escalabilidade da aplicacao web do sistema. A priorizacao destes elementos se deu
com base na criticidade de interesses de desempenho de potenciais stakeholders do sistema.
Capıtulo 3
Testes de desempenho
Enquanto a internet oferece conectividade em dispositivos, ela nao oferece controle sobre
o ambiente dos dispositivos clientes ou sobre todas as etapas envolvidas na comunicacao
entre dispositivos clientes e servidores. Diante deste cenario, para realizar testes efetivos
em aplicacoes web e necessario conhecer os sistemas e tecnologias a serem testados de forma
a reduzir o numero de variaveis ambientais tornando o problema menor e tratavel [Ngu01].
Um sistema puramente web pode possuir qualquer numero de servidores fısicos, cada
um fornecendo um ou mais tipos de servicos tais como servicos e paginas web, servidores
de aplicacao, banco de dados e etc. E possıvel colocar em perspectiva alguns elementos
deste tipo de sistema tal qual exibe a figura 3.1.
23
Figura 3.1: Sistemas cliente-servidor [HQN03]
Esta forma de tratar aplicacoes cliente-servidor e valida para muitos sistemas presentes
na internet, porem, nao para todos. A figura 3.2, por exemplo, mostra de forma um pouco
mais detalhada uma estrutura tıpica de aplicacoes web.
24
Figura 3.2: Arquitetura tıpica de sistemas web [HQN03]
A figura 3.2 demonstra que sistemas web sao essencialmente distribuıdos por natureza,
porem a arquitetura deste tipo de sistema pode ficar ainda mais complexa, como e o caso
do sistema analisado. O sistema analisado neste trabalho incorpora caracterısticas comuns
de sistemas web e as combina com caracterısticas de monitoramento remoto de sensores
como demonstra a figura 3.3 a seguir.
Figura 3.3: Elementos do SGT na internet
Neste cenario o numero de variaveis a ser considerado e muito alto e as simplificacoes
certas sao necessarias para tornar os testes executaveis, controlados, porem nao irreais.
Definição 25
3.1 Definicao
Testes de desempenho sao os tipos de teste com o objetivo de determinar a capacidade
de resposta, vazao, confiabilidade e escalabilidade de um sistema sob determinada carga de
trabalho. Sao testes frequentemente utilizados para avaliar a maturidade de um software
a ser lancado em producao em termos de conformidade com criterios de desempenho,
comparar caracterısticas entre multiplos sistemas ou configuracoes (benchmarking), achar
fontes de problemas (gargalos de desempenho) e suportar o processo de otimizacao de
desempenho [MFB+07].
3.2 Metas
Os testes de desempenho realizados neste trabalho possuem as metas de identificacao de
problemas de desempenho associados aos objetivos tracados no capıtulo 2 que e caracterizar
elementos de desempenho atrelados ao ponto de vista dos operadores do sistema, isto
e, usuarios que utilizarao sua interface web para realizar o monitoramento das unidades
remotas.
Para o primeiro requisito, regra dos 8 segundos definida na secao 2.3.4, o sistema deve
possuir um tempo de resposta as requisicoes para a pagina grafica de monitoramento de
unidades remotas inferior a 8 segundos para o acesso concorrente de 25 usuarios, dada uma
carga de ate 3000 unidades remotas cadastradas no banco de dados.
Para o segundo requisito (velocidade de interacao), o sistema deve ser capaz de res-
ponder a interacoes do usuario com a pagina grafica de monitoracao (a saber, cliques de
mouse em marcadores especıficos do mapa) em um tempo maximo de ate 1 segundo para
uma carga de ate 3000 unidades remotas exibidas na tela.
3.3 Metodologia
A figura 3.3 mostra que, para o sistema analisado, a aplicacao web e a aplicacao de
sensoriamento possuem baixo acoplamento atraves do banco de dados. A aplicacao de
sensoriamento se comunica com as unidades remotas recolhendo os dados das mesmas e
Metodologia 26
inserindo-os no banco de dados e conferindo eventuais agendamentos de comandos realiza-
dos pela aplicacao web. A aplicacao web, por sua vez, consome estes dados e realiza estes
agendamentos inserindo informacoes especıficas no banco.
Em funcionamento, o sistema estabelece apenas uma relacao indireta entre a aplicacao
web, a aplicacao de sensoriamento e as unidades remotas. Por tanto, esta fora do escopo
deste trabalho analisar as questoes de desempenho relacionadas a aplicacao de sensoria-
mento e as unidades remotas.
O impacto das atividades das mesmas possui impacto funcional maior do que o de
desempenho, isto nao quer dizer que o desempenho da aplicacao web nao seja afetado.
Grandes volumes de unidades remotas significam grandes volumes de marcadores a serem
monitorados nos mapas e eventos associados a estas unidades remotas sao igualmente
refletidos nos mapas. Porem, para fins de testes, estas situacoes podem ser emuladas
realizando carga previa do banco de dados compartilhado.
Os requisitos funcionais analisados, nao requerem respostas das unidades remotas a
comandos agendados pela aplicacao web. A real dependencia e que unidades remotas
estejam cadastradas e possuam dados de localizacao e de parametros eletricos validos. Isto
torna simples a criacao da massa de dados, uma vez que e necessario apenas criar entidades
que representam unidades remotas hipoteticas e atribuir valores validos ao seus atributos
de medicao.
A metodologia adotada nos testes de desempenho deste trabalho consistiu basicamente
em:
• Identificar o ambiente de testes;
• Modelar o uso estimado da aplicacao;
• Criar casos de teste especıficos;
• Selecionar ferramentario de teste;
• Criar massa de testes;
Metodologia 27
3.3.1 Identificando o ambiente de teste
O servidor de teste e um laptop HP-Pavilion dv4-1125br com o Ubuntu 11.10 64bits
instalado. Este servidor e host do banco de dados Mysql 5.1, do servidor web Apache
2.2.20 que hospeda a aplicacao web do sistema. A aplicacao e executada pelo interpretador
python 2.7.2 e o navegador utilizado e o firefox versao 8.0.
O servidor de testes possui uma conexao com internet de 10 Mbps e os testes devem
ser executados fora dos horarios de pico de utilizacao do provedor de internet (apos as
22h e antes das 8h) de forma a minimizar possıveis impactos decorrentes de variacao da
velocidade do link de internet.
3.3.2 Casos de teste
Os casos de testes da aplicacao sao simples pela caracterıstica das funcionalidades ana-
lisadas. A partir dos requisitos levantados, foram desenvolvidos dois casos de testes:
1. Depois de logado, o usuario de testes deve clicar em um link na tela inicial da aplicacao
para exibir a tela de monitoramento grafico. O tempo total desta requisicao sera
medido utilizando diferentes cenarios de teste;
2. Depois de logado e na tela grafica de monitoramento, o usuario de testes deve clicar
em um marcador para que seja aberta uma janela de informacoes caracterıstica da
Google Maps API. O tempo total da execucao deste codigo sera medido utilizando
diferentes cenarios de teste;
3.3.3 Cenarios de teste
Os cenarios de teste desenvolvidos para a execucao dos testes sao igualmente simples e
apenas requerem a criacao de massas de dados de diferentes volumetrias, foram criados 5
cenarios de testes.
As volumetrias adotadas foram (em registros de unidades remotas e seus respectivos
atributos eletricos): 10, 50, 100, 1000 e 3000.
Metodologia 28
Os cenarios especıficos dos testes de carga possuem a caracterıstica de serem executados
concorrentemente por 25 usuarios de teste diferentes (threads criadas pelo JMeter) para
refletir as condicoes de concorrencias que serao encontradas em producao.
3.3.4 Ferramentas de teste
Foram selecionadas tres ferramentas especıficas para os testes:
• JMeter;
• Programa de criacao de massa de dados escrito em C++;
• Codigo JavaScript de instrumentacao inserido diretamento no codigo da aplicacao;
JMeter
O JMeter e uma ferramenta consagrada para testes de desempenho e carga em apli-
cacoes web, soap, banco de dados, entre outras. Foi escolhido como ferramenta devido a
sua flexibilidade de configuracao, suporte a multithreading para emular acessos concorren-
tes a aplicacao. E permitir gravacao das requisicoes HTTP realizadas a aplicacao web do
sistema. A figura 3.4 exibe a interface da ferramenta.
Metodologia 29
Figura 3.4: Interface da Ferramenta JMeter
Programa de criacao de massa de dados
Este programa, escrito com a unica finalidade de criar registros no banco de dados que
representam unidades remotas monitoradas, pode ser parametrizado com a volumetria de
unidades remotas a ser inserida no banco de dados.
Instrumentacao JavaScript
Simples codigo JavaScript inserido diretamente no codigo da aplicacao para fins de
teste. Apresenta-se na forma de uma funcao wrapper que encapsula a funcionalidade do
codigo a ser testado e mede o seu tempo de execucao. O codigo 3.3.1 a seguir exibe um
exemplo deste codigo de instrumentacao que possui precisao maxima de 1 milisegundo.
Resultados Obtidos 30
1 function instrumentingWrap() {2 var start = new Date().getMilliseconds();3 // codigo especıfico a ser medido4 var stop = new Date().getMilliseconds();5 var executionTime = stop - start;6 alert("funcaoMedida() executou em " + executionTime + " milisegundos");7 }
Codigo 3.3.1: Exemplo de codigo de instrumentacao JavaScript
3.3.5 Testes de carga
Os testes de carga foram executados em baterias de 10 testes para cada cenario de
teste e o resultado das execucoes destes testes foi condensado em uma media. Em outras
palavras, tomando-se como exemplo o caso de teste 1: o mesmo foi executado 10 vezes
para o cenario de 100 unidades remotas no banco, em seguida foi extraıda a media dos
resultados destes testes.
3.3.6 Testes de desempenho
Os testes de desempenho tambem foram executados em baterias de 10 testes para cada
cenario de teste e o resultado foi condensado em uma media. Em exemplo: o codigo de
instrumentacao para a exibicao da janela de informacao foi executado 10 para o cenario de
500 unidades remotas no banco, em seguida esses resultados foram sumarizados em uma
media.
3.4 Resultados Obtidos
A tabela 3.1 condensa os resultados obtidos, apos a realizacao da primeira bateria de
testes de carga (caso de teste 1).
Tabela 3.1: Primeira bateria de testes de cargaQtd. marcadores 10 50 100 1000 3000Tempo de carga 2.589s 10.741s 26.628s 50.234s 130.401s
Ja a tabela 3.2 sumariza os resultados obtidos apos a execucao da primeira bateria de
testes de desempenho (caso de teste 2).
Resultados Obtidos 31
Tabela 3.2: Primeira bateria de testes de desempenhoQtd. marcadores 10 50 100 1000 3000
Tempo de execucao 0.020s 0.081s 0.628s 1.723s 2.613s
As figuras 3.5 e 3.6 exibem os graficos destes resultados.
Figura 3.5: Resultados da primeira bateria de teste de carga
Problemas Potenciais 32
Figura 3.6: Resultados da primeira bateria de testes de desempenho
3.5 Problemas Potenciais
A partir dos resultados obtidos, e possıvel identificar dois problemas de desempenho. O
primeiro problema esta na capacidade de carga do sistema, seu tempo de resposta maximo
ficou 1630% acima do limite esperado (8 segundos).
O segundo problema esta no tempo de resposta de interacao do sistema que apresenta
um valor 261.3% acima do limite maximo esperado (1 segundo).
Estes dados caracterizam problemas de desempenho no sistema significando que o sis-
tema nao atende as propriedades qualitativas dos requisitos descritos no capıtulo 2 (secao
2.3.4).
Varias hipoteses podem ser levantadas a partir destes resultados:
• Baixo desempenho dos algoritmos presentes na aplicacao web;
• Pouca otimizacao do banco de dados (pouco desempenho na execucao de queries);
• Conexao de dados lenta com a Google Maps API ;
• Alto trafego de dados com os servidores Google;
Problemas Potenciais 33
Estas hipoteses servirao de insumos para elaboracao de estrategias de otimizacao e os
resultados obtidos a partir da implementacao destas estrategias eliminarao as hipoteses
incorretas.
A breve investigacao destas hipoteses ocorrera na forma de analise dos resultados obti-
dos apos a otimizacao implementada, sendo que os resultados obtidos determinarao se as
hipoteses apresentam problemas solucionados pelas implementacoes.
Capıtulo 4
Otimizacao de desempenho
4.1 Definicao de metas
As metas de otimizacao para a aplicacao web do sistema sao melhorar a experiencia de
usuario diminuindo o tempo de carregamento para a exibicao dos mapas e aumentando a
velocidade de interacao do usuario com os mesmos.
Estas metas, apesar de genericas e abrangentes, fornecem um bom ponto de partida
para o inıcio das atividades de otimizacao. E necessario, porem, que as mesmas sejam bem
definidas em termos quantitativos para que sejam mensuraveis.
Uma armadilha comum em atividades de otimizacao e a falta de definicao quantificavel
de objetivos de melhoria, o que torna difıceis as posteriores analises e avaliacoes de resul-
tados obtidos. Em geral, a falta de conformidade clara com os objetivos das atividades e
uma causa comum ao insucesso das iniciativas de melhoria de desempenho.
Para este trabalho serao utilizadas metas que sao conhecidas como metas de qualidade
de servico (QoS - Quality of Service) e que estao intimamente ligadas com a capacidade
de resposta do sistema (responsiveness) [RW05] e sao descritas a seguir.
4.1.1 Diminuicao do tempo de carregamento dos mapas
O tempo de carregamento de paginas web pode ter inumeras variaveis, tais como desem-
penho do sistema operacional e do hardware do cliente da requisicao, do modem utilizado,
da rede pela qual a requisicao trafega, de possıveis roteadores, de backbones na internet,
do hardware, sistema operacional, software e sistema de arquivos do servidor e inclusive
do conteudo do banco de dados [Kil98].
A figura 4.1 detalha as etapas seguidas pela requisicao de uma pagina web a uma
Definição de metas 35
aplicacao web ate a sua resposta efetiva ao browser que realizou a solicitacao.
Figura 4.1: Requisicao HTTP detalhada [Kil98]
Como e possıvel observar, o numero de variaveis envolvida e alto. Para que a meta da
diminuicao do tempo de carregamento dos mapas seja definida de forma objetiva, pode-se
utilizar uma abordagem cientıfica para reduzir ao maximo o numero de variaveis ambientais
e substituı-las por constantes que posteriormente servirao para possibilitar a reproducibi-
lidade dos resultados e a comparacao com resultados anteriores e posteriores [Vec08].
Portanto, define-se como meta de diminuicao do tempo de carregamento dos mapas o
carregamento de 3000 marcadores no mapa em um tempo inferior a 8 segundos em um
ambiente identico ao ambiente onde os testes iniciais foram conduzidos.
4.1.2 Aumento da velocidade de interacao com os mapas
O aumento da velocidade de interacao com os mapas tem, por sua vez, reduzida intera-
cao com os outros componentes do sistema - seus elementos ficam em grande parte contidos
no browser cliente na forma de codigo JavaScript e elementos DOM - e elevada dependencia
em um servico externo (Google Maps API ). Estas sao condicoes verdadeiramente inospitas
para a quantificacao de metas de otimizacao pois suas validacoes dependerao de instrumen-
tacao manual da operacao do sistema (codigo JavaScript medindo tempos de resposta), o
que, segundo o princıpio da incerteza de Heisenberg [Hut03], produzira perturbacoes no
sistema observado.
Definição de estratégias 36
Contudo, para as intencoes desta meta, estas perturbacoes serao desconsideradas, uma
vez que aproximacoes de ordem de grandeza menor do que as medicoes pretendidas sao
consideradas suficientemente validas para analise.
Finalmente, define-se como meta de aumento da velocidade de interacao com os mapas
a medida indireta de sua velocidade atraves do tempo de resposta de interacao com o web
site, dado que o mesmo nao devera ser maior do que 1 segundo para uma carga de 3000
marcadores no mapa em um ambiente de testes identico ao dos testes iniciais.
4.2 Definicao de estrategias
Para o atingimento destas metas de desempenho e necessario realizar retrabalhos arqui-
teturais no sistema de modo que o comportamento seja adequado. Antes que o retrabalho
seja realizado, ele precisa ser planejado e projetado para tal, utilizando os mesmos compro-
missos de propriedades qualitativas explanados no capıtulo 2 e tambem os compromissos
funcionais utilizados na construcao do sistema. Colocado de uma outra forma, a otimizacao
de desempenho nao deve causar prejuızos funcionais e nem ”extra-funcionais” [RW05].
As estrategias de otimizacao devem ser criadas a partir de hipoteses levantadas na
analise de dados inicial dos testes do sistema e avaliadas a partir de seus potenciais impactos
nas propriedades qualitativas do sistema. Na avaliacao das estrategias, deve ser levado
em consideracao os compromissos com algumas propriedades qualitativas do sistema que
podem ser afetadas como usabilidade e mantenabilidade [Fai10].
Uma heurıstica antiga da engenharia de software [RW05] diz que sistemas computacio-
nais tendem a passar 80% do seu tempo executando 20% do seu codigo. A implicacao em
desempenho e que as estrategias de otimizacao devem focar nestes 20% do sistema.
4.2.1 Utilizar XHTML simples
Uma das hipoteses de problemas potenciais levantadas na secao 3.5 e que o volume de
codigo JavaScript utilizado para plotar os marcadores seja excessivamente grande, o que
onera o tempo de carregamento da pagina. Este panorama pode ser evitado ao remover
grande parte do codigo JavaScript da pagina, deixando apenas marcacoes HTML expostas
ao navegador e pouco codigo JavaScript com o proposito apenas de realizar navegacao.
Existe uma API da famılia Google Maps API chamada de Static Maps API que nao
Definição de estratégias 37
utiliza JavaScript nem qualquer carregamento dinamico da pagina. Esta API fornece um
webservice que renderiza o mapa com base nos parametros de URL enviados por meio
de uma solicitacao HTTP padrao e o retorna como uma imagem passıvel de exibicao na
pagina web [Goo]. O codigo 4.2.1 exemplifica uma chamada a esta API :
1 <html>2 <header>3 <title>Hello World Google Static Maps</title>4 </header>5 <body>6 <img src="http://maps.google.com/maps/api/staticmap?center=34.420831,7 -119.698190&zoom=11&markers=34.417390,-119.805830|34.419938,-119.6780208 &size=500x300&sensor=false"/>9 </body>
10 </html>
Codigo 4.2.1: Chamada da Google Static Maps API em codigo XHTML [Goo]
Esta estrategia diminui bastante a comunicacao com o servidores da Google pois os
resultados das requisicoes sao apenas imagens, por outro lado, a complexidade de interacao
do usuario anteriormente tratada pela API JavaScript da Google e transferida para o
sistema, o que aumenta custos de manutencoes evolutivas e corretivas.
A utilizacao desta API tambem diminui os limites de escalabilidade do sistema, uma
vez que sua polıtica de limites de uso restringe um valor diario de 1000 solicitacoes que
retornem imagens diferentes para um mesmo utilizador. Outro limite e que as URLs da
Google Static Maps API sao restritos a 2048 caracteres, o que pode limitar a marcacao de
uma quantidade massiva de marcadores [Goo].
Outra desvantagem desta abordagem e a perda de funcionalidades RIA (Rich Internet
Applications). Funcionalidades antes comuns como o arrastar e soltar em um mapa para
movimentar a area monitorada nao serao mais possıveis e sera responsabilidade do sistema
prover funcionalidades que as substituam.
Os potenciais ganhos em desempenho proporcionados por esta estrategia afetam outras
propriedades qualitativas do sistema, tais como mantenabilidade, escalabilidade e funcio-
nabilidade. Portanto, esta estrategia nao sera implementada.
4.2.2 Utilizar cluster de marcadores
Esta abordagem e constituıda no agrupamento de marcadores no mapa, existem diver-
sas tecnicas e algoritmos para realizar este agrupamento. O agrupamento e geralmente
Definição de estratégias 38
realizado para aumentar o desempenho do codigo JavaScript que controla e plota marca-
dores no mapa segundo criterios como por exemplo, um limiar de quantidade excessiva de
marcadores no mapa. Esta abordagem possui vantagens como melhorar significativamente
o desempenho da interacao com o mapa, facilitar sua leitura e interpretacao reduzindo a
quantidade de elementos visıveis [Sve10].
O codigo 4.2.2 exibe um exemplo adaptado de [Sve10] sobre como usar cluster de
marcadores utilizando a Google Maps API, este exemplo foi utilizado como ponto de partida
para a implementacao de clusterizacao.
1 window.onload = function() {2
3 var options = {4 zoom: 3,5 center: new google.maps.LatLng(37.09, -95.71),6 mapTypeId: google.maps.MapTypeId.ROADMAP7 };8 var map = new google.maps.Map(document.getElementById(’map’), options);9
10 var markers = [];11
12 for (var i = 0; i < 1000; i++) {13
14 var lat = getRandomLat();15 var lng = getRandomLng();16 var latlng = new google.maps.LatLng(lat, lng);17
18 var marker = new google.maps.Marker({position: latlng});19
20 markers.push(marker);21
22 var markerclusterer = new MarkerClusterer(map, markers);
Codigo 4.2.2: Exemplo JavaScript da utilizacao de marcadores [Sve10]
As figuras 4.2 e 4.3 ilustram como clusters agrupam grupos de marcadores.
Definição de estratégias 39
Figura 4.2: Marcadores proximos renderizados individualmente [LM]
Figura 4.3: Marcadores proximos renderizados em cluster [LM]
4.2.3 Limitar o carregamento de marcadores a area visıvel domapa
A limitacao do carregamento de marcadores a area visıvel do mapa tem o potencial de
diminuir consideravelmente a quantidade de marcadores processados dependendo da sua
Definição de estratégias 40
utilizacao por parte do usuario. Esta estrategia parte do princıpio de que e nao e possıvel
prever as acoes do usuario, uma vez que o mapa e carregado e portanto carregar marcadores
que estao localizados fora da area visıvel e disperdıcio de processamento, uma vez que o
usuario pode nunca navegar para estas areas.
Uma desvantagem desta abordagem e a adicao de complexidade adicional no carrega-
mento dos marcadores para limitar a quantidade de marcadores processados. Este aumento
na complexidade do codigo pode aumentar os custos de manutencoes corretiva e evolutiva.
As figuras 4.4 e 4.5 exibem a diferenca entre carregar todos os marcadores e carregar
apenas os marcadores contidos na area visıvel.
Figura 4.4: Carregamento de todos os marcadores [LM]
Definição de estratégias 41
Figura 4.5: Carregamento dos marcadores presentes na area visıvel do usuario [LM]
4.2.4 Realizar o carregamento por streaming de marcadores
Estrategia consagrada por sites de publicacao de conteudo multimıdia como o youtube
para diminuir substancialmente o tempo de acesso ao conteudo. Os marcadores sao divi-
didos em grupos pequenos e enviados ao browser aos poucos, permitindo que o primeiro
acesso do usuario demore um tempo significativamente menor do que se fosse necessario
carregar o conteudo de forma monolıtica.
E disponibilizado ao usuario de forma rapida uma pequena parte dos marcadores. En-
quanto o usuario e livre para interagir com as informacoes ja disponıveis na tela, o browser
realiza sucessivamente pequenas requisicoes AJAX de marcadores e os disponibiliza ime-
diatamente apos recebe-los como exemplificado no codigo 4.2.3. Esta estrategia tende a
melhorar muito a latencia de acesso do site e, no primeiro acesso, causar um efeito de
Codigo 4.2.3: Trecho de codigo JavaScript usando AJAX para recuperacao de marcadores
4.2.5 Estrategias selecionadas
As estrategias selecionadas foram carregar marcadores por streaming e agrupa-los em
clusters. Dado o seu baixo impacto em outras propriedades qualitativas do sistema como
manutencao e usabilidade.
A estrategia de utilizacao de paginas XHTML simples foi descartada pela caracterıstica
indesejada de possuir alto impacto na usabilidade dos mapas, aumentar a complexidade de
manutencao da aplicacao web e diminuir a escalabilidade do sistema.
Por sua vez, a estrategia de limitar o carregamento dos marcadores foi excluıda apenas
por limitacao de recurso de tempo para a bateria de otimizacao.
4.3 Taticas de implementacao
Para implementar o streaming de marcadores foi necessario criar chamadas AJAX para
a realizacao da query que antes retornava todos os marcadores. Esta query foi alterada -
limitando-se arbitrariamente em 10 o numero de registros retornados - para que o controle
dos pacotes seja realizado via JavaScript.
Existem varias algoritmos para a criacao de clusters de marcadores em mapas, alguns
analisados foram:
4.3.1 Cluster baseado em grid
O cluster baseado em grid funciona dividindo o mapa em varios quadrados que mudam
de tamanho conforme o nıvel de zoom em que o mapa se encontra e agrupando todos os
marcadores dentro de um mesmo quadrado em clusters. As figuras 4.6 e 4.7 ilustram este
processo.
Táticas de implementação 43
Figura 4.6: Posicao dos marcadores nos grids [LM]
Figura 4.7: Clusters em seus respectivos grids [LM]
Apesar de sua implementacao ser direta e simples e seu desempenho extremamente
rapido existe um problema com esta abordagem. Durante o agrupamento dos marcadores,
Táticas de implementação 44
existe a possibilidade de marcadores muito proximos estarem em quadrados diferentes, isto
pode levar a uma grande imprecisao visual apos o agrupamento dos marcadores.
4.3.2 Cluster baseado em distancia
Esta tecnica e similar a anterior com a a diferenca de que ao inves de criar quadrados
fixos no mapa para agrupar os marcadores, este agrupamento e realizado de acordo com
a distancia de cada marcador para centroides dinamicos de clusters. Estes centroides sao
criados com base em criterios relativos as posicoes dos marcadores na mapa, enquanto
que a distancia de agrupamento e parametrizada. As figuras 4.8 e 4.9 exemplificam este
processo.
Figura 4.8: Grande numero de marcadores no mapa [LM]
Implementação das otimizações 45
Figura 4.9: Clusters agrupados por distancia [LM]
A implementacao desta tecnica e um pouco mais complexa do que a anterior, porem
produz resultados visuais muito mais precisos para o agrupamento. A Google Maps API
possui recursos de agrupamento de marcadores em cluster que implementa um comporta-
mento bem similar ao descrito anteriormente e tambem disponibiliza funcionalidades para
o controle de parametros de agrupamento.
Portanto, para o agrupamento de marcadores em cluster foi escolhida a tecnica de
clusterizacao baseada em distancia usando os mecanismo de agrupamento disponibilizados
pela Google Maps API.
4.4 Implementacao das otimizacoes
As principais tecnologias utilizadas pela aplicacao web do sistema sao XHTML, CSS,
Python e JavaScript. Outras tecnologias (frameworks) sao utilizadas para adicionar fun-
cionalidades a aplicacao web, os frameworks de interesse para este trabalho sao Django1 e
Google Maps API 2.
1Framework para aplicacoes web escrito em Python e que roda em servidores web.2Framework escrito em JavaScript e que roda em browsers para incorporar servicos de mapas
do Google a aplicacoes web.
Implementação das otimizações 46
O Django utiliza um Design Pattern conhecido como MVC 3 cujo objetivo e isolar as
regras de negocio da aplicacao de sua interface de usuario, isto permite o desenvolvimento
e edicao separados destas partes [HKM08]. No MVC, o modelo e o codigo que representa
as entidades que sao tratadas pela aplicacao e os dados que podem ser persistidos. A visao
utiliza o modelo para exibir dados ao usuario e suas interacoes com o mesmo disparam a
execucao de codigo do controlador. O controlador, por sua vez, recebe entrada de dados
atraves da visao, processa estes dados utilizando o modelo e inicia uma resposta ao usuario
que sera exibida pela visao [SM02]. A figura 4.10 exibe uma representacao simplificada do
MVC e seus elementos correlatos no Django.
Figura 4.10: Representacao dos elementos do Django no modelo MVC
As taticas de implementacao escolhidas impactam em como o modelo da aplicacao e
exibido e processado, porem, devido ao baixo acoplamento proporcionado pelo MVC, nao
foi necessario realizar modificacoes no modelo da aplicacao. A figura 4.11 exibe de forma
simplificada o ciclo de vida do processamento de uma requisicao HTTP para a exibicao do
mapa no sistema, os elementos modificados aparecem na cor verde.
3Acronimo para Model View Controller
Implementação das otimizações 47
Figura 4.11: Ciclo de vida simplificado de uma requisicao HTTP para a exibicao do mapa
No arquivo settings.py, onde sao realizadas configuracoes globais globais da aplicacao
web, foi adicionada uma constante para representar a quantidade de marcadores a ser
transferida durante cada requisicao. O trecho de interesse deste arquivo e exibido no
codigo 4.4.1.
1 //Codigo omitido para simplificac~ao2 DEBUG = false3 QUANTIDADE_PONTOS_PAGINA=104 FLAG_STATUS_NORMAL = 05 TEMPLATE_DEBUG = DEBUG6 //Codigo omitido para simplificac~ao
Codigo 4.4.1: Trecho do arquivo settings.py
Esta constante, QUANTIDADE PONTOS PAGINA, sera utilizada nas funcoes que
processam a requisicao HTTP para definir o tamanho maximo de um conjunto de registros
a ser retornado pela query que busca informacoes sobre as unidades remotas no banco de
dados, este e o ponto de partida para a implementacao do streaming de marcadores.
A funcao que processa a requisicao para acessar a pagina do mapa na aplicacao esta
Codigo 4.4.3: Extrutura XHTML do arquivo mapa.xhtml
O codigo 4.4.3 omite alguns trechos de codigo para aumentar a claridade do mesmo.
Apesar deste arquivo possuir a extensao .xhtml ele nao e um arquivo XHTML valido.
O Django utiliza sua propria Template Engine4 que consiste em inserir o resultado da
avaliacao de variaveis e expressoes Python em zonas especıficas nas marcacoes XHTML.
O codigo 4.4.4 exibe uma das funcoes JavaScript omitidas no codigo 4.4.3 chamada
load() cujo proposito e iniciar o mapa provido pela Google Maps API.
4Framework interno para renderizar paginas web a partir de modelos.
Implementação das otimizações 50
1 var map;2 var janela;3 var points_normal = [];4 var flag_normal = {{FLAG_STATUS_NORMAL}};5 var data_hora_atualizacao_evento=0;6 var temp_normal = [];7 var pagina_atual=0;8 //Codigo omitido para simplificac~ao9 function load(){
10 var map_points = [];11 map = new Map( ’map’ , {{ x }} , {{ y }} , {{ zoom }} );12 map.gmap.addControl(new GSmallMapControl());13 map.gmap.disableDoubleClickZoom();14 map.gmap.enableScrollWheelZoom();15 iniciar_pontos();16 window.opener.location.reload();17 setTimeOut("atualizarPontosUR()",500);18 }19 //Codigo omitido para simplificac~ao
Codigo 4.4.4: Funcao load() do arquivo mapa.xhtml
A funcao load() faz uso do objeto Map() que cria um mapa com suporte para adicionar
marcadores no mesmo. O codigo 4.4.5 exibe a definicao deste objeto.
Implementação das otimizações 51
1 //Codigo omitido para simplificac~ao2 function Point(lat,long,html,url,icon) {3 this.gpoint = new GMarker(new GLatLng(lat,long),{icon:icon,});4 this.html = html;5 this.url = url;6 }7 //Codigo omitido para simplificac~ao8 function Map(id,lat,long,zoom) {9 this.id = id;
10 this.gmap = new GMap2(document.getElementById(this.id));11 this.gmap.setCenter(new GLatLng(lat, long), zoom);12 this.addmarker = addmarker;13 function addmarker(point) {14 if (point.html) {15 GEvent.addListener(point.gpoint, "mouseover", function() {16 var tabs = [];17 tabs.push(new GInfoWindowTab(’Nome’, point.html[0]));18 tabs.push(new GInfoWindowTab(’Serial’, point.html[1]));19 point.gpoint.openInfoWindowHtml(’<h3>Codigo: <hover_text>’ + point.html[0] +20 ’<p><h3>Evento: <hover_text>’ + point.html[2] + ’<p>’ +21 ’<h2><h3>Endereco: <p><hover_text>’ + point.html[1]);22 });23 GEvent.addListener(point.gpoint, "mouseout", function() {24 point.gpoint.closeInfoWindow();25 });26 }27 if (point.url){28 GEvent.addListener(point.gpoint, "click", function(latlng) {29 function abrir(URL) {30 var width = 350;31 var height = 250;32 var left = 99;33 var top = 99;34 if( janela ){35 janela.close()36 }37 janela = window.open(URL,’janela’);38 janela.focus();39 }40 abrir(’/admin/monitoramento/unidade/’ + point.url + ’/?_popup=1&&monitorar=1&&mapa=1’);41 });42 }43 this.gmap.addOverlay(point.gpoint);44 }45 }46 //Codigo omitido para simplificac~ao
Codigo 4.4.5: Objeto Map() do arquivo mapa.xhtml
A funcao load() tambem realiza uma chamada a funcao iniciar pontos() que instancia os
marcadores a serem inseridos no mapa, configura aspectos visuais dos mesmos e configura
a funcao carregar pontos normal() para ser executada apos um segundo. O codigo 4.4.6
mostra a definicao desta funcao.
Implementação das otimizações 52
1 //Codigo omitido para simplificac~ao2 function iniciar_pontos(){3 var points = [];4 {% for unidade in UR_normal %}5 var icon = new GIcon();6 icon.image = "/site_media/img/icons/green.png";7 icon.shadow = "/site_media/img/icons/shadow.png";8 icon.iconSize = new GSize(16, 27);9 icon.shadowSize = new GSize(26, 28);
10 icon.iconAnchor = new GPoint(6, 20);11 icon.infoWindowAnchor = new GPoint(5, 1);12 points.push([ {{ unidade.relacao.posto.latitude }} , {{ unidade.relacao.posto.longitude }} ,13 [’{{ unidade.relacao.posto.substacao }}{{ unidade.relacao.posto.codigo }}’,14 ’{{ unidade.relacao.posto.logradouro }}, {{ unidade.relacao.posto.bairro }}’,15 ’’,],16 ’{{ unidade.dados.id_ur }}’,17 icon18 ]);19 {% endfor %}20 for (var i in points){21 var point = new Point(points[i][0],points[i][1],points[i][2],points[i][3],points[i][4]);22 temp_normal.push(point);23 }24 setTimeout( "carregar_pontos_normal()" , 1000 );25 }26 //Codigo omitido para simplificac~ao
Codigo 4.4.6: Funcao iniciar pontos() do arquivo mapa.xhtml
A funcao carregar pontos normal() efetivamente adiciona estes marcadores no mapa
(ate um maximo de 10) e agenda a sua propria execucao apos um segundo. Caso existam
mais de 10 marcadores, apenas os primeiros 10 sao adicionados, os outros marcadores
serao adicionados nas execucoes subsequentes desta funcao. Esta funcao e definida no
codigo 4.4.7.
Implementação das otimizações 53
1 //Codigo omitido para simplificac~ao2 function carregar_pontos_normal(){3 if( temp_normal.length != 0 ){4 var max;5 if ( temp_normal.length > 10 ){6 max = 10;7 }else{8 max = temp_normal.length;9 }
10 for ( var i=0 ; i < max ; i++ ){11 points_normal.push( temp_normal[i] );12 map.addmarker( points_normal[ points_normal.length - 1 ] );13 if( !document.getElementById("check_normal").checked ){14 points_normal[ points_normal.length - 1 ].gpoint.hide();15 }16 }17 temp_normal.splice(0,max);18 document.getElementById("n_normal").innerHTML = points_normal.length;19 setTimeout( "carregar_pontos_normal()" , 1000 );20 }21 }22 //Codigo omitido para simplificac~ao
Codigo 4.4.7: Funcao carregar pontos normal() do arquivo mapa.xhtml
O ultimo comando da funcao load() exibida no codigo 4.4.2 e o agendamento da exe-
cucao da funcao atualizarPontosUR() exibida no codigo 4.4.8
Codigo 4.4.10: Funcao Carregar MapaAjax() do arquivo views.py
A funcao Carregar MapaAjax() realiza uma query limitando a faixa de resultados para
a pagina atual e retorna a renderizacao do template mapa2.xhtml.
O template mapa2.xhtml e exibido no codigo 4.4.11. Este template instancia os objetos
marcadores retornados pela requisicao AJAX do codigo 4.4.10, remove unidades remotas
que tenham sido excluıdas e verifica se o carregamento de marcadores foi finalizado.
Implementação das otimizações 55
1 {% load i18n admin_modify adminmedia %}2 {% load funcoes_monitoramento %}3 {% load funcoes_admin %}4 var view_normal = document.getElementById("check_normal").checked;5 var points = [];6 var point,endimg;7 var id_tipo_evento_aux;8 var icon,alterar=0;9 {% for unidade in UR %}
10 id_tipo_evento_aux = {{unidade.dados.id_tipo_evento}};11 icon = new GIcon();12 {%ifequal unidade.dados.id_tipo_evento FLAG_STATUS_NORMAL %}13 icon.image = "/site_media/img/icons/green.png";14 {% endifequal %}15 icon.shadow = "/site_media/img/icons/shadow.png";16 icon.iconSize = new GSize(16, 27);17 icon.shadowSize = new GSize(26, 28);18 icon.iconAnchor = new GPoint(6, 20);19 icon.infoWindowAnchor = new GPoint(5, 1);20 alterar=0;21 {%ifequal finalizado 1 %}22 alterar=2;23 for ( var i=0 ; i < points_geral.length ; i++ ){24 if(parseInt(points_geral[i][2],10)==parseInt({{ unidade.dados.id }},10)){25 if(parseInt(points_geral[i][3],10)!=parseInt({{ unidade.dados.id_evento }},10)){26 point = points_geral[i][0];27 map.gmap.removeOverlay(point.gpoint);28 points_geral.splice(i,1);29 alterar=1;30 }else{31 alterar=0;32 }33 break;34 }35 }36 {%endifequal%}37 if (!finalizado){38 point = new Point({{ unidade.relacao.posto.latitude }},39 {{ unidade.relacao.posto.longitude }},40 [’{{ unidade.relacao.posto.substacao }}{{ unidade.relacao.posto.codigo }}’,],41 ’{{ unidade.dados.id_ur }}’,icon);42 temp_normal.push([point]);43 }44 {% endfor %}45 {% for unidade in urs_deletadas %}46 for ( var i=0 ; i < points_geral.length ; i++ ){47 if(parseInt(points_geral[i][2],10)==parseInt({{ unidade.dados.id }},10)){48 a=1;49 point = points_geral[i][0];50 map.gmap.removeOverlay(point.gpoint);51 points_geral.splice(i,1);52 alterar=1;53 break;54 }55 }56 {% endfor %}57 quantidade_total_paginas = parseInt({{page_cnt}},10);58 quantidade_total_urs = parseInt({{ur_cnt}},10);59 if(pagina_atual>quantidade_total_paginas){60 data_hora_atualizacao_evento = ’{{data_hora}}’;61 finalizado=1;62 pagina_atual=parseInt(0,10);63 }64 if(pagina_atual==0){65 data_hora_atualizacao_evento = ’{{data_hora}}’;66 }
Codigo 4.4.11: Template mapa2.xhtml
Implementação das otimizações 56
Com estas implementacoes o streaming de marcadores esta finalizado, porem ainda e
necessario implementar o agrupamento dos marcadores em clusters. Para isso, e necessario
alterar a funcao Map() para instanciar o cluster de marcadores. Esta alteracao e exibida
no codigo 4.4.12.
1 if (GBrowserIsCompatible()) {2
3 function Point(lat,long,html,url,icon) {4 this.gpoint = new GMarker(new GLatLng(lat,long),{icon:icon,});5 this.html = html;6 this.url = url;7 }8
9 //Codigo omitido para simplificac~ao10 function Map(id,lat,long,zoom) {11 this.id = id;12 this.gmap = new GMap2(document.getElementById(this.id));13 this.gmap.setCenter(new GLatLng(lat, long), zoom);14 this.addmarker = addmarker;15 this.markerclusterer = new MarkerClusterer(this.gmap);16 //Codigo omitido para simplificac~ao17 //this.gmap.addOverlay(point.gpoint);18 this.markerclusterer.addMarker(point.gpoint);19 function addmarker(point) {20 //Codigo omitido para simplificac~ao21 }//Map
Codigo 4.4.12: Funcao load() modificada do arquivo mapa.xhtml
Por fim, e preciso alterar a forma como os marcadores sao adicionados no mapa, ini-
cialmente os marcadores eram adicionados diretamente no mapa, apos a implementacao
do cluster, estes marcadores passam a ser adicionados somente no cluster. Para tanto, a
funcao addmarker() deve ser alterada como mostra o codigo 4.4.13.
Resultados Obtidos 57
1 //Codigo omitido para simplificac~ao2 function addmarker(point) {3 if (point.html) {4 //Codigo omitido para simplificac~ao5 }6 if (point.url){7 GEvent.addListener(point.gpoint, "click", function(latlng) {8 function abrir(URL) {9 var width = 350;var height = 250;
10 var left = 99;var top = 99;11 if( janela ){12 janela.close()13 }14 janela = window.open(URL,’janela’);15 janela.focus();16 }17 abrir(’/admin/monitoramento/unidade/’ + point.url + ’/?_popup=1&&monitorar=1&&mapa=1’);18 });19 }20 this.markerclusterer.addMarker(point.gpoint);21 }22 //Codigo omitido para simplificac~ao
Codigo 4.4.13: Funcao carregar pontos normal() alterada no arquivo mapa.xhtml
4.5 Resultados Obtidos
Apos a selecao das taticas de otimizacao, as mudancas estruturais propostas para a
arquitetura da aplicacao web do sistema foram implementadas e uma nova bateria de
testes de carga e de desempenho foi realizada seguindo a mesma metodologia e ambiente
e casos de testes utilizada no capıtulo 3.
A tabela 4.1 condensa os resultados obtidos apos a realizacao da segunda bateria de
testes de carga.
Tabela 4.1: Segunda bateria de testes de cargaQtd. marcadores 10 50 100 1000 3000Tempo de carga 2.371s 2.732s 2.521s 2.420s 2.684s
Ja a tabela 4.2 sumariza os resultados obtidos apos a execucao da segunda bateria de
testes de desempenho.
Resultados Obtidos 58
Tabela 4.2: Segunda bateria de testes de desempenhoQtd. marcadores 10 50 100 1000 3000
Tempo de execucao 0.082s 0.136s 0.090s 0.291s 0.245s
As figuras 4.12 e 4.13 exibem os resultados da segunda bateria de testes (pos-
otimizacao).
Figura 4.12: Resultados da segunda bateria de testes de desempenho
Análise Comparativa 59
Figura 4.13: Resultados da segunda bateria de teste de carga
4.6 Analise Comparativa
Ao comparar os resultados obtidos na primeira e segunda bateria de testes de carga,
e possıvel observar uma otimizacao drastica de desempenho no tempo de carregamento
da pagina de mapas. A figura 4.14 demonstra que o tempo de carregamento de pagina
apresenta um tempo praticamente constante variando apenas 0.313mS e manteve-se no
mınimo 5.2s aquem dos limites estabelecidos nos cenarios de testes (8s). O motivo deste
resultado e que com a nova implementacao, independente da quantidade de marcadores no
banco de dados o primeiro acesso a tela exibira inicialmente no maximo 10 marcadores.
Ja nos testes de interacao, observou-se um pequeno aumento no tempo de execucao
para a exibicao de uma quantidade pequena de marcadores como demonstra a figura 4.15,
porem mantendo uma degradacao de desempenho muito menor durante a exibicao de uma
quantidade grande de marcadores e mantendo o resultado dos testes abaixo do limite
maximo estabelecido em todos os cenarios de teste. Este aumento no tempo de resposta
para pequenas quantidades de marcadores deve-se ao overhead causado pela adicao de uma
camada adicional de codigo JavaScript, esta pequena diminuicao na capacidade de resposta
Análise Comparativa 60
do sistema foi compensada pelo grande aumento de sua escalabilidade para este requisito.
Figura 4.14: Comparacao entre as duas baterias de teste de carga
Figura 4.15: Comparacao entre as duas baterias de teste de desempenho
Capıtulo 5
Conclusoes
Prazos de entrega cada vez mais curtos, orcamentos cada vez mais enxutos, requisitos
qualitativos cada vez mais agressivos requerem a utilizacao de metodos de engenharia para
tratar estas questoes com viabilidade tecnica e economica.
Antes de aplicar a otimizacao de desempenho no sistema foi essencial caracterizar seus
elementos de interesse atraves da utilizacao do IEEE1471, a utilizacao desta tecnica permi-
tiu a elaboracao de requisitos de desempenho bem definidos (tempo de carga e velocidade
de interacao) a serem analisados durante este trabalho. A existencia destes requisitos e
determinante para o sucesso de projetos de otimizacao.
Nenhuma das hipoteses de causa raiz dos problemas de desempenho foi refutada ou
confirmada por este trabalho, o uso do ciclo fechado de iteracao apenas utiliza as mesmas
como insumo na elaboracao de estrategias de otimizacao e trata os problemas a partir
da sıntese de implementacoes baseadas nas estrategias. O criterio de parada - atingir os
requisitos de desempenho propostos - para a aplicacao do ciclo fechado de iteracao foi
atingido ao final da primeira iteracao, portanto nao foram realizadas iteracoes posteriores.
O streaming de marcadores se revelou uma tecnica excelente para a diminuicao da
latencia de resposta do sistema. No inıcio dos testes, o sistema possuıa um tempo de
resposta exponencial e apos a implementacao desta tecnica o tempo de resposta passou a
ter um comportamento praticamente constante.
O agrupamento de marcadores em clusters se revelou uma tecnica que possui bom po-
tencial para melhoria da velocidade de interacao quando existem quantidades significativas
de marcadores exibidos no mapa. Com uma quantidade pequena de marcadores, e pos-
sıvel que a utilizacao desta tecnica degrade um pouco o desempenho do sistema, isto foi
observado para um numero de marcadores abaixo de 50.
62
Atividades complexas como testes e otimizacao de desempenho de sistemas computaci-
onais, precisam ser realizadas de forma estruturada para que suas iteracoes cumpram com
seus objetivos e a devida agregacao de valor para os stakeholders seja realizada. E preciso
salientar que as alteracoes estruturais dos softwares submetidos a otimizacao impactam no
balanceamento das propriedades qualitativas do sistema e portanto devem ser realizadas
com foco em objetivos de compromisso com os interesses dos stakeholders. Neste complexo
ciclo de ajustes arquiteturais, a utilizacao apropriada de metodos cientıficos e empıricos e
considerada boa pratica para acelerar o retorno de investimento.
Apesar dos resultados obtidos, este trabalho atentou para algumas propriedades quali-
tativas de interesse de stakeholders especıficos (operadores da aplicacao web do sistema),
o que deixa espaco para que trabalhos futuros identifiquem outros stakeholders, mapeiem
seus interesses e os validem de acordo com propriedades qualitativas relacionadas. O sis-
tema analisado continua passıvel de otimizacao de desempenho em diversos componentes
estruturais, tais como seu banco de dados, sua aplicacao de sensoriamento, suas unidades
remotas e mesmo a propria aplicacao web.
Referencias Bibliograficas
[BLKW95] Mario Barbacci, Thomas H. Longstaff, Mark H. Klein, and
Charles B. Weinstock. Quality attributes. software engi-
neering institute, carnegie mellon university. disponıvel em: