Testes ao servidor do operador

Os testes efetuados ao prot´otipo do servidor do operador, visam avaliar a sua capacidade e velocidade de resposta a m´ultiplosrequests HTTP em simultˆaneo, em situa¸c˜oes decheck-in, paragens interm´edias e check-out. Apesar de, num sistema real, o servidor lidar com todo o tipo de pedidos em simultˆaneo, neste caso os trˆes tipos de situa¸c˜oes referidas s˜ao avaliadas em testes diferentes, de forma a permitir visualizar e avaliar os resultados obtidos separadamente.

Tal como nos testes `a aplica¸c˜ao, os tempos de resposta devem-se situar, no m´ınimo, abaixo do tempo esperado entre as paragens/esta¸c˜oes mais pr´oximas, que neste caso ser´a considerado 1 minuto, e os resultados permitir˜ao avaliar se o sistema implementado necessita de aumentar a sua escalabilidade.

Osetup de testes empregue est´a representado na Figura 6.9 e ´e constitu´ıdo por umrouter, a rede Hedera Hashgraph e um computador port´atil que aloja o servidor do operador. Este computador incorpora um processador Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, 8 GB de RAM e sistema operativo Windows 10. Osoftware Locust usado para conduzir os testes, tal como o servidor, tamb´em ´e executado no computador port´atil que comunica com orouter atrav´es deWi-Fi para “alcan¸car” a rede Hedera Hashgraph.

Osoftware Locust, atrav´es de uma API, permite configurar a quantidade de novas liga¸c˜oes TCP a aceder ao servidor, para simular utilizadores a fazerem pedidos, e definir o n´umero m´aximo de liga¸c˜oes simultˆaneas. Tamb´em ´e importante referir que, apesar da framework Django usar por defeito uma base de dados SQLite, esta demonstrou uma forte limita¸c˜ao a m´ultiplos pedidos simultˆaneos, pelo que foi alterada para uma base de dados MySQL, que permitiu melhorar o desempenho do servidor neste aspeto.

Os testes efetuados, foram separados em trˆes processos: processo decheck-in, processo de valida¸c˜ao de uma paragem interm´edia e processo de check-out.

A simula¸c˜ao docheck-in foi programada de forma a enviar POSTs HTTP para as classes do servidor: AnnouncementAPI - onde ´e efetuada a valida¸c˜ao dos an´uncios de paragem e registo do check-in - e PendingRefundAPI - respons´avel por registar o pedido de reembolso do passageiro. A simula¸c˜ao, testa a sua capacidade de resposta ao surgimento de 50 novos utilizadores por segundo a realizarcheck-ins nas suas aplica¸c˜oes, at´e ser atingido um m´aximo de 1000 passageiros em simultˆaneo a fazeremrequests ao servidor.

Neste caso, contrariamente aos testes `a aplica¸c˜ao, o request `a classe PendingRefundAPI, que envia informa¸c˜ao sobre o pagamento efetuado pelo utilizador, foi feito sem efetuar a transa¸c˜ao na Testnet Hedera Hashgraph, tendo em conta que neste caso o foco foi apenas testar a resposta do servidor. Os resultados obtidos, apresentados na Tabela 6.4, mostram que todos os requests realizados para a classe AnnouncementAPI experienciaram uma taxa

Figura 6.9: Setup de testes ao servidor.

de sucesso superior a 99,5% e de 100% para a classe PendingRefundAPI, tendo atendido 26,1 RPS (requests por segundo) e 22,9 RPS, respetivamente.

Requests Req. Falhados M´edia(ms) Mediana(ms) 95%il(ms) RPS

Check-in 1457 5 17295 22000 25000 26,1

Pagamento 1275 0 9120 10000 12000 22,9

Tabela 6.4: Requests e tempos de resposta do servidor no processo decheck-in.

Como se pode verificar na Figura 6.10, no final do gr´afico de tempos de resposta, a linha correspondente 95% das amostras que outrora estava em constante subida, mostra tendˆencia de estabilizar. Este foi o crit´erio de paragem usado em todos os testes ao servidor, em vez de este ser definido por tempo total de execu¸c˜ao ou n´umero de amostras. Da´ı terem sido feitos 1457 requests para a classe AnnouncementAPI, em situa¸c˜ao de check-in, que foram respondidos em m´edia em 17295 ms. No caso dos 1275 requests para a PendingRefundAPI verificou-se uma m´edia de 9120 ms.

No processo de valida¸c˜ao de uma paragem interm´edia tamb´em foi simulada a entrada de 50 novos passageiros por segundo, at´e serem atingidos os 1000 no total. Como mostram os resultados na Tabela 6.5, em 2796 amostras, houve 28 que n˜ao foram bem sucedidas devido ao erro “[Errno 10061] [WinError 10061] Nenhuma liga¸c˜ao pˆode ser feita porque o computador de destino as recusou ativamente.”, correspondendo a uma percentagem de 99% e um RPS de 42,1. Osrequests bem sucedidos obtiveram um tempo de resposta m´edio de 17067 ms. Os gr´aficos correspondentes a este processo, encontram-se na Figura 6.11.

Por fim, o processo decheck-out, recorreu a transa¸c˜oes na rede Hedera Hashgraph, por´em os testes ficaram limitados ao n´umero de contas Hedera Hashgraph utilizadas. Tendo em

Figura 6.10: Gr´aficos do n´umero de utilizadores, tempos de resposta e RPS, em ordem ao tempo de execu¸c˜ao, do processo decheck-in.

Requests Req. Falhados M´edia(ms) Mediana(ms) 95%il(ms) RPS

I.Paragem 2796 28 17067 16000 39000 42,1

Tabela 6.5: Requests e tempos de resposta do servidor na identifica¸c˜ao de paragens.

Figura 6.11: Gr´aficos do n´umero de utilizadores, tempos de resposta e RPS, em ordem ao tempo de execu¸c˜ao, do processo de valida¸c˜ao de uma paragem interm´edia.

conta que, na simula¸c˜ao, apenas foi usada 1 conta Hedera Hashgraph do lado dos passageiros e 1 do lado do servidor, o n´umero m´aximo de utilizadores simultˆaneos foi reduzido para 100, com o aparecimento de 5 novos utilizadores a comunicar com o servidor a cada segundo, no primeiro teste, e 1 novo utilizador por segundo, no segundo teste. Neste caso, foi decidido testar duas taxas de surgimento de novos utilizadores para estudar o impacto que a carga tem no servidor e rede Hedera Hashgraph.

Atrav´es da Tabela 6.6, pode-se verificar que em 306requests do primeiro teste houve 65 que n˜ao foram efetuados com sucesso. Isto parece dever-se `a sobrecarga das duas contas, provocada pelo envio de um n´umero elevado de transa¸c˜oes num curto per´ıodo de tempo e que resultam em mensagens de erro do tipo “invalid account amounts”, “duplicate transaction”,

