5. Validação
5.3. Testes de Performance após Optimizações
Após as optimizações que foram realizadas no sistema de eventos da plataforma (ver cap. 4.3.4), foi novamente avaliado o desempenho dos vários componentes da plataforma, de forma a validar o resultado das optimizações efectuadas. Para tal, foram repetidos os mesmos tipos de testes, tendo sido aproveitada a oportunidade para aumentar a escala dos mesmos.
30% 37% 31% 1%0%1%0%0%0%0%0%0%0%0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%0%0%0%0%0%
Tempo Total
UtteranceMessageListener GenericDAOImpl WookieConnectorBean5.3.1. Integração do Wave na Plataforma
1. Objectivo do teste
Validar o desempenho temporal dos módulos da plataforma na criação de sessões com o recurso Wave. Comparar os resultados obtidos com os analisados no capítulo 5.2.2.
2. Descrição do teste
O teste consistiu em efectuar, concorrentemente, três mil sessões colaborativas da plataforma com a funcionalidade colaborativa Document Edition e o servidor de recursos Wave. Por efectuar uma sessão entende-se todo o processo de construção da mesma: criação de um grupo, em que cada grupo criado possuía três participantes; criação de uma conversa com esse grupo; criação da sessão a partir da conversa; efectuar a reserva de recursos da sessão através do setup da mesma. Comparando com a validação original, neste teste foram efectuadas mais duas mil sessões concorrentemente. Pretendia-se elevar a carga para as dez mil sessões concorrentes, porém tal não foi possível devido às limitações impostas pela máquina disponível para realizar os testes.
3. Ambiente de realização do teste
Para realizar o teste foi instalada a plataforma no servidor aplicacional JBoss 5.1.0. O servidor JBoss foi instalado num PC com processador Intel Core 2 Duo 2.40Ghz, 3 GB de RAM, 320 GB de disco rígido e sistema operativo Windows 7 32-bit. O JBoss foi executado a partir do IDE Eclipse, através do plugin JBoss Tools [75]. O teste foi implementado através do serviço Session Scheduler do JBoss [71]. Para medir a performance temporal da plataforma usou-se uma ferramenta para profiling do servidor JBoss no Eclipse, o Eclipse Test & Performance Tools Platform [74].
O servidor Wave FedOne e a base de dados da plataforma foram instaladas nas mesmas condições descritas no capítulo 5.2.2.
4. Resultados do teste
A figura 19 representa o tempo total gasto em cada componente da plataforma para realizar o teste. A primeira observação que é feita a partir da figura é que o componente UtteranceMessageListener, que no capítulo 5.2.2 correspondia a 40% do tempo gasto e que foi um dos alvos das optimizações feitas, deixou de aparecer no gráfico. Analisando os dados brutos obtidos, confirmou-se que o componente já não é usado no processo de criação e setup de sessões. Por outro lado, o componente GenericDAOImpl continua a ter a maior percentagem de tempo gasto, 66%. No gráfico é também visível um novo componente, SessionServiceBean. Este componente faz a ligação entre o GenericDAOImpl e os restantes módulos da plataforma. Por
“Eager”, ou seja, todos de uma só vez e tal era feito no GenericDAOImpl. Quando os novos testes foram realizados, este acesso à base de dados tinha sofrido optimizações neste campo, realizadas por outros membros da equipa de desenvolvimento da plataforma. Nomeadamente, alguns dos atributos da sessão colaborativa eram obtidos da base de dados de forma “Lazy”, ou seja, só eram obtidos quando tal era necessário. No entanto, por motivos de teste, eles estavam a ser forçadamente obtidos no SessionServiceBean de forma a garantir que estavam correctos.
Figura 19 - Integração do Wave na Plataforma - Tempo total gasto em cada classe após optimizações
Resumindo, ambos os componentes GenericDAOImpl e SessionServiceBean correspondem a acessos de base de dados, o que significa que com as optimizações desenvolvidas sobre o sistema de eventos, 89% do tempo gasto na criação e setup de sessões com o Wave é gasto com a base de dados.
O componente WaveConnectorBean corresponde a 5% do tempo gasto, o que confirma as conclusões tiradas no parágrafo anterior uma vez que este componete quase não sofreu alteração quando comparado com as validações originais (4%).
5.3.2. Funcionalidades de Recording e Play
1. Objectivo do teste
Validar o desempenho temporal dos módulos desenvolvidos para as funcionalidades de Recording e Play após as optimizações efectuadas ao sistema de eventos. Comparar os resultados obtidos com os das validações originais.
2. Descrição do teste
O teste consistiu em simular uma sessão colaborativa com o recurso slideshow e efectuar o recording da mesma. O recording foi feito através do UtteranceGuide slide, ou seja, o recording
66% 23% 5% 1% 1% 1% 1% 1% 0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
Tempo Total
GenericDAOImpl SessionServiceBean WaveConnectorBeandas utterances foi guiado por transição de slide. Foi também usada a funcionalidade de sincronização com recursos de texto, através do servidor Wave. O slideshow usado continha 100 slides e o teste foi executado 50 vezes, ou seja, no total foram registados 5000 slides. Comparando com a validação original, foram enviados mais 4000 slides. Pretendia-se elevar a carga para os dez mil slides, no entanto tal não foi possível devido às limitações da máquina disponível para realizar os testes.
3. Ambiente de realização do teste
O ambiente de execução deste teste foi o mesmo descrito no capítulo 5.3.1.
4. Resultados do teste
A figura 20 representa o gráfico obtido a partir dos resultados do teste efectuado. Analisando o gráfico, nota-se que não são visíveis os componentes que foram alvo de optimizações (UtteranceMessageListener, BrokerConnectorBean, etc.), ou seja, as optimizações desenvolvidas não tiveram efeitos secundários negativos. Comparando com os resultados das validações originais (cap. 5.2.3), nota-se no entanto um aumento da percentagem do WaveConnectorBean e diminuição do tempo gasto com a base de dados (GenericDAOImpl e SessionServiceBean). Isto é resultado das optimizações desenvolvidas na base de dados por outros elementos da equipa de desenvolvimento da plataforma.
Resumindo, a conclusão que se pode retirar deste teste é que as optimizações desenvolvidas sobre o sistema de eventos, cujo principal resultado foi optimizar o tempo de criação e setup de sessões, como foi visto no capítulo anterior, não teve efeitos secundários negativos aquando da utilização do mesmo para Recording de sessões.
Figura 20 - Funcionalidades de Recording e Play - Tempo total gasto em cada classe após optimizações
48% 32% 16% 1% 0% 0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0%0% 0% 0%
Tempo Total
SessionServiceBeanWaveConnectorBean
GenericDAOImpl
5.3.3. Modelo de Extensibilidade
1. Objectivo do teste
Validar o desempenho temporal dos módulos da plataforma na criação de sessões com o recurso Wookie [53]. Comparar os resultados obtidos com os analisados no capítulo 5.2.4.
2. Descrição do teste
O teste consistiu em efectuar, concorrentemente, três mil sessões colaborativas da plataforma com a funcionalidade colaborativa widget e o servidor de recursos Wookie. Por efectuar uma sessão entende-se todo o processo de construção da mesma: criação de um grupo, em que cada grupo criado possuía três participantes; criação de uma conversa com esse grupo; criação da sessão a partir da conversa; efectuar a reserva de recursos da sessão através do setup da mesma. Para seleccionar a funcionalidade colaborativa da sessão usou-se o sistema dinâmico de carregamento de funcionalidades desenvolvido. Mais especificamente, usou-se uma das widgets que vinha já instalada no servidor Wookie, denominada de Natter.
3. Ambiente de realização do teste
O ambiente de execução deste teste foi idêntico ao descrito no capítulo 5.3.1. No entanto, o servidor de recursos usado não foi o Wave, mas sim o Wookie. O servidor Wookie foi instalado num servidor aplicacional JBoss, que por sua vez estava instalado num servidor com processador Intel Xeon Dual-Core com 2.13 Ghz, 4 GB de RAM e 160 GB de disco. A base de dados do servidor Wookie, em MySql, foi instalada na mesma máquina.
4. Resultados do teste
A figura 21 representa o gráfico com os tempos totais gastos por componente, obtidos a partir do teste efectuado. Tal como no capítulo 5.3.1, ao analisar o gráfico reparamos que não é visível o componente UtteranceMessageListener, componente esse que no capítulo 5.2.4 correspondia a 30% do tempo gasto. Esta análise confirma as conclusões retiradas no capítulo 5.3.1 sobre o sucesso das optimizações efectuadas sobre o sistema de eventos.
Quanto aos outros componentes visíveis no gráfico, nota-se que houve uma diminuição quanto ao tempo gasto no WookieConnectorBean, de 31% para 19%. Tal deve-se à deslocação do servidor Wookie e sua base de dados MySql para uma máquina diferente da que estava a fazer os testes de carga. Desta forma o servidor Wookie passou a ter mais recursos disponíveis, uma vez que os testes de carga e profiling da plataforma consumem bastantes recursos. Juntando as percentagens dos dois componentes ligados à base de dados, conclui-se que na criação e setup de sessões com o recurso Wookie, 73% do tempo gasto corresponde à base de dados.
Figura 21 - Modelo de Extensibilidade - Tempo total gasto em cada classe após optimizações