Uma vez que a OpenWhisk ´e open source, ´e poss´ıvel instal´a-la localmente, de forma a realizar alguns testes para que se perceba o impacto que a infraestrutura, sobre a qual a plataforma corre, apresenta na sua performance. Os resultados obtidos foram comparados com os obtidos na execu¸c˜ao, desses mesmos testes, na plataforma OpenWhisk da IBM. Procedeu-se a instala¸c˜ao da OpenWhisk numa m´aquina virtual Linux. Esta possui um ambiente com 4 cores de CPU, 4GB de mem´oria RAM e 64GB de disco. Os passos seguidos no processo de instala¸c˜ao da plataformas podem ser vistos em https://github. com/apache/incubator-openwhisk#native-development. De forma a perceber-se qual o n´umero m´aximo de containers de execu¸c˜ao de fun¸c˜oes suportados pela instala¸c˜ao local, realizaram-se invoca¸c˜oes com um alto valor de concorrˆencia, e visualizaram-se , repetidas vezes, os containers existentes na m´aquina da instala¸c˜ao. O m´aximo obtido foi de 4 containers ativos para a fun¸c˜ao em execu¸c˜ao e 2 containers pr´e alocados para a linguagem de programa¸c˜ao utilizada, Node.js, como se pode ver na Figura 8.14.
Figura 8.14: Containers ativos de uma fun¸c˜ao e pr´e alocados para a linguagem de pro- grama¸c˜ao na instala¸c˜ao local da OpenWhisk
Foi executado o teste T1 nas duas plataformas, seguindo-se exatamente o mesmo processo que o descrito na sub-sec¸c˜ao 8.2. Os resultados calculados pelo sistema a partir das latˆencias das invoca¸c˜oes realizadas de forma sequencial, num per´ıodo de 20 segundos, em ambos os provedores, IBM e local, s˜ao apresentados na Tabela 8.5 e tamb´em mostrados sob a forma de gr´afico na Figura 8.15.
Provedor: OW IBM OW Local
Latˆencia M´axima (ms): 345 1061
Latˆencia M´ınima (ms): 237 109
Latˆencia M´edia (ms): 269.93 510.59 Desvio Padr˜ao Latˆencia (ms): 26.20 354.27 % de Invoca¸c˜oes Com Sucesso: 100 100
% de Invoca¸c˜oes Com Falha: 0 0
N´umero de execu¸c˜oes: 68 39
Tabela 8.5: Resultado da execu¸c˜ao do teste T1 na OpenWhisk da IBM e na local, durante 20 segundos
Figura 8.15: Resultado da execu¸c˜ao do teste T1 na OpenWhisk da IBM e na local, du- rante 20 segundos: M´edia (c´ırculo a laranja), desvio padr˜ao (retˆangulo cinzento) e valores m´aximos e m´ınimos (barra a vermelho) de latˆencia
na OpenWhisk local ´e aproximadamente o dobro da apresentada na plataforma da IBM. Outro dos aspetos a retirar ´e que na instala¸c˜ao local a diferen¸ca entre a latˆencia de di- ferentes invoca¸c˜oes ´e bastante dispersa, uma vez que apresenta um alto valor de desvio padr˜ao. Isto significa que entre diferentes invoca¸c˜oes podemos obter tempos de latˆencia bastante vari´aveis. Uma observa¸c˜ao interessante ´e que em algumas das invoca¸c˜oes con- seguimos obter valores de latˆencia bastante mais baixos na nossa plataforma do que na da IBM. Este facto pode dever-se `as latˆencias ocorridas aquando da execu¸c˜ao da fun¸c˜ao utilizando um hot container. No geral, a degrada¸c˜ao de mem´oria na plataforma local pode dever-se a constante destrui¸c˜ao dos containers, devido aos poucos recursos computacionais que possui, uma vez que a plataforma liberta com frequˆencia os que tem ativos, para que possa ter capacidade dispon´ıvel para responder a poss´ıveis invoca¸c˜oes a outras fun¸c˜oes. Esta a¸c˜ao explica tamb´em o alto desvio padr˜ao j´a abordado.
Numa tentativa de se tentar perceber como a instala¸c˜ao local se comporta em escala, com o aumento da carga concorrente, foi executado o teste T2 nas duas plataformas, seguindo- se exatamente o mesmo processo que o descrito na sub-sec¸c˜ao 8.3. Os resultados do teste, calculados pelo sistema a partir da latˆencia m´edia e do throughput das invoca¸c˜oes realizadas de forma sequencial, num per´ıodo de 20 segundos, para cada valor de carga concorrente, s˜ao apresentados para a instala¸c˜ao local da OpenWhisk na Figura 8.16 e para a da IBM na Figura 8.17.
Figura 8.16: Resultado da execu¸c˜ao do teste T2 na instala¸c˜ao local da OpenWhisk : Th- roughput por segundo e latˆencia m´edia por invoca¸c˜ao em fun¸c˜ao do n´umero de pedidos concorrentes efetuados durante 20 segundos
Figura 8.17: Resultado da execu¸c˜ao do teste T2 na OpenWhisk da IBM: Throughput por segundo e latˆencia m´edia por invoca¸c˜ao em fun¸c˜ao do n´umero de pedidos concorrentes efetuados durante 20 segundos
mostra uma escalabilidade quase linear, em fun¸c˜ao do aumento da concorrˆencia, sendo que a latˆencia m´edia por invoca¸c˜ao tende a baixar `a medida que a concorrˆencia aumenta. Este comportamento ´e explicado pelo facto de quanto for maior o n´ıvel de concorrˆencia, maior ser´a a probabilidade de existir um hot container da fun¸c˜ao ativo, o que permite que o overhead relativo `a utiliza¸c˜ao de um cold container seja eliminado. Relativamente
aos dados relativos `a instala¸c˜ao local, podemos observar um baixo throughput at´e ao n´ıvel de concorrˆencia 8 e um forte aumento nos tempos de latˆencia. Este comportamento pode dever-se ao facto da plataforma lan¸car m´ultiplos novos containers antes de come¸car a reutiliza-los, e desta forma existe em cada uma das invoca¸c˜oes o overhead da cria¸c˜ao dos containers. A partir deste valor de concorrˆencia, o throughput escala de forma bastante r´apida e a latˆencia estabiliza, sendo que para este comportamento contribui a reutiliza¸c˜ao de containers para a realiza¸c˜ao da execu¸c˜ao das fun¸c˜oes. Como j´a foi explicado, a pla- taforma s´o suporta 6 containers ativos, 4 da fun¸c˜ao e dois pr´e criados para a linguagem de programa¸c˜ao. Uma vez que o m´aximo de throughput conseguido foi de 5 respostas por segundo para 14 invoca¸c˜oes concorrentes, pode-se ter atingido o limite da plataforma para este valor de pedidos concorrentes. A diminui¸c˜ao do throughput e o aumento da latˆencia m´edia no n´ıvel 15 de concorrˆencia pode dever-se `a liberta¸c˜ao de containers ativos por parte da plataforma, por esta ter atingido o seu limite, necessitando de ter recursos dispon´ıveis para o caso de ter de executar uma outra fun¸c˜ao.
Como se pode verificar por estes dois testes realizados na instala¸c˜ao local da OpenWhisk, a capacidade computacional que as plataformas de computa¸c˜ao serverless tˆem afeta bastante a performance que podem oferecer. Este efeito ´e bastante vis´ıvel a n´ıvel da reutiliza¸c˜ao de containers, que ´e um mecanismo bastante importante para a obten¸c˜ao de uma melhor performance nestas plataformas.