“key prefix mismatch” e “invalid node account”, o que no final correspondeu a uma taxa de aprova¸c˜ao de 78,8% e RPS de apenas 6,5. Osrequests bem sucedidos obtiveram um tempo de resposta m´edio de 9227 ms. Baixando o n´umero de novos utilizadores para 1 por segundo, a taxa de sucesso dosrequests aumenta significativamente, para cerca de 95%, com o tempo de resposta a acompanhar a melhoria. Em m´edia o tempo de resposta passou a ser de 7643 ms com um RPS de 7,2. Os gr´aficos correspondentes a este processo, encontram-se nas Figuras 6.12 e 6.13.

Requests Req. Falhados M´edia(ms) Mediana(ms) 95%il(ms) RPS

CO(100/5) 306 65 9227 10000 14000 6,5

CO(100/1) 914 49 7643 7500 13000 7,2

Tabela 6.6: Requests e tempos de resposta do servidor no processo de check-out.

O aumento de escalabilidade do servidor dever´a passar pelo aumento da respetiva capa-cidade de processamento e de mem´oria, neste caso, limitado pelo uso do computador pessoal nos testes. Verificou-se em todos os testes efetuados que `a medida que o n´umero de clientes simultˆaneos aumentou, o tempo de resposta do servidor dilatou-se, tendo levado tamb´em `a perda de pedidos. O aumento de recursos computacionais recorrendo `a paraleliza¸c˜ao do aten-dimento a pedidos, por exemplo usando mais servidores, poder´a permitir n˜ao s´o melhorar o tempo de resposta como evitar o drop de requests, como ocorreu em eventos de check-in e paragem interm´edia.

No processo de check-out o limite no n´umero de requests processados em simultˆaneo dever-se-´a ao facto das transa¸c˜oes serem feitas entre apenas 2 contas Hedera Hashgraph.

Numa implementa¸c˜ao real do sistema que permita `a empresa de transporte p´ublico recorrer ao n´umero de contas Hedera Hashgraph que desejar dever´a ser poss´ıvel responder a mais transa¸c˜oes em simultˆaneo. No entanto, em 95% dos 914 requests realizados com um novo utilizador a surgir a cada segundo, os pedidos foram respondidos em menos de 13 s, o que sugere a viabilidade do uso desta criptomoeda em transportes p´ublicos tendo em conta o tempo que as suas transa¸c˜oes demoram a ser validadas.

Globalmente pode-se concluir que o sistema desenvolvido, apesar de ter sido limitado pelo hardware e n´umero de contas Hedera Hashgraph usadas, demonstra ter potencial para ser aplicado a um cen´ario real devido `a sua escalabilidade e celeridade das transa¸c˜oes da criptomoeda usada.

Figura 6.12: Gr´aficos do n´umero de utilizadores, tempos de resposta e RPS, em ordem ao tempo de execu¸c˜ao, do processo decheck-out (100/5).

Figura 6.13: Gr´aficos do n´umero de utilizadores, tempos de resposta e RPS, em ordem ao tempo de execu¸c˜ao, do processo decheck-out (100/1).