Ap´os a realizac¸˜ao dos v´arios benchmarks apresentados, o DDS foi testado num ambiente mais realista, utilizando 4 r´eplicas com a BFT-SMaRt [41] como biblioteca de replicac¸˜ao e com uma variac¸˜ao de carga no sistema atrav´es do aumento progressivo do n´umero de clientes por experiˆencia. Os resultados (d´ebito do servic¸o e latˆencia das operac¸˜oes2) foram
ent˜ao comparados aos resultados obtidos na execuc¸˜ao do DepSpace no mesmo ambiente. As primeiras experiˆencias consideram apenas 1 cliente do servic¸o, de modo a obter resul- tados base que permitem a comparac¸˜ao e aceitac¸˜ao de resultados com mais clientes. De seguida, aumentamos o n´umero de clientes para 10, 100, 1000 e 10000.
Numa primeira fase foram testadas as operac¸˜oes b´asicas do servic¸o, ou seja, as operac¸˜oes out(inserc¸˜ao de tuplos), inp (remoc¸˜ao de tuplos) e rdp (leitura de tuplos), onde 100% da carga do sistema se resumia a cada uma destas operac¸˜oes. Numa segunda fase, o DDS foi testado com diferentes cargas. Em primeiro lugar, as experiˆencias consideravam uma carga de 50% de inserc¸˜oes e 50% de remoc¸˜oes de tuplos. A carga das restantes ex- periˆencias foi de 80% de leituras, 10% de inserc¸˜oes e 10% de remoc¸˜oes de tuplos. Todas as experiˆencias foram efectuadas em apenas um espac¸o de tuplos l´ogico, acedido por todos os clientes.
Tal como referido na secc¸˜ao 4.3, foi executada uma fase de pre-warmup nas ex- periˆencias com cargas de 100% de remoc¸˜oes e de leituras. A criac¸˜ao de tuplos e padr˜oes para a realizac¸˜ao de operac¸˜oes ´e a mesma apresentada na secc¸˜ao 4.3.1.
4.4.1
100% de inserc¸˜oes de tuplos
Os resultados obtidos nas experiˆencias com 100% de inserc¸˜oes de tuplos s˜ao apresentados na figura 4.3.
A figura 4.3(a) mostra a comparac¸˜ao entre os d´ebitos obtidos com o DepSpace e com o DDS, considerando diferentes clientes a inserir tuplos. Como era previsto, o d´ebito do DDS ´e menor do que o do DepSpace, devido ao custo das escritas para disco. Por´em, quando temos uma carga de 10000 clientes, o d´ebito do DDS ´e 30.03% menor do que o d´ebito do DepSpace (14739 ops/s do DepSpace vs 10313 ops/s do DDS). Tendo em conta que o DDS mant´em a durabilidade dos dados e oferece uma maior fiabilidade do que o DepSpace, a perda de 1/3 do d´ebito parece-nos aceit´avel.
Os resultados mostram tamb´em que, com cargas superiores a 1000 clientes, o d´ebito do DepSpace estabiliza e o d´ebito do DDS continua a aumentar. Na secc¸˜ao 4.3.2, vi- mos que o DDS sem camada de replicac¸˜ao consegue d´ebitos na ordem das 18000 ops/s, enquanto o DepSpace debita pelo menos 25000 ops/s. No entanto, nessas situac¸˜oes os batchesde mensagens s˜ao muito maiores do que os recebidos nestas experiˆencias, o que explica o facto de nunca terem sido alcanc¸ados os mesmos d´ebitos das experiˆencias ante-
Cap´ıtulo 4. Avaliac¸˜ao 44
riores. Para al´em disso, com mensagens com tamanhos superiores a 1KB, o ponto cr´ıtico do sistema passa a ser o protocolo de ordenac¸˜ao (BFT-SMaRt).
(a) D´ebitos do DepSpace e do DDS. (b) Comparac¸˜ao entre os d´ebitos do DepSpace e do DDS e as latˆencias das suas operac¸˜oes.
Figura 4.3: Resultados do DepSpace e do DDS com 100% de inserc¸˜oes de tuplos.
Embora os d´ebitos do DDS sejam visivelmente inferiores aos do DepSpace, as latˆencias das operac¸˜oes de ambos os servic¸os tendem a aproximar-se (ver figura 4.3(b)). Conside- rando a mesma carga de 10000 clientes, a figura 4.3(b) mostra um aumento de 15% da latˆencia do DepSpace para a do DDS (332.7 ms no DepSpace vs 383.1 ms no DDS).
4.4.2
100% de remoc¸˜oes de tuplos
A figura 4.4 mostra os resultados de latˆencia e d´ebito obtidos nas experiˆencias com cargas de 100% de remoc¸˜oes de tuplos.
Analisando a figura 4.4(a), podemos concluir que apesar da grande diferenc¸a entre os d´ebitos do DepSpace e do DDS, uma maior carga nos sistemas levaria os d´ebitos a tomarem valores bastante semelhantes. Com 10000 clientes o d´ebito do DepSpace j´a se encontra a decrescer, enquanto o d´ebito do DDS ainda aumenta significativamente, verificando-se uma diminuic¸˜ao de 43% do DepSpace para o DDS (31636 ops/s no DepS- pace vs 18040 ops/s no DDS).
Em relac¸˜ao `as latˆencias das operac¸˜oes de remoc¸˜ao (figura 4.4(b)), e considerando os 10000 clientes, o DDS tem uma latˆencia de remoc¸˜ao de tuplos 232% maior do que a latˆencia do DepSpace (119.2 ms no DepSpace vs 395.5 ms no DDS). Esta grande diferenc¸a na latˆencia das operac¸˜oes de remoc¸˜ao tem como principal factor o logging dos batchesrecebidos pelo servic¸o. Durante as experiˆencias efectuadas, o DepSpace recebeu um total de 3897 batches com uma m´edia de 477 operac¸˜oes cada um, enquanto o DDS re- cebeu um total de 306 batches com 3569 operac¸˜oes cada um. Sabendo que cada operac¸˜ao
Cap´ıtulo 4. Avaliac¸˜ao 45
tem um tamanho de 1KB, o DDS escreveu para disco 3569 KB (aproximadamente 3.6 MB) por cada batch recebido, o que justifica a grande diferenc¸a observada.
(a) D´ebitos do DepSpace e do DDS. (b) Comparac¸˜ao entre os d´ebitos do DepSpace e do DDS e as latˆencias das suas operac¸˜oes.
Figura 4.4: Resultados do DepSpace e do DDS com 100% de remoc¸˜oes de tuplos.
Nestas experiˆencias podemos ver que os d´ebitos de ambos os servic¸os s˜ao superiores aos apresentados na figura 4.3(a) devido ao facto de os templates utilizados nas operac¸˜oes de remoc¸˜ao terem metade do tamanho dos tuplos utilizados nas experiˆencias de inserc¸˜ao de tuplos, o que permite `a BFT-SMaRt garantir um maior d´ebito na ordenac¸˜ao de mensa- gens.
4.4.3
100% de leituras de tuplos
As operac¸˜oes de leitura de tuplos tˆem duas particularidades em relac¸˜ao `as restantes: nor- malmente n˜ao requerem a execuc¸˜ao do protocolo de ordenac¸˜ao da biblioteca BFT-SMaRt e n˜ao s˜ao mantidas em disco pelo DDS.
O facto de n˜ao serem guardadas em disco pelo DDS, significa que, com cargas de 100% de leituras, o d´ebito deste servic¸o tem de ser semelhante ao d´ebito do DepSpace, j´a que n˜ao ´e efectuado qualquer logging das operac¸˜oes.
Os resultados presentes na figura 4.5 confirmam o que foi agora descrito.
Como pode ser observado na figura 4.5(a), com 10000 clientes, o d´ebito do DDS ´e muito semelhante ao d´ebito do DepSpace, sendo a diferenc¸a de 0.08% (12639 ops/s no DepSpace vs 12629 ops/s no DDS), o que n˜ao ´e relevante.
Apesar das semelhanc¸as nos d´ebitos de ambos os servic¸os, existem diferenc¸as nas latˆencias que n˜ao podem ser ignoradas (ver figura 4.5(b)). A diferenc¸a de 85.10% entre latˆencia das operac¸˜oes de 10000 clientes (267.6 ms no DepSpace vs 495.3 ms no DDS) pode ser explicada por diferentes taxas de sucesso da operac¸˜ao rdp no espac¸o de tuplos.
Cap´ıtulo 4. Avaliac¸˜ao 46
Quando um cliente recebe, como resultado de uma operac¸˜ao rdp, uma confirmac¸˜ao em como a operac¸˜ao n˜ao teve sucesso, volta a tentar a mesma operac¸˜ao. No entanto, esta segunda operac¸˜ao ´e enviada utilizando o protocolo de ordenac¸˜ao do servic¸o [24], o que aumenta a sua latˆencia. No caso de a segunda tentativa de leitura falhar, o cliente assume que n˜ao existe nenhum tuplo com o padr˜ao desejado e prossegue a sua execuc¸˜ao com outras operac¸˜oes.
(a) D´ebitos do DepSpace e do DDS. (b) Comparac¸˜ao entre os d´ebitos do DepSpace e do DDS e as latˆencias das suas operac¸˜oes.
Figura 4.5: Resultados do DepSpace e do DDS com 100% de leituras de tuplos.
4.4.4
50% inserc¸˜oes e 50% remoc¸˜oes de tuplos
Nestas experiˆencias foram utilizados 50% dos clientes a executar operac¸˜oes de inserc¸˜ao e os restantes 50% a executar operac¸˜oes de remoc¸˜ao de tuplos. Os clientes n˜ao devem efec- tuar os dois tipos de operac¸˜oes para que o compilador JIT da JVM do consiga optimizar o c´odigo, de forma a obter melhores resultados.
Os resultados destas experiˆencias (ver figura 4.6) podem ser validados a partir do resultados presentes nas secc¸˜oes 4.4.1 e 4.4.2. Por exemplo, a figura 4.6(a) mostra que com 100 clientes o DDS debita 2918 ops/s. Se considerarmos os mesmos 100 clientes nas figuras 4.3(a) e 4.4(a), vemos que os d´ebitos do DDS s˜ao de 2803 e 3119 ops/s, respectivamente. Como temos de considerar apenas 50% dos clientes para cada tipo de operac¸˜ao, temos que 2803 × 50% + 3119 × 50% = 2961 ops/s, apenas mais 43 ops/s do que o observado na realidade.
Os resultados das figuras 4.6(a) e 4.6(b) est˜ao conforme o previsto, com pouca diferenc¸a em relac¸˜ao aos previstos em c´alculos semelhantes ao apresentado para 100 clientes.
Cap´ıtulo 4. Avaliac¸˜ao 47
(a) D´ebitos do DepSpace e do DDS. (b) Comparac¸˜ao entre os d´ebitos do DepSpace e do DDS e as latˆencias das suas operac¸˜oes.
Figura 4.6: Resultados do DepSpace e do DDS com 50% de inserc¸˜oes e 50% de remoc¸˜oes de tuplos.
4.4.5
80% leituras, 10% inserc¸˜oes e 10% remoc¸˜oes de tuplos
As experiˆencias apresentadas nesta secc¸˜ao consideram 80% dos clientes a executar operac¸˜oes de leitura, 10% a executar operac¸˜oes de inserc¸˜ao e os restantes 10% a executar operac¸˜oes de remoc¸˜ao de tuplos.
A validac¸˜ao dos resultados obtidos nestes experiˆencias (ver figura 4.7) pode ser efec- tuada atrav´es dos c´alculos apresentados na secc¸˜ao anterior, com os resultados das ex- periˆencias das secc¸˜oes 4.4.1, 4.4.2. e 4.4.3.
Uma an´alise `as figuras 4.7(a) e 4.7(b) mostra que o desempenho (latˆencias das operac¸˜oes e d´ebito do sistema) do DDS ultrapassa o desempenho do DepSpace com 100, 1000 e 10000 clientes. Apesar de a diferenc¸a ser m´ınima, estes resultados mostram que mesmo garantindo a durabilidade, o DDS consegue obter bons desempenhos com cargas reais, que contˆem leituras, inserc¸˜oes e remoc¸˜oes de tuplos.
Como foi descrito na secc¸˜ao 3.4.3, foram implementados dois mecanismos de loc- king(moderate e extreme) no DDS, que garantem diferentes propriedades de controlo de acesso. De forma a corroborar a hip´otese de que o uso moderate locking far´a com que o desempenho do DDS seja superior ao desempenho com o uso de extreme locking, com- par´amos as latˆencias das operac¸˜oes e o d´ebito do DDS com os dois mecanismos, como mostram as figuras 4.8(a) e 4.8(b).
Estes mecanismos apenas foram testados com estas cargas de 80% de operac¸˜oes n˜ao ordenadas e 20% de operac¸˜oes ordenadas por serem as ´unicas experiˆencias que envolviam estes dois tipos de operac¸˜oes, podendo a obtenc¸˜ao de locks para leitura e para escrita ser testada devidamente.
Cap´ıtulo 4. Avaliac¸˜ao 48
(a) D´ebitos do DepSpace e do DDS. (b) Comparac¸˜ao entre os d´ebitos do DepSpace e do DDS e as latˆencias das suas operac¸˜oes.
Figura 4.7: Resultados do DepSpace e do DDS com 80% de leituras, 10% de inserc¸˜oes e 10% de remoc¸˜oes de tuplos.
(a) Moderate vs Extreme Locking no DDS. (b) Comparac¸˜ao entre os d´ebitos e as latˆencias das operac¸˜oes do DDS com moderate e extreme locking.
Figura 4.8: Comparac¸˜ao dos resultados do DDS com moderate e extreme locking.
Como podemos observar na figura 4.8(a), a hip´otese estava correcta, pelo que o de- sempenho do DDS, com moderate locking e uma carga de 10000 clientes, ´e 319% superior ao desempenho observado com o uso de extreme locking (13369 ops/s com moderate e 3191 com extreme locking).
J´a a figura 4.8(b) mostra que, nas mesmas condic¸˜oes, a latˆencia das operac¸˜oes com moderate locking´e 82% menor comparada `a latˆencia com o uso de extreme locking.
Apesar dos resultados com moderate locking serem visivelmente melhores do que os resultados obtidos com extreme locking, este primeiro mecanismo n˜ao garante a con-
Cap´ıtulo 4. Avaliac¸˜ao 49
sistˆencia do sistema, como referido na secc¸˜ao 3.4.3, o que inviabiliza a sua utilizac¸˜ao.