Para avaliar o DDS sem as limitac¸˜oes de latˆencia impostas pela biblioteca de replicac¸˜ao, foram feitas algumas experiˆencias com o DepSpace e o DDS sem a camada de replicac¸˜ao. Assim, foi iniciada uma r´eplica numa das m´aquinas apresentadas na secc¸˜ao 4.1 e foram- lhe passados batches de operac¸˜oes contendo entre 1 e 1000 operac¸˜oes.
Nas experiˆencias feitas, foram criados v´arios tuplos para inserir nos espac¸os de tuplos e ainda padr˜oes (i.e., templates) para as operac¸˜oes de remoc¸˜ao e leitura. Os tuplos criados contˆem 4 campos no formato String, num total de 1KB de tamanho1, ou seja, cada campo ocupa 256 bytes. Dado que cada string ´e representada no formato UTF-16 [32], onde cada caractere ´e representado por 2 bytes, os campos dos tuplos / templates s˜ao preenchidos com strings de 128 caracteres. Antes de dar in´ıcio `as experiˆencias, as strings utilizadas s˜ao obtidas de um ficheiro que cont´em 40000 strings diferentes, todas com 128 caracteres, e s˜ao distribu´ıdas uniformemente pelos tuplos.
Enquanto isso, os templates das operac¸˜oes de remoc¸˜ao e leitura s˜ao tamb´em repre- sentados por tuplos de 4 campos. No entanto, apenas os dois primeiros s˜ao strings do ficheiro, sendo os dois ´ultimos compostos pela string “*”, que representa um campo n˜ao definido (ver [5] para mais detalhes).
A distribuic¸˜ao uniforme das strings faz com que todas elas tenham a mesma probabi- lidade de ser utilizadas no tuplos ou templates criados pelos clientes. Isto faz com que a probabilidade de uma operac¸˜ao de leitura ou remoc¸˜ao utilize um template com os mesmos campos de um tuplo que existe no espac¸o de tuplos, garantindo assim que estas operac¸˜oes tˆem alguma probabilidade de sucesso, ainda que inferior a 100%.
Para al´em do d´ebito e latˆencia dos sistemas, foram testadas duas novas concretizac¸˜oes dos espac¸os de tuplos e ainda o tempo de criac¸˜ao de checkpoints de v´arios tamanhos e o tempo de leitura de um ficheiro de log e recriac¸˜ao das operac¸˜oes contidas nesse ficheiro.
Cap´ıtulo 4. Avaliac¸˜ao 39
4.3.1
Avaliac¸˜ao das concretizac¸˜oes do espac¸o de tuplos
As vers˜oes iniciais do DepSpace implementam o espac¸o de tuplos como uma lista de tuplos, o que permite obter bons resultados de latˆencia nas operac¸˜oes de out, pois apenas se insere o tuplo pretendido no final da lista. No entanto, as latˆencias das operac¸˜oes inp (remoc¸˜ao) e rdp (leitura) s˜ao demasiado altas devido `a pesquisa ineficiente no espac¸o de tuplos. O algoritmo de pesquisa consiste apenas em percorrer toda a lista, tuplo a tuplo, at´e encontrar o tuplo pretendido (complexidade linear).
De forma a optimizar estas operac¸˜oes, foram propostas duas novas concretizac¸˜oes para o espac¸o de tuplos, baseadas em ´ındices (ver secc¸˜ao 3.4.2). As concretizac¸˜oes di- vergem apenas na ordenac¸˜ao dos ´ındices implementados, sendo uma baseada em ´ındices ordenados(ou IO) e a outra em ´ındices n˜ao ordenados (ou INO), considerando dois n´ıveis de profundidade (ver figura 3.5).
Ap´os a implementac¸˜ao das novas concretizac¸˜oes de espac¸os de tuplos, foi feita uma avaliac¸˜ao ao desempenho do DepSpace e do DDS com os 3 diferentes tipos de espac¸os de tuplos, para verificar qual a implementac¸˜ao que teria o melhor desempenho nas operac¸˜oes de inserc¸˜ao (out) e remoc¸˜ao (inp).
Para testar a operac¸˜ao inp, foi necess´aria a introduc¸˜ao de uma fase de pre-warmup onde s˜ao inseridos tuplos nos espac¸os de tuplos. Esta fase ´e necess´aria para garantir uma taxa de sucesso das operac¸˜oes realizadas nas experiˆencias.
As tabelas 4.3 e 4.4 mostram os resultados da latˆencia de cada operac¸˜ao out e inp, respectivamente, considerando batches (ver secc¸˜ao 3.2.1) de v´arios tamanhos.
Tal como previsto, a lista de tuplos ´e a implementac¸˜ao que atinge as menores latˆencias nas operac¸˜oes out (cerca de 8% menores do que as conseguidas com INO e 46% menores do que as obtidas com IO, se considerarmos batches de 1000 mensagens no DepSpace), dada a simplicidade da operac¸˜ao em quest˜ao. As implementac¸˜oes com ´ındices, tˆem um processamento adicional de verificar se os ´ındices correspondentes `aquele tuplo existem, criar os ´ındices em caso negativo e, no ´ultimo n´ıvel considerado, inserir o tuplo na lista de tuplos a que corresponde. Entre as novas implementac¸˜oes de espac¸os de tuplos, os ´ındices n˜ao ordenados s˜ao ligeiramente melhores do que os ordenados.
No entanto, se considerarmos os resultados das experiˆencias com batches de 1000 operac¸˜oes no DDS, podemos ver que os ´ındices ordenados superam os ´ındices n˜ao orde- nados.
Em termos de remoc¸˜ao de tuplos, a lista ´e claramente ineficiente, sendo que a introduc¸˜ao de espac¸os de tuplos com ´ındices melhorou significativamente as latˆencias destas operac¸˜oes (melhorias de 99% com ambos os ´ındices, comparando os resultados das latˆencias de bat- chesde 1000 mensagens). Mais uma vez, os ´ındices n˜ao ordenados fazem os sistemas obterem resultados de latˆencias ligeiramente melhores do que os ´ındices ordenados. Es- tas diferenc¸as s˜ao mais vis´ıveis nos resultados obtidos com o DDS, onde a latˆencia da execuc¸˜ao de batches com 1000 operac¸˜oes de remoc¸˜ao em ´ındices n˜ao ordenados ´e 91%
Cap´ıtulo 4. Avaliac¸˜ao 40
inferior `a latˆencia de execuc¸˜ao de batches semelhantes em espac¸os de tuplos com ´ındices ordenados.
Latˆencia (ms)
DepSpace DDS Tamanho do Batch Lista INO IO Lista INO IO
1 0,457 0,064 0,068 7,074 6,737 6,537 10 0,231 0,062 0,059 1,582 1,703 1,543 100 0,030 0,032 0,034 0,218 0,221 0,219 1000 0,024 0,037 0,040 0,069 0,089 0,069
Tabela 4.3: Latˆencias das operac¸˜oes out com o processamento de batches de diferentes tamanhos no DepSpace e no DDS com diferentes concretizac¸˜oes dos espac¸os de tuplos.
Latˆencia (ms)
DepSpace DDS
Tamanho do Batch Lista INO IO Lista INO IO 1 1,141 0,232 0,216 5,963 5,004 5,193 10 2,2415 0,052 0,134 2,537 1,468 2,01 100 2,782 0,044 0,055 2,827 0,199 0,661 1000 3,213 0,041 0,047 3,494 0,063 0,694
Tabela 4.4: Latˆencias das operac¸˜oes inp com o processamento de batches de diferentes tamanhos no DepSpace e no DDS com diferentes concretizac¸˜oes dos espac¸os de tuplos.
Os resultados apresentados mostram tamb´em que, com o aumento do tamanho do batchprocessado, a diferenc¸a entre as latˆencias das operac¸˜oes no DepSpace e no DDS diminui, o que significa que as latˆencias impostas pelo logging das operac¸˜oes diminui ao ponto de poder ser desconsiderada.
Atrav´es dos resultados resultados obtidos, podemos concluir que a implementac¸˜ao de espac¸os de tuplos com ´ındices n˜ao ordenados (INO) foi a que obteve melhores resulta- dos nas operac¸˜oes de remoc¸˜ao de tuplos, pelo que todos os resultados apresentados nas pr´oximas secc¸˜oes j´a consideram o uso destes espac¸os de tuplos.
4.3.2
DDS vs DepSpace
Ainda considerando testes locais nas m´aquinas Servidor, a figura 4.1(a) mostra a evoluc¸˜ao do d´ebito de operac¸˜oes out com o aumento do tamanho dos batches passados ao DepSpace e ao DDS, enquanto a figura 4.1(b) mostra a evoluc¸˜ao da latˆencia das operac¸˜oes out com o aumento da carga em ambos os servic¸os.
Os resultados mostram que o DDS consegue debitar quase tantas operac¸˜oes por se- gundo como o DepSpace, caso os batches de operac¸˜oes sejam grandes o suficiente. Com batchesde 100000 mensagens, o DepSpace debita 25000 ops/s e o DDS debita 18333 ops/s, ou seja, uma diminuic¸˜ao de apenas 26% do DepSpace para o DDS.
Cap´ıtulo 4. Avaliac¸˜ao 41
Em termos de latˆencia de operac¸˜oes, pode observar-se um aumento das latˆencias com o aumento do d´ebito em ambos os servic¸os. Com batches de 100000 mensagens, o DDS tem uma latˆencia de 4500 ms por cada batch, enquanto o DepSpace tem uma latˆencia de 3500 ms, ou seja, um aumento de 1 segundo do DepSpace para o DDS. A raz˜ao das latˆencias do DDS serem superiores `as do DepSpace ´e a escrita das suas operac¸˜oes para o disco, o que n˜ao acontece neste ´ultimo.
(a) D´ebitos do DepSpace e do DDS sem camada de replicac¸˜ao.
(b) Comparac¸˜ao entre os d´ebitos do DDS e as latˆencias das suas operac¸˜oes.
Figura 4.1: Resultados das experiˆencias no DepSpace e no DDS sem a camada de replicac¸˜ao.
No entanto, se o DDS implementasse logging s´ıncrono em vez de logging paralelo `a execuc¸˜ao das suas operac¸˜oes e escrevesse as operac¸˜oes individualmente para disco em vez de batches de mensagens, a tabela 4.2 mostra que a latˆencia de execuc¸˜ao de 100000 operac¸˜oes seria de 699500 ms, o que equivale a mais de 11 minutos. Nas mes- mas condic¸˜oes, ou seja, a executar operac¸˜oes individualmente, o DepSpace demoraria 40772 ms, ou seja 40 segundos, a executar as mesmas 100000 operac¸˜oes, enquanto o DDS optimizado com logging paralelo e batching de operac¸˜oes demoraria 505 ms, ou seja, 8 segundos, a executar essas mesmas operac¸˜oes . Com estes valores conclu´ımos que o DDS n˜ao optimizado teria uma latˆencia superior `a do DepSpace em 11 minutos e que a optimizac¸˜ao do logging em conjunto com a execuc¸˜ao de batches de operac¸˜oes melho- raram as latˆencias do DDS em 19871%, representando melhorias muito significativas no desempenho do servic¸o.
4.3.3
Logging & Checkpointing
Depois de implementados os algoritmos de leitura e escrita de ficheiros de log e de check- point, foram realizadas experiˆencias para avaliar os tempos de leitura de um ficheiro de loge recuperac¸˜ao do estado contido nele e ainda o tempo de escrita de um checkpoint
Cap´ıtulo 4. Avaliac¸˜ao 42
para disco. As expericˆencias efectuadas consideraram leituras e escritas de ficheiros com 100, 1000, 10000 e 100000 tuplos de 4 campos e com 64, 256, 512 e 1024 bytes e ainda uma operac¸˜ao para a criac¸˜ao do espac¸o de tuplos.
Os resultados da escrita de checkpoints est˜ao na figura 4.2(a) e os resultados da recuperac¸˜ao do estado a partir do ficheiro de log est˜ao na figura 4.2(b).
Como era de esperar, os resultados mostram que o aumento do tamanho dos tuplos inseridos aumenta a latˆencia da escrita dos checkpoints e da recuperac¸˜ao do estado do log.
(a) Latˆencia da gerac¸˜ao de checkpoints no DDS. (b) Latˆencia das recuperac¸˜oes de estado a partir do fi- cheiro de log no DDS.
Figura 4.2: Resultados das experiˆencias efectuadas com as camadas de logging e check- pointingdo DDS.
Ainda em relac¸˜ao `as escritas dos checkpoints, podemos ver que escrever checkpoints com 10000 tuplos de 1024 bytes (aproximadamente 10 MB de estado) demora 439.3 ms, ou seja, menos de meio segundo. Isto significa que, com 10000 tuplos de 1 KB no espac¸o de tuplos, no momento em que o sistema tem de escrever um checkpoint, a execuc¸˜ao de operac¸˜oes dos clientes p´ara durante menos de um segundo, o que pensamos ser bastante aceit´avel.
A recuperac¸˜ao de estado a partir do log demora, no caso de existirem 10000 tuplos de 1KB no ficheiro, 5.8 segundos, ou seja, nesse intervalo de tempo o DDS lˆe e interpreta o log, cria o espac¸o de tuplos e insere l´a todos os 10000 tuplos. A diferenc¸a entre recuperar 10000 tuplos com 64 e 1024 bytes ´e de 1.6 segundos (4.1 segundos para tuplos com 64 bytese 5.8 segundos com tuplos 1024 bytes), ou seja, um aumento de 41%, o que mostra que o tamanho dos tuplos influencia bastante a latˆencia da recuperac¸˜ao do estado a partir dos ficheiros.
Cap´ıtulo 4. Avaliac¸˜ao 43