Na figura 5.1 são apresentadas as latências médias observadas para as várias oper- ações do DepSpace utilizadas pelos serviços mencionados. Os dados apresentados foram obtidos a partir da medição do tempo de execução de cada uma das operações aquando da execução dos benchmarks ou, visto haver operações que são menos exercitadas que outras, as operações rdAll e replace foram também exercitadas explicitamente. No total, cada uma das operações foi executada aproximadamente 30000 vezes.
Como podemos ver na figura, a latência mais baixa é a das operações rdp sendo estas da ordem dos 63 ms. As operações de inp e cas, utilizadas para remover e inserir tuplos de metadados, apresentam latências na ordem dos 66ms. Por sua vez a operação rdAll tem uma latência média de 75 ms enquanto que a operação replace demora em média 87 ms. Com isto podemos perceber que em média, as operações de leitura de metadados, mesmo não usando cache são as mais rápidas, enquanto que as operações de actualização de metadados, embora com uma diferença pouco assinalável, são as que mais tempo demoram.
Note-se também que as operações cas e inp são utilizadas pelo serviço de locks para inserir e remover tuplos de lock, respectivamente. Segundo estes experimentos, a obtenção e destruição de um lock demora então, em média, 66 ms por operação.
Capítulo 5. Avaliação Experimental 62
Figura 5.1: Latência das operações do DepSpace.
o facto de, na maioria das vezes, não ser necessário executar o protocolo de consenso distribuído para a sua execução [23]. Como podemos ver na figura, as operações inp e castem uma latência comparável à operação rdp. Isto acontece pois, visto as réplicas do DepSpace estarem todas instaladas em máquinas virtuais de uma mesma zona de disponi- bilidade do Amazon EC2, a comunicação entre estas aquando do protocolo de consenso é feita usando a rede interna do provedor do serviço, não resultando a execução do proto- colo num aumento significativo da latência das referidas operações.
A latência média observada na operação rdAll justificam-se com o facto de, embora (na maioria das vezes) não seja também necessária a execução do protocolo de consenso, a quantidade de dados lidos nesta operação ser significativamente maior que na operação rdp. Por outro lado, o valor médio da latência observado na operação replace justifica-se com o facto de, para além ser sempre executado o protocolo de consenso para ordenar a sua execução nas réplicas do DepSpace, esta operação pode activar o Trigger de substitu- ição de tuplos (ver secção 4.2).
Latência das Operações rdp e getMetadata
Na figura 5.2 é apresentada a diferença existente entre a latência média das operações rdp do DepSpace e getMetadata do serviço de directorias com cache. Aqui podemos perceber a eficiência da operação getMetadata para diferentes valores de ∆ e, assim, perceber de que forma é que este valor melhora o desempenho desta operação. Estes valores, ao contrário dos apresentados na figura 5.1, foram obtidos tendo em conta apenas valores de latência medidos na execução dos benchmarks anteriormente descritos sobre o sistema. Assim, os valores apresentados são a média dos valores obtidos de dez execuções de cada benchmarks, utilizando o serviço de directorias com cache com os valores 0, 100, 150 e 500 ms para o parâmetro ∆. O valor 0 foi escolhido para testar o comportamento
Capítulo 5. Avaliação Experimental 63
do serviço sem a utilização de cache. A escolha dos valores 100 e 150 pretende testar o comportamento do serviço quando os metadados são mantidos em cache por um tempo aproximado à latência das operações do DepSpace no pior caso. O valor 500 foi escolhido com o objectivo de perceber até que ponto a subida de ∆ influencia o desempenho do serviço.
Figura 5.2: Latência da obtenção de metadados.
Como podemos observar na figura 5.2, quando o valor de ∆ é 0, não existem ganhos de latência da utilização do serviço, sendo a latência média das operações getMetadata igual à das operações rdp no DepSpace. Por outro lado, sempre que é utilizada cache no serviço de directorias, a latência na obtenção de metadados passa a cerca de metade da latência das operações rdp. Observa-se também que, com o aumento do valor de ∆ (e assim o aumento do tempo em que os metadados permanecem válidos em cache), existem pequenas melhorias no valor da latência média da operação getMetadata quando comparado com o mesmo valor para a operação de leitura do DepSpace.
Através da análise da figura podemos também perceber que os ganhos de desempenho da operação getMetadata não são proporcionais à subida do valor de ∆. Isto é facilmente perceptível, por exemplo, verificando as latências médias desta operação com ∆ = 100 e ∆ = 500. Neste caso, sendo o valor de ∆ cinco vezes superior, enquanto que a latência média para ∆ = 100 é aproximadamente 50% menor que latência média da operação rdp, para ∆ = 500 existe um ganho de apenas 56.5%. Assim podemos concluir que, para obter importantes ganhos de desempenho, o valor do parâmetro ∆ deve ser maior que zero, mas não demasiado grande. Embora com a subida deste valor sejam observadas melhorias no desempenho da operação getMetadata, este aumento leva também a uma diminuição da coerência dos metadados mantidos no DepSpace. É então importante que este factor seja tido em conta na escolha do valor deste parâmetro.
Capítulo 5. Avaliação Experimental 64
Latência das Operações do C2FS e Tempo de Execução dos Benchmarks
As figuras 5.3 e 5.4 apresentam, respectivamente, a latência média de várias operações do sistema de ficheiros e o tempo de execução dos benchmarks para diferentes valores do parâmetro ∆.
A figura 5.3 apresenta a latência média de algumas operações do sistema relacionadas com os metadados. Os valores apresentados nesta figura foram obtidos através da ex- ecução sobre o C2FS do workload do Filebench que simula um servidor de ficheiros. Cada valor resulta da média dos oito melhores valores obtidos de dez execuções. Note-se, antes de mais, que cada uma destas operações (com a excepção da operação close) inclui uma ou mais obtenções de metadados dos ficheiros operados, resultando a melhoria do desempenho da operação getMetadata numa melhoria das mesmas. Note-se ainda que a operação open, para além de obter os metadados do ficheiro a abrir, nos casos em que este é aberto para escrita, implica também a aquisição de um lock sobre o seu contentor de dados. É também necessário ter em conta que é na operação close que os dados são escritos para as clouds, logo, é necessário actualizar os metadados (através da chamada à operação updateLocalMetadata do serviço de directorias).
Figura 5.3: Latência das operações do sistema de ficheiros.
Como podemos ver, também para estes experimentos, o aumento do valor de ∆ rep- resenta sempre um aumento do desempenho. Em todas as operações, tal como anterior- mente observado, a utilização de cache de metadados representa a diminuição da latência das mesmas para cerca de metade. Uma excepção é a operação close. Este compor- tamento justifica-se com o facto de, neste operação, não haver necessidade de obter os metadados do ficheiro que se pretende fechar. É também importante observar que, tam- bém neste experimento se verifica que a diminuição da latência não é proporcional ao aumento do valor do parâmetro ∆.
Capítulo 5. Avaliação Experimental 65
copy files e create files do Filebench para diferentes valores de ∆. Tal como no caso da figura anterior, os resultado aqui apresentados resultam da média dos oito melhores valores obtidos de dez execuções.
Figura 5.4: Tempo de execução de benchmarks.
Tal como anteriormente, também nesta figura podemos verificar que a utilização de cachede metadados representa um aumento do desempenho do serviço de directorias, e assim, o desempenho global do C2FS. Em todas as execuções, o desempenho aumenta com o crescimento do valor do parâmetro ∆. Podemos ver que, com ∆ = 100, temos tempos de execução aproximadamente 50% menores que para ∆ = 0 (48% para o Post- Mark, 43% e 52% para os workloads create files e copy files, respectivamente). Com o aumento do valor de ∆ continuam a existir ganhos no desempenho do sistema, sendo estes, no entanto, mais modestos. As melhorias com o aumento do tempo de validade dos metadados em cache de 100 para 500, no caso dos tempos de execução do PostMark e do workload copy filessão de apenas 10.1% e 13.2%, respectivamente. No caso do workload create files, para os mesmos valores de ∆, temos ganhos bastante nos tempos médios de execução (na ordem dos 25%).