• Nenhum resultado encontrado

5.4 An´ alise do Desempenho

5.4.3 Considera¸c˜ oes sobre o Desempenho nos Experimentos

Nos primeiros experimentos foi observado que o tempo de execu¸c˜ao em um dos provedores de nuvem selecionados foi excessivamente alto. Foi constatado que a m´aquina em execu¸c˜ao passava mais tempo trabalhando em tarefas relacionadas a entrada e sa´ıda de dados (I/O) ao inv´es de efetivamente usar os processadores na

sua m´axima capacidade. Como estava sendo empregado um computador como ser- vidor de arquivo, foi poss´ıvel monitorar a velocidade do fluxo de dados na rede e, consequentemente, o fluxo para leitura e grava¸c˜ao de arquivos. O monitoramento do fluxo de dados foi realizado por meio do aplicativo speedometer gerando os gr´aficos de atividades a exemplo dos apresentados na Figura 5.32.

Figura 5.32: Exemplo de fluxo de I/O da execu¸c˜ao de atividades do SciEvol. Estes gr´aficos apresentam os resultados do monitoramento do fluxo de dados em uma mesma atividade nos provedores A e B. O eixo x dos gr´aficos apresenta o tempo demandado, no eixo y est´a a velocidade do fluxo de informa¸c˜ao e as siglas TX e RX representam, respectivamente, a taxa de dados transmitidos e recebidos. ´E poss´ıvel observar que a vaz˜ao de disco do provedor B (parte inferior) ´e constante e alta em rela¸c˜ao a capacidade total do recurso, limitando TX em 59, 0M bytes/s, RX em 31, 1M bytes/s. J´a no provedor A a taxa de transmiss˜ao ´e mais alta se comparado ao primeiro provedor, obtendo um TX em 220M bytes/s e um RX em 250M bytes. Portanto, o gargalo da execu¸c˜ao no provedor B s˜ao os recursos de I/O. Analisando os gr´aficos fica claro o quanto ´e primordial escolher recursos computacionais na nuvem com maiores taxa e velocidade de acesso ao disco, pois trata-se de um recurso que impacta diretamente no tempo total de execu¸c˜ao do workflow.

objetivo de aumentar os recursos para a redu¸c˜ao do tempo de execu¸c˜ao. A princ´ıpio, uma reprodu¸c˜ao utiliza a mesma quantidade e caracter´ısticas de recursos usados no experimento original. No entanto, um cientista pode ter o interesse de aumentar o n´umero de recursos com o objetivo de diminuir o tempo de execu¸c˜ao, uma vez que ele tem acesso a uma grande variedade de recursos dos provedores de nuvem. Por exemplo, no caso do Montage, que ´e um workflow intensivo de dados, a redu¸c˜ao do tempo de execu¸c˜ao n˜ao ´e proporcional ao aumento do n´umero de recursos de processamento. A redu¸c˜ao do tempo de execu¸c˜ao ´e dependente da otimiza¸c˜ao dos recursos relacionados a disco.

Por exemplo, foi observado que um workflow que executou as suas atividades com 8 n´ucleos em 30 minutos obteve um ganho de 33% no tempo de execu¸c˜ao ao executar o mesmo workflow com 32 n´ucleos, nesse caso, em 20 minutos. Levando em considera¸c˜ao que cada n´o usado nos experimentos tinha 8 n´ucleos, ser´a necess´ario multiplicar o valor dos recursos usados no primeiro cen´ario por 4 para alcan¸car os 32 n´ucleos do segundo cen´ario do experimento. Por´em, a velocidade de acesso ao disco n˜ao cresce na mesma propor¸c˜ao que o n´umero de n´ucleos adicionados ao experimento, portanto, pode ser necess´ario fazer uma op¸c˜ao por manter o n´umero de n´ucleos baixo executando por um maior tempo ao inv´es de alocar mais recursos de processamento para melhorar o desempenho, j´a que se trata de uma reprodu¸c˜ao.

´

E importante destacar que o provedor de nuvem oferece uma diversidade de re- cursos de computa¸c˜ao. O cientista que vai reproduzir o experimento pode fazer a implanta¸c˜ao com recursos com maior desempenho, por´em, deve analisar os custos que ser˜ao despendidos com essa decis˜ao. Portanto, a escolha do tipo de instˆancia fica a cargo do experimentador. A abordagem sugere as instˆancias baseada nos dados de proveniˆencia sobre os perfis de computadores usados na execu¸c˜ao do ex- perimento original, para a produ¸c˜ao dos resultados, por´em, n˜ao ´e uma regra usar especificamente os recursos apontados.

A ado¸c˜ao do ReproeScience causa uma sobrecarga na execu¸c˜ao do workflow, conforme mostrado na Figura 5.33. O percentual dessa sobrecarga tamb´em ´e apre- sentado na Tabela 5.7. As an´alises foram aplicadas aos cen´arios de 16 e 32 cores no ambiente de produ¸c˜ao dos dados no cluster. S˜ao apresentados os comportamentos da execu¸c˜ao tanto com a abordagem de monitoramento Repro quanto com a Strace. As barras em amarelo mostram o tempo de resposta das execu¸c˜oes apoiadas pelo ReproeScience, enquanto as barras em azul mostram as execu¸c˜oes sem esse apoio.

Diante desses resultados, ´e necess´ario fazer uma an´alise para verificar os impactos da sobrecarga causada pela ado¸c˜ao da solu¸c˜ao de reprodu¸c˜ao. Principalmente em que momento ela deve ser adotada, em todas as execu¸c˜oes ou somente no momento em que a execu¸c˜ao de produ¸c˜ao dos resultados for efetivada.

0:00:00 0:05:00 0:10:00 0:15:00 0:20:00 0:25:00 0:30:00 0:35:00 0:40:00

Scievol Scievol Montage Montage Scievol Scievol Montage Montage

Strace Repro Strace Repro Strace Repro Strace Repro

16 32 T emp o d e Exe cu ção (h h :mm:s s) Ambiente Avaliado

Avaliação da sobrecarga do ReproeScience - SciCumulus

Execução Monitorada Execução Não Monitorada

Figura 5.33: Sobrecarga da ado¸c˜ao do ReproeScience aos experimentos. Tabela 5.7: Porcentagem de carga adicionada a execu¸c˜ao dos workflows com a ado¸c˜ao do ReproeScience.

Cores Monitor Workflow Execu¸c˜ao Monitorada Execu¸c˜ao N˜ao Monitorada Diferen¸ca Tempo Sobrecarga (%) 16 Strace Scievol 00:28:32 00:27:33 00:00:58 3,51 Repro Scievol 00:27:20 00:26:32 00:00:48 3,02 Strace Montage 00:38:02 00:36:03 00:01:59 5,50 Repro Montage 00:26:24 00:24:13 00:02:11 9,02 32 Strace Scievol 00:16:18 00:15:15 00:01:03 6,89 Repro Scievol 00:15:48 00:14:45 00:01:03 7,12 Strace Montage 00:29:35 00:27:10 00:02:25 8,9 Repro Montage 00:18:40 00:16:13 00:02:27 15,11