- Os testes de 30 Writes e 100 Writes foram feitos com o objetivo final de ter 100 Adventures no estado Confirmed.
- Escolhemos analisar os resultados com base nos valores de latência e do throughput por serem os parâmetros mais representativos do impacto da politica otimista da FenixFramework nas chamadas aos serviços remotos.
- Não executámos os testes com 2000 utilizadores porque a carga na memória era demasiado elevada e os resultados que obtivémos com 100 utilizadores foram suficientes para a nossa análise.
- Considerámos que Sample Time = Latência + Processing Time
- Google Docs com todos os resultados da análise (gráficos e tabelas): Link
Este teste evidencia uma situação em que a politica otimista implementada pela FenixFramework produz maior aumento de desempenho, sem grandes consequências negativas ao nivel da latência.
- Read Brokers
- Read Adventures
- Read Banks
- Read Clients
- Read Accounts
- Read Hotels
- Read Rooms
- Read Providers
- Read Activities
- Read Offers
Podemos concluir que aumentando o número de utilizadores conseguimos aumentar significativamente o desempenho (throughput) do sistema sem prejudicar de forma significativa a latência.
Observámos que para a maioria das operações os valores da latência não são muito influenciados pelo aumento de utilizadores, visto que não ocorrem conflictos nas operações de READ e não é necessário abortar/reiniciar transações.
Comparando o Sample Time com a Latency verificámos que estes tempos são muito semelhantes para cada operação nas mesmas condições de teste: isto indica-nos que o tempo de processamento das instruções é muito baixo (Sample Time = Latency + Processing Time), o que corresponde ao que seria de esperar numa operação de READ.
Como neste teste só são executadas operações de READ, não existem conflitos nas transações de cada utilizador, logo, a taxa de erros para cada operação é de 0%.
- Process Adventure
- Read Adventures
- Read Banks
- Read Clients
- Read Accounts
- Process Adventure
- Read Rooms
- Read Activities
- Read Offers
- Process Adventure
Observámos que o throughput diminui tendencialmente com a diminuição do número de utilizadores, visto que são executadas 70% de operações de Read e neste tipo de situações o aumento do número de utilizadores está associado a um aumento do throughput (ver conclusões do teste 100 Reads).
No entanto, a existência de operações Write provoca um aumento do throughput porque ocorrem menos conflitos e consequences restarts (ver conclusões do teste de 100 Writes).
Adicionalmente, verificámos também que com 10 e 4 utilizadores o throughput atingiu os valores mais elevados, embora não tenha superado o desempenho com 100 utilizadores. Julgamos que isto se deva à distribuição do processamento pelos cores do processador, visto que utilizámos para os testes um computador com 4 cores.
De acordo com a política otimista da Fénix Framework, quando se faz uma escrita na base de dados esta é iniciada imediatamente e apenas no final é feito um teste de validação. Quando este teste falha, a operação de escrita é reiniciada.
Consequentemente, com muitos utilizadores, e respetivas escritas concorrentes, é expectável que existam mais falhas nos testes de validação, o que obriga a vários recomeços de transações.
Isto traduz-se no aumento da latência quando aumenta o número de utilizadores como se pode observar facilmente no gráfico acima. Para piorar a situação, como são processadas operações de Read e Write concorrentes, ocorrem mais conflitos o que faz com que a latência seja ainda maior do que se as operações fossem só de Read ou de Write.
Em relação aos erros durante o teste, verifcamos que só foram encontrados erros com 100 utilizadores, o que se deve muito provavelmente às escritas concorrentes dos vários utilizadores que causam falhas nos testes de validação. Outro factor que poderá ter influenciado a taxa de erros é a população dos dados que foi feita para cada teste.
- Process Adventure
- Process Adventure
- Process Adventure
- Process Adventure
- Process Adventure
Observámos que o throughput aumenta naturalmente com a diminuição do número de utilizadores, visto que se reduz o número de conflitos entre as operações de escrita concorrentes e consequentes restarts.
Adicionalmente, verificámos também que com 10 e 4 utilizadores o throughput atingiu os valores mais elevados. Julgamos que isto se deva à distribuição do processamento pelos cores do processador, visto que utilizámos para os testes um computador com 4 cores.
De acordo com a política otimista da Fénix Framework, quando se faz uma escrita na base de dados esta é iniciada imediatamente e apenas no final é feito um teste de validação. Quando este teste falha, a operação de escrita é reiniciada.
Consequentemente, com muitos utilizadores, e respetivas escritas concorrentes, é expectável que existam mais falhas nos testes de validação, o que obriga a vários recomeços de transações. Isto traduz-se no aumento da latência quando aumenta o número de utilizadores como se pode observar facilmente no gráfico acima.