Tamanho Amazon S3 Google Cloud Storage Dropbox Lunacloud T-Stratus
0,01 MB 0,263 0,486 0,51 9,143 0,812
0,1 MB 0,255 0,495 0,543 10,317 0,683
1 MB 0,263 0,453 0,503 9,532 0,588
10 MB 0,267 0,403 0,563 11,365 0,687
Tabela 5.13: Tempos medidos (em segundos) para operações de remoção de ficheiros de diferentes tamanhos para as quatro clouds e para o middleware
0,25 0,5 1 2 4 8 16 0,01 MB 0,1 MB 1 MB 10 MB T e mpo d e exe cu ção (s e gu n d o s) Tamanho do ficheiro (MB)
Remove de ficheiros
Amazon S3Google Cloud Storage Dropbox
Lunacloud Tstratus
Figura 5.8: Gráfico correspondente aos valores da Tabela5.13
Aqui o comportamento domiddlewareé semelhante ao get, onde os tempos medidos
se encontram bastante próximos do terceiro pior tempo registado para as clouds. Como seria de esperar, verifica-se o mesmo comportamento que as clouds, onde a remoção de um ficheiro é completamente independente do seu tamanho. Derivado do estudo ante- rior, tanto às clouds, como ao peso dos vários componentes domiddlewarenuma remoção,
seria este o comportamento expectável. Como mencionado acima, iremos verificar um aumento consoante o número de fragmentos em que o ficheiro se divide, visto que é ne- cessário um número de pedidos de remove equivalente. Essa será a análise a efetuar nos testes da secção seguinte, onde é tido em conta o número de fragmentos em que se divide o ficheiro.
5.7
Diferentes tamanhos de fragmentos ao nível do middleware
O resultado da variação do tamanho dos ficheiros escritos para o middleware na secção anterior é uma das métricas mais importantes a ser avaliada, pois é o melhor indicador de performance que se pode retirar, face à inserção direta dos ficheiros nas várias cloudsusadas. Verificou-se, até este ponto, que a diferença dos tempos medidos não é significa- tiva, de forma a que possa comprometer a performance do sistema e utilização do mesmo como solução segura de armazenamento. No entanto, nesta secção, procurou-se analisar a forma como a alteração do tamanho dos fragmentos em que os ficheiros são repartidos afetada a performance das três operações principais do sistema, get, put e remove. O objetivo é tentar perceber até que ponto compensa dividir um ficheiro em fragmentos e não envia-lo na integra, como um único fragmento, de maior dimensão.
5.7.1 Inserção (put)
Inicialmente foi testada a variação da escrita de ficheiros de 1 MB para omiddleware, para
fragmentos de 100 KB, 300 KB, 600 KB e 1024 KB (este último é equivalente a não ocorrer fragmentação). Os resultados encontram-se na Tabela5.14.
Fragmento Digest Metadata Put Compressão Cifra Digest T Cache Riak 100 KB 0,009 0,008 26,825 0,047 0,02 0,007 0,007 0,092 300 KB 0,009 0,006 17,734 0,049 0,018 0,007 0,006 0,067 600 KB 0,009 0,006 16,945 0,049 0,02 0,007 0,008 0,03 1024 KB 0,009 0,007 16,302 0,048 0,019 0,007 0,004 0,03
Tabela 5.14: Tempos medidos (em segundos) para operações de escrita de ficheiros de 1 MB para o middleware, para diferentes tamanhos de fragmentos
Aqui podemos verificar que para a geração da prova de integridade (Digest) e ex- tração dos metadados do ficheiro (Metadata), a variação é praticamente inexistente, pois não tem qualquer efeito sobre o número de fragmentos e são duas operações que execu- tam sobre todo o conjunto de dados do ficheiro. A Compressão, Cifra, Digest T e Cache (sendo as três primeiras o somatório para os vários fragmentos) acabam por não sofrer alterações significativas e mantêm-se bastante idênticas para fragmentos de 100 KB a 1024KB. Já o índice Riak, para 100 KB e 300 KB apresenta um tempo superior, derivado da necessidade de armazenar uma maior quantidade de informação associada ao objeto, nomeadamente, os vários fragmentos que o compõem. No geral, ao analisar o tempo total gasto na escrita do ficheiro, conclui-se que, para ficheiros de 1 MB ou inferior, a fragmentação não é viável. Esta apenas irá piorar a performance geral do sistema, que se encontra diretamente condicionada pela operação na cloud, como visto anteriormente.
5.7.2 Obtenção (get)
De seguida foram efetuadas leituras sobre os ficheiros escritos nomiddlewareno passo an- terior. A Tabela5.15reúne os resultados obtidos, de onde podemos tirar ilações bastante semelhantes ao comportamento verificado para as escritas, na subsecção anterior.
5. AVALIAÇÃO 5.7. Diferentes tamanhos de fragmentos ao nível do middleware
Fragmento Digest Get Descompressão Decifra Cache Riak 100 KB 0,007 13,576 0,005 0,022 0 0 300 KB 0,007 7,849 0,005 0,024 0 0 600 KB 0,007 6,635 0,006 0,025 0 0 1024 KB 0,007 4,967 0,007 0,026 0 0
Tabela 5.15: Tempos medidos (em segundos) para operações de leitura de ficheiros de 1 MB a partir do middleware, para diferentes tamanhos de fragmentos
Aqui, verifica-se pouca ou nenhuma variação para a geração do Digest, bem como a Descompressão e a Decifra. O Riak apresenta o valor zero pois não chega a ser acedido em nenhuma das situações acima. O ficheiro em questão encontra-se na cache, e é direta- mente obtido da mesma, sem necessidade de recorrer ao índice principal do sistema. O valor zero associado ao tempo de obtenção do objeto da cache, com a informação acerca do ficheiro armazenado não é, na verdade, nulo. Acontece que o valor é demasiado baixo (inferior a 1 milissegundo), não sendo portanto significativo. Finalmente, conclui-se que para ficheiros menores ou iguais a 1 MB a fragmentação não é viável, pois constitui um aumento do tempo total de execução da operação.
5.7.3 Remoção (remove)
Por fim, o mesmo conjunto de dados foi analisado face à remoção dos ficheiros domid- dleware. Os tempos medidos para esta operação (Tabela5.16), como seria de esperar, de-
monstram que quanto maior o número de fragmentos, maior o tempo despendido para toda a operação.
Tamanho Remove Frag Remove Cache Riak 100 KB 0,491 5,4 0,005 0,014 300 KB 0,523 2,09 0,005 0,012 600 KB 0,5 1 0,004 0,015 1024 KB 0,588 0,588 0,009 0,012
Tabela 5.16: Tempos medidos (em segundos) para operações de remoção de ficheiros de 1 MB do middleware, para diferentes tamanhos de fragmentos
Esta conclusão era expectável, pois na subsecção 5.6.3 verificou-se que o tamanho do ficheiro não afeta a performance da operação de remoção do mesmo. No entanto, a performance degrada-se com o aumento do número de operações de remoção realizadas ao quórum bizantino. Consequentemente, quando maior o número de fragmentos em que um ficheiro se divide, maior será o tempo necessário para a remoção do mesmo.
Por fim, como conclusão desta secção, embora não sejam apresentados resultados para ficheiros superiores a 1 MB, foram realizados ensaios sobre ficheiros de 10 MB,
para fragmentos de 1 MB, 2 MB, 3 MB, 5 MB e 10 MB. Contudo, apenas foram efetua- das leitura e escritas, pois o teste à remoção de ficheiros foi conclusivo o suficiente para qualquer tamanho a considerar. A conclusão obtida para ficheiros de 10 MB foi idên- tica, verificando-se que mesmo para estes, a fragmentação não compensa face à inserção direta de um único fragmento.