Understanding Open Source Serverless Platforms: Design Considerations and Performance
Metadane
- Autorzy: Junfeng Li, Sameer G. Kulkarni, K. K. Ramakrishnan, Dan Li
- Rok: 2019
- Źródło: Fifth International Workshop on Serverless Computing (WOSC ‘19), December 9–13, 2019, Davis, CA, USA. ACM.
- DOI: 10.1145/3366623.3368139
- arXiv: 1911.07449
- PDF: https://arxiv.org/pdf/1911.07449v4
- Status: to-read
- Kategoria główna: Systems
- Podkategorie: Serverless Computing, FaaS, Performance, Open Source
- Tagi:
#serverless#faas#performance#open-source#openwhisk#fission#benchmark#throughput#latency#project:js-runtime-energy
Streszczenie
Praca analizuje wydajność kilku popularnych open-source platform serverless (OpenWhisk, Fission, Kubeless, OpenFaaS) i identyfikuje czynniki wpływające na throughput i latencję. Autorzy odkrywają idiosynkrazje każdej platformy i wskazują, że samo resource-based (CPU/memory) lub workload-based (RPS) auto-scaling jest niewystarczające.
Ważna dla kontekstu badań: baseline rozumienia jak różne open-source serverless platforms działają — platformy na których będą testowane JS runtimes.
Kluczowe Wnioski
- Każda platforma serverless ma unikalne idiosynkrazje wpływające na throughput/latencję
- Auto-scaling oparty wyłącznie na CPU/memory lub RPS jest niewystarczający
- Skalowanie musi uwzględniać jednocześnie resource-based i workload-based triggery
- Różnice wydajnościowe między platformami są znaczące (nawet 10× throughput)
- Cold start jest głównym czynnikiem wpływającym na latencję przy niskim ruchu
- OpenWhisk vs Fission vs OpenFaaS — różne architektury, różne trade-offy
Metodologia
- Platformy: OpenWhisk, Fission, Kubeless, OpenFaaS
- Workloady: typowe funkcje HTTP (echo, compute, I/O)
- Metryki: throughput (RPS), latencja (p50, p99), cold start time
- Infrastruktura: własne klastry Kubernetes
- Narzędzia: wrk2 (load generator)
Główne Koncepcje
- OpenWhisk: Apache project — jeden z pierwszych open-source FaaS (używany w IBM Cloud Functions)
- Fission: FaaS na Kubernetes od Platform9 — fokus na szybkim cold start (pre-warmed pools)
- OpenFaaS: popularny open-source FaaS z dużą społecznością
- Auto-scaling: dynamiczne skalowanie liczby instancji funkcji w odpowiedzi na ruch
- Resource-based vs workload-based scaling: CPU/memory thresholds vs RPS thresholds
Wyniki
- OpenWhisk: najdłuższy cold start (~1-2s), ale stabilna wydajność przy warm start
- Fission: najkrótszy cold start (~100ms) dzięki pre-warmed pools
- Różnice wydajnościowe między platformami: 2-10× w throughput przy niskim ruchu
- Wzajemne oddziaływanie auto-scaling mechanizmów powoduje oscylacje
Przydatne Cytaty
“We identify the idiosyncrasies affecting performance (throughput and latency) for different open-source serverless platforms.” (Abstract)
“Just having either resource-based or workload-based auto-scaling is inadequate to address the needs of the serverless platforms.” (Abstract)
Datasety
- Własne eksperymenty na klastrach Kubernetes
Powiązane Tematy
- Cold Start Review (Golec 2024) — kontekst cold start
- Kiener 2021 (intra-function parallelism)
- Kontekst dla benchmarkowania JS runtimeów w open-source FaaS (#JE-1, JE-3)