Tremulant: Latency in Serverless Platforms beyond the 99th Percentile

Tremulant: Latency in Serverless Platforms beyond the 99th Percentile Linus Gustafsson

Trever Schirmer

David Bermbach

TU Berlin Berlin, Germany lig@3s.tu-berlin.de

TU Berlin Berlin, Germany ts@3s.tu-berlin.de

TU Berlin Berlin, Germany db@3s.tu-berlin.de

arXiv:2610.18532v1 [cs.DC] 13 Oct 2026

Function-as-a-Service (FaaS) increases developer productivity by removing operational concerns such as managing hardware and software runtimes. Because function instances are started on demand, some requests must wait for a new instance, called a cold start. These are a common obstacle to more widespread adoption of FaaS, as they lead to unpredictable latency spikes that are not acceptable for some use cases. To solve this, many cold start optimizations have been implemented. However, comparatively little attention has been directed towards the slowest warm starts. With improvements in cold start times, slow warm starts emerge as a new problem for extreme tail events. By analyzing a dataset of several million requests across seven FaaS platforms, we show that the long tail of slow warm starts can be hundreds of times slower than their median performance, while a virtual machine we use as a baseline is substantially more consistent. We confirm this across four independent public datasets spanning 2020 to 2025, so the effect is neither new nor specific to one platform. Moreover, the warm share among the slowest calls starts to rise again at the highest percentiles: the most extreme latencies are not only cold starts, and cold-start mitigation alone cannot remove them.

Keywords serverless, FaaS, warm starts, tail latency, statistical analysis, warm tail

1

Introduction

Function-as-a-Service (FaaS) is a serverless cloud-computing model in which applications are composed of small, event-driven, ideally stateless functions, while operational responsibilities such as provisioning, scaling, and runtime management are handled by the cloud provider. Since FaaS entered mainstream technology stacks, popularized by Amazon Web Services (AWS) Lambda, it has seen significant adoption due to its promise of simplicity: developers can focus primarily on application logic, which can improve iteration speed and productivity [15]. This momentum has prompted other cloud providers to introduce their own FaaS offerings [16, 24]. To extend FaaS to a broader set of latency-sensitive applications, research and engineering efforts increasingly focus on improving latency behavior and, in particular, latency consistency. This is motivated both by user-facing quality requirements and by economics: because execution is commonly billed per invocation and execution duration, latency improvements can directly reduce cost. In practice, two effects contribute strongly to inconsistency. First, requests that require a new function instance to be started before processing (so-called cold starts) can substantially increase end-to-end latency

GCF

1.3

2.6

3.6

6.5

Lambda (X86)

1.3

1.8

3.2

11.9

Lambda (ARM)

1.3

1.8

3.1

12.9

OCF (X86)

1.7

16.2

33.0

119.1

OCF (ARM)

1.8

18.6

35.7

299.3

DD

5.4

5.8

138.5

424.1

CW

1.3

1.8

4.0

26.3

Fly.io

1.4

3.4

16.1

947.5

FEC

2.0

5.0

37.9

113.7

EC2 (Baseline)

1.0

1.2

1.6

3.4

TFp95

TFp99

TFp99.9

TFp99.99

Factor over median (x)

Relative Tail Factors

Abstract

102

101

Tail Latency Threshold

Figure 1: Even when only considering warm starts, the highest latency percentiles are much slower than their median. In our baseline, AWS EC2, the p99 latency is less than 20 % slower than its median. Even at p95, every FaaS platform is further from its own median than EC2 at p99. At p99.99, warm starts are between 6.5 and 947.5 times slower than their median.

[5]. Cold starts have been studied extensively, and many techniques exist to mitigate their impact in a wide range of scenarios [6, 34]. Very slow warm invocations, however, have received less attention in research, even though they alone already exhibit a long latency tail. While cold starts are represented more in the higher latency percentiles than warm starts, they are far rarer than warm starts, and their share drops again at the highest latency percentiles. In Figure 1, we show the slowdown of warm starts at specific percentiles, compared to the platform’s own median. While the p99.99 request latency on our baseline virtual machine is 3.4 × slower than the median request, it is hundreds of times slower on multiple FaaS platforms. Complex serverless applications often comprise multifunction workflows [15], where the probability that at least one tail event occurs increases with every additional function call. In this paper, we identify tail events of warm starts as a crossplatform issue and validate the effect against existing datasets. For

Linus Gustafsson, Trever Schirmer, and David Bermbach

this, we present a reusable method of making heterogeneous serverless traces tail-comparable. We then validate our findings by analyzing existing datasets from other serverless research, demonstrating that these issues have existed for a long time and are not unique to one platform or dataset. We publish all analysis available as open-source software.1 In summary, we make the following contributions: (1) We characterize warm-start latency across seven FaaS platforms and an IaaS baseline. We show that warm invocations can be more than two orders of magnitude slower than their median in the tail. (2) We introduce the warm share as a metric to describe the composition of the slowest calls, and show that warm calls increasingly contribute to the extreme tail. (3) We screen eleven public datasets and reproduce these effects in the four that qualify.

2

Background

FaaS resides at a high abstraction level in the cloud computing spectrum [49]. It abstracts away infrastructure management, runtime provisioning, and scheduling, so users only provide code as a deployment package that the platform loads into a function instance. Although platforms implement it differently, all of them use virtualization technologies to isolate instances from each other [43]. Some newer, edge-oriented platforms use the mechanism provided by the language runtime to isolate functions, e.g., the isolates provided by the JavaScript runtime V8 [8]. Other platforms use lower-level mechanisms, e.g., containers [45] or microVMs [1]. The isolation mechanisms influence the overhead of a cold start and the resource configurability options a user is provided with. Function Lifecycle. The cost-efficiency of FaaS is enabled by an execution model in which a function instance is started only when a request arrives. At a high level, this model results in two common invocation paths that behave similarly across many FaaS platforms. First, if no function instance is available to serve an incoming request (either because no instance exists or all are busy handling requests), the platform must create and initialize a new instance. This process is commonly referred to as a cold start [34]. Depending on the underlying virtualization technology, cold starts can consume substantial compute resources and add disproportionate latency because the platform must create a virtual environment and initialize the language runtime and dependencies [14, 31]. Therefore, cold starts are frequently associated with tail-latency events and can substantially degrade platform performance [6]. Moreover, because billing is often tied to metered execution duration and initialization of the environment is considered part of the execution, cold starts can substantially increase cost [14]. Second, if an instance is available, the platform can route the request to it, avoiding the overhead of a cold start. Such invocations are commonly referred to as warm starts [49]. To increase the likelihood of warm starts, many FaaS platforms keep instances alive for some time after request processing instead of terminating them

1 https://github.com/3s-rg-codes/warm-tail-analysis

immediately [38]. Platforms terminate instances when demand subsides to save cost and resources, as users are typically not billed for this keep-alive period. As increasingly complex use cases are implemented on FaaS platforms, applications often consist of multiple functions with explicit dependencies [15]. Such multi-function workflows are frequently coordinated through event-based processing and orchestration [6].

3

Related Work

FaaS platforms have attracted substantial research interest across benchmarking methodology, cold-start mitigation, and tail latency analysis; yet, as we discuss below, warm-start behavior at extreme latency percentiles remains largely unexplored. One major area of interest has been understanding the proprietary architectures and technologies underlying commercial FaaS platforms. In particular, several efforts introduce tools that simplify benchmarking by automating deployment and experimental workflows. A prominent subcategory of these tools focuses on exposing FaaS platforms to realistic workloads to assess the applicability of the paradigm to business use cases. For example, Grambow et al. [22], Kim and Lee [28], Yu et al. [52] propose such frameworks. Conversely, Copik et al. [9] contribute a suite of automated microbenchmarks that characterize isolated aspects of FaaS platforms, such as cold-start behavior and latency variability, alongside more complex workloads for assessing cost efficiency and invocation overhead. Although these frameworks primarily target end-to-end analysis and general platform performance, complementary work addresses more specific capabilities. Scheuner et al. [39] focus on tracing by integrating their benchmarking framework with platform-specific tracing tools. Kuhlenkamp et al. [29] investigate platform elasticity by generating diverse load patterns across phases and correlating these phases with distinct performance modes across four platforms. In practice, most benchmarking frameworks cover only a small subset of FaaS platforms; the most frequently studied are Google Cloud Functions, AWS Lambda, and Azure [40]. In particular, modern edge FaaS platforms such as Cloudflare Workers (CW) [8], Deno Deploy (DD) [12], and Fastly Edge Compute (FEC) [17] remain underrepresented in research [40, 43]. Other work has focused specifically on minimizing the impact of cold starts on overall platform performance. Two primary strategies have been pursued: (i) reducing the duration of individual cold starts [13, 31], and (ii) reducing their frequency [48]. For the former, both academic and industry research has sought to lower the overhead of virtualization technologies while preserving the strong function isolation required for security guarantees [2, 4, 36]. A notable contribution is Firecracker, developed by AWS and subsequently open-sourced by Agache et al. [1]. For the latter, researchers have explored the inherent dependencies between functions and proposed optimization strategies such as merging multiple functions into a single deployment [42] or predicting function invocations to pre-warm instances before requests arrive [6]. By contrast, warm-start tail latency has received comparatively little attention. This gap reflects a prevalent assumption in the literature: that long tails in FaaS platforms are largely attributable

Tremulant

Table 1: The platforms and configurations present in the primary dataset by Schirmer et al. [43]. Reg. (✓) marks regional platforms, where users pick a deployment region; ✗ marks worldwide platforms, which replicate deployments and route requests to a nearby location. The last two columns give the number of warm calls at or beyond p99.99. † Regional configuration is also possible. ‡ A second version was released in 2024. § FEC reports every invocation as a cold start (see §4), so its count covers all calls. Warm calls at p99.99 Platform

Reg. Memory

ARM

x86

AWS Lambda [3] Cloudflare Workers (CW) [8] Deno Deploy (DD) [12] Fastly Edge Compute (FEC) [17] Fly.io† [18] Google Cloud Run Functions (GCF)‡ [21] Oracle Cloud Infrastructure Functions (OCF) [37]

✓ ✗ ✗ ✗ ✗ ✓

128/512/1024 MB not configurable not configurable not configurable 256/512/1024 MiB 128/512/1024 MiB

192

– –

187 192

✓

128/512/1024 MB

189

185

162 28 29 64§

to cold starts. While this assumption has motivated extensive coldstart research, it has left the tail behavior of the warm path, the dominant operating mode in production deployments [26, 27, 43], underexplored. Moreover, tail latency is commonly characterized only at the 99th percentile, leaving the remaining 1 % of invocations unexamined. We argue that this portion has a significant impact on observed performance, even when cold starts are excluded. For instance, although Ustiugov et al. [46] analyze FaaS platforms with a focus on tail latencies, providing insight into their causes and effects, they only consider data up to the 99th percentile. The study of extreme tail latencies has received more attention in adjacent fields, such as IaaS deployments and OS-level performance analysis. In these contexts, latency beyond the 99th percentile is sometimes considered, yielding a more complete picture of how tail shape influences system-level performance [30]. Dean and Barroso [11] show that even rare high-latency events in the top 1 % of requests can have a significant cumulative performance impact when considered at scale, e.g., in large datacenters. Xu et al. [51] examine the causes and effects of tail latencies in IaaS environments, finding that virtualization exacerbates long-tail behavior by factors of two to four. Hao et al. [23] address the problem at the OS level, showing how I/O scheduling can be adapted to limit the impact of tail latency events on application-level performance.

4

Analyzing Tail Latency Events

In this paper, we analyze an existing dataset comprising millions of calls to seven different FaaS platforms [43]. The seven platforms are commercial FaaS platforms that are well documented, are not built on top of another FaaS platform, and do not use the default Kubernetes scheduler, which has been shown to have limited performance in FaaS implementations [10]. Table 1 shows all platforms, their abbreviation used in this paper, and the respective function resource configurations present in the dataset. While previous work based on this dataset focused on understanding the architecture of the platforms and its impact on overall performance, this paper focuses on warm tail latency events as a subset of the gathered data.

Execution. In the primary dataset by Schirmer et al. [43], platform performance is measured by repeatedly executing a minimal FaaS function on each platform. The functions are empty functions that immediately return. For each request (i) the function start time, and (ii) whether the request was served by a cold instance are recorded. To detect a cold start, the functions use a global variable that is written during the first request. The experiment is executed over an extended period to reduce bias from diurnal, weekly, and seasonal workload shifts that are common on FaaS platforms [41]. Moreover, the dataset’s extended experimental duration2 makes it particularly suitable for analyzing tail latency events: The long timeframe yields a sufficiently large sample size, which is essential for reliably capturing and studying such inherently rare occurrences. Additionally, due to the minimalist function setup that excludes outside influences, no tail events can be caused by user code, leaving the platform and network path as the only possible sources. Functions are called with an inter-arrival time of 3 s for 1 min, repeated every 5 min. Because requests arrive continuously within each iteration, and iterations are close together, this setup increases the likelihood of observing warm starts. IaaS Baseline. To contextualize tail latencies observed in the dataset, we adopt the approach of Copik et al. [9] and run the same warm start workload on a virtual machine (VM). In contrast to FaaS, a request to an IaaS deployment does not require a platformmanaged control plane or router. Consequently, the request path is substantially shorter, avoiding potential sources of additional latency. In our experiments, the VM thus serves as a reference point for the level of consistency that a minimal IaaS instance can achieve. We use the smallest possible AWS EC2 instance type (t3.nano), start it in the same region that the functions were deployed in, serve the same code from a Node.js HTTP server, and put it under the same load as the functions for 11 days.3 Although t3.nano instances have burstable CPU performance, we do not expect CPU credit exhaustion or resource contention to affect the measured latencies, since the request pattern, as in the primary dataset [43], imposes only a very low load. While the baseline experiment ran after the data collection period of the primary dataset, we argue that the effect size we identify is too large to be caused by seasonal differences. Metrics. Our analysis of tail latency relies on three core metrics: The first metric is the latency percentile. Although the 95th (p95) and 99th (p99) percentiles are the standard measures for characterizing tail behavior, higher percentiles have received comparatively little attention in the context of FaaS platforms. To characterize the extreme tail in our measurements, we additionally report p99.9 and p99.99, following the “9s”-pattern. Latency is measured as TimeTo-First-Byte (TTFB), defined as the elapsed time until the client receives the first byte of the server response. Rather than anchoring tail events to a single fixed percentile, we examine how the full range of percentiles collectively characterizes platform performance.

2 The experiments by Schirmer et al. [43] were conducted over 53 days, 2025-11-13 to

2026-01-05. 3 The IaaS baseline experiments were conducted from 2026-04-16 to 2026-04-27.

Linus Gustafsson, Trever Schirmer, and David Bermbach

p95 103

Percentile p99 p99.9

p99.99

Lambda (X86)

Lambda (ARM)

OCF (X86)

OCF (ARM)

GCF

CW

DD

FEC

Fly.io

EC2 (Baseline)

Tail Factor (TF)

102 101 100 103 102 101 100

0

12

0

12

0

12

0

12

0

12

Hour of day Figure 2: The tail factor TF𝑝 ∗ for p95, p99, p99.9, and p99.99 across all platforms. Generally, there is a pronounced divergence between p99.99 and the other evaluated percentiles, underscoring the importance of examining these extreme latencies to fully understand platform performance. OCF, FEC, Fly.io, CW, and DD demonstrate inconsistent tail performance throughout the day, whereas Lambda and GCF exhibit more stable behavior disrupted by isolated spikes, as indicated by the vertical lines. Furthermore, AWS EC2 and GCF show substantially lower relative tail latencies compared to the other FaaS platforms. Notably, the EC2 baseline exhibits the lowest overall relative tail latencies and the highest consistency. The second metric is the tail factor (TF𝑝 ∗ ), defined as the ratio of an arbitrary latency percentile 𝑝 ∗ to the median (p50): TF𝑝 ∗ =

latency𝑝 ∗ latency𝑝50

We use this metric as we are largely interested in tail performance in relation to the median performance of a platform, as it makes the platforms comparable. This gives an intuitive understanding of how much worse the tail is compared to the expected median behavior. TF𝑝 ∗ and latency percentiles are always calculated using only warm starts. The only exception is FEC, which reports every invocation as a cold start because global state does not persist between its invocations; for FEC, we therefore use all calls. The third metric is the warm share (WS𝑝 ∗ ). Unlike the previous two metrics, it describes the composition of the slowest calls. For a latency percentile, it reports what fraction of requests in this percentile were warm starts: WS𝑝 ∗ =

𝑛 warm ≥𝑝 ∗ 𝑛 ≥𝑝 ∗

A WS above 50 % means that the majority of the slowest requests at or above this percentile were warm starts. The absolute values can only compare composition within platforms, as the platforms have different base rates of cold requests. To make them comparable, we additionally report the overall rate of cold starts per dataset.

5

Tail Latency Across Seven Platforms

We find that warm start tail latency behavior decreases platform performance substantially. Calls in percentiles that are rarely considered when evaluating FaaS platforms can be up to 947.5 × slower than the median. Moreover, for most platforms the highest latencies are not just caused by cold starts but also by warm starts.

Tail Severity Across Platforms. Tail latency often worsens nonlinearly, and a few extreme outliers (which are often disregarded) dominate the very end of the distribution. In the dataset, we observe a recurring pattern, which is visualized in Figure 1. Latencies in p95 and p99 are often similar, even though the interval between them spans 4 % of calls, expressing a denser latency distribution in that range. However, the tail then steepens, with a jump at p99.9 (0.9 % of calls) and another large jump at p99.99 (0.09 %). Across every platform, as well as on the IaaS baseline, the step from p99.9 to p99.99 is the largest single absolute increase in TF. This pattern holds for all platforms except FEC and OCF, which exhibit wide and relatively evenly spaced latency distributions even above the 95th percentile. For instance, DD exhibits a TF𝑝95 of 5.43 and a TF𝑝99 of 5.85, but strongly increased TF𝑝99.9 and TF𝑝99.99 values of 138.46 and 424.05, respectively. That is, p95 and p99 are closely clustered, but p99.9 and p99.99 are more spread out and show a strong increase. Consequently, the true extent of the tail

AWS (ARM) OCF (X86)

99 .99 10 0

82.5

GCF AWS (X86)

99 .9

100 80 60 100 75 40 50 25 20 0 0 80.0

99 .7

Warm starts among slowest calls (%)

Tremulant

85.0

87.5

90.0

OCF (ARM) DD

Percentile (%)

92.5

CW Fly.io

95.0

97.5

100.0

Figure 3: Warm start percentage of all calls in a latency percentile. At p80, most calls are warm starts for every provider shown. As expected, the rate generally drops in the higher percentiles, as cold starts usually take longer. The warm share then starts rising beyond its minimum on every platform except for GCF, which stays comparatively close to 100 % throughout. At p99.99, more than 50 % of calls are warm starts on five out of six platforms. The effect is very clear on DD: WS is >90 % at p80, reaches its minimum of ∼50 % around p99, and rises to ∼75 % at p99.5 before easing off again in the extreme tail. This shows that the extreme tail does not just belong to cold starts. The per-provider lines end when <30 data points remain. FEC is excluded from this figure, since all calls above p80 are cold starts.

ECDF

GCF OCF (ARM) FEC 1.00

Lambda (x86) DD EC2 (Baseline)

Lambda (ARM) CW

OCF (x86) Fly.io

0.98 0.96 100

101

102

103

Latency (ms)

104

105

Figure 4: ECDF showing absolute latency values above the 95th percentile for all providers. While CW, Fly.io and FEC have requests that complete faster than the baseline VM running on AWS EC2, it has a denser distribution and hence more consistent performance than all FaaS platforms with a TF𝑝99.99 of 3.4. The FaaS platforms lie between 6.5 and 947.5.

and its impact often only become visible when observing values above p99. This characterizes a long, heavy tail, which is most visible beyond the 99th percentile. Such tails have a disproportionate impact on overall platform performance. For instance, when disregarding values above the 99th percentile for DD, we observe improvements of the distribution’s mean of up to 33 % in comparison to the mean of the full distribution. Moreover, when disregarding the 99.99th percentile for Fly.io, removing just 0.01 %, the mean improves by 13 %. Comparison to the IaaS Baseline. Although the severity of tail distributions varies across observed FaaS platforms, all of them exhibit heavy tails. In particular, Figure 4 visualizes that absolute

latency values of FaaS platforms span one order of magnitude at p95, but at p99.9 they already span close to two orders of magnitude, with latencies reaching up to approximately 1500 ms for OCF. Contrarily, the latency distribution of the IaaS baseline (AWS EC2 t3.nano) is substantially denser with tail latencies that are only marginally higher than the median. Even above the 99.5th percentile, where all observed FaaS platforms experience strong performance degradation, latencies only slightly increase for the EC2 instance (see Figures 1 and 4). For instance, the TF𝑝99.99 for the AWS EC2 instance is 3.4, while it is between 6.5 and 947.5 for the FaaS platforms. In absolute values that means p99.99 is ≈ 100 ms for the IaaS baseline and ≈ 6514 ms for Fly.io as the worst performing FaaS platform in that regard. Notably, the fastest requests from FEC, Fly.io, and CW outperform the IaaS baseline. However, these platforms ultimately exhibit inferior performance at higher percentiles. This early performance advantage is likely attributable to their deployment close to the benchmarking client, decreasing networking overhead.

Diurnal Variation at p99.99. Although Figure 2 shows that p95, p99, and p99.9 differ considerably across platforms, their percentiles are largely stable diurnally within each platform. However, p99.99 exhibits substantial diurnal variance. For instance, GCF, Fly.io, and Lambda exhibit isolated but substantial latency spikes or dips at p99.99, while lower percentiles remain largely unaffected. For OCF, CW, FEC, and DD, p99.99 (and partially p99.9) also shows unstable behavior, but events are less isolated and generally span longer periods of instability. Although the IaaS baseline also shows isolated p99.99 spikes, their magnitude is less pronounced and hence aligns with the overall observed performance. Particularly, Figure 2 visualizes that the p99.99 latency spikes for the IaaS baseline are up to two orders of magnitude lower than those of OCF, DD, and Fly.io.

Linus Gustafsson, Trever Schirmer, and David Bermbach

Warm Share. Figure 3 shows what share of a latency percentile comprises warm starts. Because the platforms cold-start at very different rates, these shares are only comparable across platforms once that base rate is known: over the whole experiment, 0.01 % of GCF calls are cold, 0.2 % on both AWS configurations, 1.2 % on DD, 1.5 % on OCF ARM, 2.2 % on Fly.io, 3.6 % on OCF x86 and 6.0 % on CW, while FEC reports every call as cold. While the warm share consistently drops above p80, it starts rising again on almost all platforms. For DD, it starts rising again just above p99, but then drops off in the extreme tail. For all other platforms, the warm share starts increasing again eventually. Even for GCF, where almost all calls are warm, the warm share starts increasing after p99.99. At p99.9, six out of nine configurations are dominated by cold starts, i.e., WS ≤ 50 %. Past p99.99, the tail is dominated by warm starts for all platforms except OCF x86 and FEC, where virtually every call is a cold start. While the lines in Figure 3 stop when fewer than 30 data points remain, the number of observations differs per platform. At p99.9, they range from 297 on DD and CW to 1919 on GCF and AWS ARM. At p99.95, they range from 148 to 960.

6

Validation with Existing Datasets

As a next step, we analyze existing research datasets for the effects we have observed, focusing on (i) the tail factor, (ii) the warm share, and (iii) diurnal variations. This serves two purposes: First, it rules out that these effects are an artifact of the data or testing methodology. Second, it improves the understanding of which platforms exhibit these effects and for how long they have existed.

6.1

Methodology

We make heterogeneous traces tail-comparable in four steps. We show the resulting included and excluded datasets in Table 2. To be included, a dataset needs to contain per-request latency values and indicate whether a request is cold or warm. Because the experiments were designed to evaluate different aspects of FaaS platforms, many experiments do not use empty functions like in the primary dataset. As differing code execution time would invalidate comparability of results, the datasets must contain information that can be used to isolate platform performance. For instance, client request latency (RTT) as well as code execution time are measured for most datasets, which allows subtraction of the two to isolate platform overhead. This makes the datasets tail-comparable. An exception to this is the dataset of Joosen et al. [27], which records frontend RTT instead

Lambda20

1.9

3.8

6.1

18.4

Lambda20

2.1

4.3

478.9 504.2

GCF20

108.5 233.8 269.5 336.5

GCF23

9.8

11.9

19.7

28.9

Azure20

1.5

1.6

1.6

1.6

IBM20

1.8

2.4

3.8

5.7

102

Tail Factor (TF)

Beyond the 99.99th percentile, an examination of the absolute maximum latency per platform provides further insight into the upper bounds of invocation delays. However, since an absolute maximum represents a single isolated outlier, it lacks the statistical robustness of the p99.99 metric, which aggregates between 28 and 192 calls depending on the platform and architecture (Table 1), and should be interpreted as a rare worst-case event rather than a stable performance indicator. Fly.io exhibits the highest relative delay with a TF𝑝100 of approximately 6149, corresponding to an absolute latency of 42 s. DD and CW follow with TF𝑝100 values of roughly 4240 and 712, respectively; FEC is omitted, as it has no warm starts. Interestingly, GCF shows the lowest TF𝑝100 at 631, an absolute maximum latency of approximately 27 s.

101

TFp95 TFp99 TFp99.9 TFp99.99

Percentile

Figure 5: TF for all platforms included in the validation datasets. Overall, the results demonstrate that tail effects extend beyond the platforms analyzed in the primary dataset. Furthermore, comparing GCF23 and GCF20 to the primary dataset reveals substantial increases, which are likely attributable to differences in platform versions. Lambda is the only platform that also appears in the primary dataset. Lambda20𝛽 and Lambda20𝛼 use the same platform. Their differing TF values show that the effect varies depending on load patterns. The Azure results should be interpreted with caution, as Kuhlenkamp et al. [29] report an error rate exceeding 95 %.

of the client RTT used by all other datasets. Due to this, the tailcomparability of Joosen et al. [27] is limited. Huawei25 is the only included dataset that does not annotate cold starts explicitly; there, we treat the first request on a given podID as cold and every later request on that pod as warm. Finally, where a dataset ships two disagreeing encodings, we use the platform-reported one rather than the derived one: CNew for Kuhlenkamp et al. [29] and isCold for GCF23. As mentioned in §4, WS is influenced not only by the severity of cold starts but also by their frequency, and hence strongly depends on load patterns. In the existing datasets, the base cold start rate varies from <0.1 % to >50 %.

6.2

Results

The analysis of existing datasets provides strong evidence that the effects identified in the primary dataset are not unique. While their magnitude varies across platforms and datasets, tail-latency amplification and warm-tail behavior can be observed consistently throughout the analyzed literature (Table 2). AWS Lambda. Lambda appears in the primary dataset as well as in Lambda20𝛼 and Lambda20𝛽 both from 2020 and using x86 processors. The results show strong variations across datasets. Lambda20𝛼 indicates similar performance for AWS as in the primary dataset,

Tremulant

Table 2: Datasets used to validate the findings of the primary dataset, and the tail factor and warm share observed in each. We include a dataset if its per-request records contain both the request latency and whether the request was a cold start. Huawei25 does not annotate cold starts explicitly, but it can be inferred from the podID. We screened and excluded seven additional datasets, which do not provide this information [20, 26, 33, 35, 44, 47, 53]. We count a dataset as showing a large tail factor if relative increases between percentiles are exponential or TF𝑝95 > 20, and as showing a warm-share rebound if WS rises again after its minimum above p80, indicating a higher relative occurrence of slow warm starts. We refer to the datasets by the short forms defined in this table.

† Azure20 has a request failure rate of >95 %, limiting validity for Azure. ‡ These datasets use Google Cloud Functions, while the primary dataset uses the successor

Google Cloud Run functions. § Their functions are computationally complex, so we exclude execution duration from our analysis.

Dataset

Abbreviation

Tail Factor

Warm-Share Rebound

Kuhlenkamp et al. [29]

Lambda20𝛽

Mahmoudi and Khazaei [32]

Lambda20𝛼

Kuhlenkamp et al. [29] Kuhlenkamp et al. [29]

Azure20 GCF20

Schirmer et al. [41]

GCF23

Huawei

Joosen et al. [27]

Huawei25§

IBM Cloud Functions

Kuhlenkamp et al. [29]

IBM20

Yes, much higher than in the primary dataset. Yes, higher than in the primary dataset. No† Yes, much higher than in the primary dataset. Yes, higher than in the primary dataset. Yes/ No, strongly depends on resource configuration. No, but lower relative factor caused by high median latency.

Yes, from 35.9 % at p99.05 to 87.5 % at p99.9 Yes, slightly, from 83 % at p99.9 to 98 % at p99.95 No† Yes, slightly, from 90 % at p99.75 to 97.8 % at p99.95 No, 0.0 % warm from p80 to p99.9 No, cold starts are at most 5.7 % of the tail Yes, from 46.6 % at p99.7 to 66 % at p99.95

100 80 60 100 75 40 50 25 20 0 0 80.0

Lambda20α Lambda20β

99 .7

Warm starts among slowest calls (%)

Azure† GCF‡

82.5

85.0

87.5

GCF20 Azure20

IBM20 Huawei25

90.0

92.5

99 .99 10 0

AWS Lambda

99 .9

Platform

Percentile (%)

95.0

97.5

100.0

Figure 6: Warm share WS of latency percentiles in the validation datasets, analogous to Figure 3. This figure excludes GCF23, where all calls above p80 are cold. Otherwise, most datasets almost completely comprise warm starts. For the datasets that have a meaningful cold start percentage, the WS starts to increase at p99.05 for Lambda20𝛽 and p99.7 for IBM20. except for a stronger increase of TF𝑝99.99 in the former (see Figures 1 and 5). Lambda20𝛽 shows a median of 29 ms with a p99.99 of 14 623 ms, while in Lambda20𝛼 the median is 92 ms with a p99.99 of 1703 ms, resulting in a strong difference in TF𝑝99.99 for the two datasets. This can be attributed to a difference in the respective experiment setups: While in Lambda20𝛼 the platform is exposed to a relatively constant load, it is deliberately tested for elasticity in Lambda20𝛽 , leading to differences in cold start frequency. For diurnal variability, Lambda20𝛼 shows similar effects to those in the primary dataset. That is, although the platform is generally stable with tightly clustered tail percentiles, it shows isolated spikes at

4 pm, 8 pm, and 10 pm (cf. Figure 7). Additionally, p95 and p99 show consistent, bimodal performance with an increase during the night. The warm share falls to 35.9 % warm at p99.05 in Lambda20𝛽 , the lowest minimum of any validation dataset shown in Figure 6. It then climbs back up to 87.5 % at p99.9 (96 calls). Over the whole dataset, 1.63 % of calls are cold. In Lambda20𝛼 , which has a lower overall cold rate of 0.13 %, the WS is >95 % until p99, then decreases to 83 %, and then increases to ∼98 % at p99.95. Azure Functions. Azure20 shows the data for the benchmark by Kuhlenkamp et al. [29] in 2020. They note that >95 % of their requests failed, limiting the usefulness of analyzing tail events. Their warm share, shown in Figure 6, is 91 % to 100 % throughout

Linus Gustafsson, Trever Schirmer, and David Bermbach

p95

p99

p99.9

less pronounced TF values than GCF20, which exhibits a TF𝑝99 that is already above 100. That is, v1 shows p99.99 latencies as high as 28 000 ms while v2 shows a p99.99 of only 275 ms. The warm share for GCF20 is high throughout the experiment, dropping to ∼90 % at p99.75 before rising to >97 %. GCF23, however, has different behavior: the WS is 0.0 % warm from p80 to p99.9, a clear separation of cold and warm starts. The datasets have very different baseline rates: 1.2 % for GCF20 and 52.7 % for GCF23, which can be attributed to differences in workloads. Diurnal variability is consistent in GCF23, with the exception for an isolated spike at 7am. Notably, the relative increases over the median are higher overall than in the primary dataset. Due to the strong diurnal consistency, the hourly TF values shown in Figure 7 can also be seen in Figure 5. Overall, the results for Google Cloud Functions v1 are not as relevant for future research, as it has since been replaced.

p99.99

Lambda20α

102 101

Tail Factor (TF)

100

GCF23

103 102 101 100

Huawei25 104 102 100

0

4

8

12

Hour of day

16

20

Figure 7: Tail factor TF𝑝 ∗ over the course of a day, analogous to Figure 2. Performance consistency varies strongly across platforms, with TF𝑝99.99 peaking at 53 for Lambda20𝛼 , 146 for GCF23, and 41 317 for Huawei25. In particular, GCF23 shows consistent, although increased latencies while the primary dataset and Lambda20𝛼 show generally low latencies. Huawei25 only contains relative timestamps; hence, their time is relative to the experiment start. Huawei25 and Lambda20𝛼 stem from a single day, increasing the probability of higher variance or the dominance of performance by an isolated event. The datasets from Kuhlenkamp et al. [29] could not be analyzed for diurnal performance as the experiments did not run for long enough.

p80—p100, but the sample size is very small: 32 calls at p99 and 4 at p99.9. Google Cloud Functions. Google Cloud Functions v1 was analyzed in GCF23 in 2023 and GCF20 in 2020. It is a predecessor to Google Cloud Run Functions (also referred to as Google Cloud Functions v2), which is used in the primary dataset. Both GCF20 and GCF23 show that the older version is less stable, indicated by strong increases in all calculated TF values compared to the primary dataset, as visualized in Figure 5. Distinctly, GCF23 shows

Huawei FunctionGraph. Huawei uses its own serverless platform running on top of Kubernetes [7]. As Huawei25 is taken from a production environment in 2025, performance across functions and function configurations varies strongly (see Figure 8). Huawei25 is the only dataset that exhibits substantial differences between configurations that are non-negligible in the tail percentiles. In particular, the most popular resource size (1000 mc / 1024 MB) has a TF𝑝99.99 of 59 514, which maps to an absolute platform delay of 62.1 s with a median of only 1.0 ms.4 The 2600 mc / 3072 MB configuration is more extreme still: on a comparable median of 2.7 ms, degradation sets in far earlier, with a TF𝑝95 of already 10 789 and a TF𝑝99.99 of 39 806, i.e. an absolute platform delay of 108.9 s. At the other extreme, the 25800 mc / 32768 MB configuration has the highest median of all configurations (47.3 ms) and by far the flattest tail, with a TF𝑝99.99 of only 5.6. Cold starts make up 0.37 % of calls at p95, which rises to 5.6 % at p99.95. This is an over-representation by a factor of 266 × relative to their overall rate of 0.021 %, but at the same time only a small part of the tail. Moreover, diurnal variability is pronounced in Huawei25 with a wide spread between observed percentiles. In particular, the 99.99th percentile spans more than one order of magnitude over the course of a day. The percentiles are, however, not bound to each other: p95 and p99 peak late in the day (7.0 and 57.3 at 11 pm), whereas p99.99 peaks at 8 am (41 317) and p99.9 at 9 pm (4887). IBM Cloud Functions. IBM Cloud Functions was analyzed in IBM20 and used Apache OpenWhisk as the underlying platform, but was deprecated in 2023 [25]. Although the low TF visualized in Figure 5 indicates stable platform performance, this reflects generally high latencies. For instance, the TF𝑝99.99 of 5.6 maps to an absolute platform latency of 19.7 s, which implies a median latency of 3.51 s. The WS in IBM20 declines from ∼80 % at p95 to ∼47 % at p99.7, indicating that cold starts are the majority of calls at this percentile. At even higher percentiles, however, the warm share increases again: it is ∼51 % at p99.9 (99 calls) and 66 % at p99.95 (50 calls). 4 Notably, latency is measured as frontend RTT and not client RTT and hence does not

contain network delays.

Tremulant

104

Tail Factor (TF)

300mc / 128MB 2.3 19.4 313 2578 400mc / 256MB 3.2 25.0 561 1891 600mc / 512MB 2.1 3.6 1737 5565 800mc / 768MB 1.5 1.9 3.6 722 1000mc / 1024MB 2.2 6.3 1819 59514 1400mc / 1536MB 2.2 3.0 37.2 162 1800mc / 2048MB 2.5 5.2 10.7 435 2600mc / 3072MB 10789 19677 31538 39806 3400mc / 4096MB 2.8 10.6 518 1584 6600mc / 8192MB 2.1 2.9 4.5 261 25800mc / 32768MB 1.9 2.4 3.5 5.6 TFp95 TFp99 TFp99.9 TFp99.99

103 102 101

Percentile

Figure 8: The equivalent of Figure 1, detailing the TF for the various function configurations evaluated in Huawei25. CPU resources are expressed in millicores (mc) and memory in MB. Configurations with fewer than 1000 calls are omitted. Platform performance varies substantially across configurations, with the most popular setup, by number of calls, (1000 mc / 1024 MB) exhibiting the highest TF𝑝99.99 . This indicates that, in contrast to the other analyzed platforms, function configuration can also play a crucial role in shaping the distribution tail. Some resource configurations have a very high median, leading to lower TF even though absolute values are comparable to other configurations (cf. §6.2).

Again, the results are not as relevant for future research, as the platform is no longer available. Summary. Overall, we see a clear indication that the same observations from our dataset also exist elsewhere. We found the same tail latency issues in older datasets from platforms that are in the primary dataset, and we see similar results for other platforms as well. We argue that this makes it unlikely that the effect is an artifact of the primary benchmarking framework. Thus, the long warm tail of serverless requests is a widespread issue for multiple platforms and has existed for a long time.

7

Discussion & Future Work

In our evaluation, we find that FaaS platforms generally exhibit strong performance variability, as evidenced by heavy distribution tails. As previous research has shown, this variability is partially caused by cold starts. However, we show that warm starts also contribute to the extreme tail. Although platforms exhibit this deterioration to varying degrees, all platforms perform considerably worse than a comparable IaaS deployment. In particular, we observe this in the primary dataset and validate it through analysis of additional datasets from different years and across various platforms. Awareness Gap. The strongest relative performance deterioration occurs in the highest percentiles. These ranges are frequently

dismissed as insignificant outliers or unrepresentative of overall platform performance. However, we find that this is a misconception, especially for FaaS platforms, since the very heavy upper distribution tails substantially influence overall performance. Such performance impacts become even more significant when analyzing the most common applications of FaaS: Eismann et al. [15] find that the largest fraction of FaaS applications are web services, which means that users are directly affected by decreased performance. Especially in online retail, this can affect profits, with a 10 % increase in website loading times already leading to a 4.2 % decrease in total sales [19]. Workflow Effect. Furthermore, beyond the direct impact on end users, tail latencies introduce systemic performance issues due to the compositional nature of common FaaS workloads. Because individual FaaS functions are typically small and contain little logic to improve reusability, applications frequently rely on workflows of multiple function invocations to fulfill a single client request [6]. Consistent with this, Eismann et al. [15] find that 59 % of FaaS workflows contain 2–10 functions, 19 % contain 10–1000 functions, and 3 % contain 1000 functions or more. Consequently, when an application requires many function calls to complete a task, the probability of experiencing at least one tail latency event naturally increases. This amplification follows from the union bound, where repeated trials increase the chance of observing at least one rare event [11]. Under an independence assumption, if a single call exceeds a latency threshold with probability 𝑝, then a workflow with 𝑛 calls exceeds it at least once with probability 1 − (1 − 𝑝)𝑛 . For small 𝑝, this probability grows approximately linearly with workflow length (i.e., 1 − (1 − 𝑝)𝑛 ≈ 𝑛𝑝). Because independence is not guaranteed in practice, this is an upper bound. Warm-Start Tails as a New Problem. For an individual request, being a cold start leads to higher latency: In Huawei25, a cold start is 266 × more likely to be in p99.95 compared to all calls. When cold starts are this rare, warm invocations still make up the majority of the extreme tail. Even when observing only warm starts, p99.9 and p99.99 still introduce substantial deterioration to overall platform performance (Figures 1 and 5). Cold start mitigations cannot address these kinds of tail events at all. Because the warm-start tail events we observed (i) follow diurnal patterns (see Figure 2) and (ii) occur even for empty functions, we attribute them to platform overhead, such as control-plane behavior and request routing. For example, Lambda and GCF exhibit strong performance deterioration around 10–12 am and 3 am UTC respectively. We hypothesize that this is caused by an increased platform-wide load, which leads not only to cold starts but also to warm requests slowing down. Warm-Tail Impact Across Platforms. Warm-tail impact differs markedly between platforms. For Lambda, CW, and GCF, platforms that host a large share of the public web [50], p95 to p99.9 are very consistent, and degradation occurs only occasionally at p99.99 or is generally low. This relative stability likely reflects operational maturity at scale and makes these platforms more attractive from a tail-latency viewpoint. Nevertheless, even the most stable FaaS platforms still underperform considerably when compared to a traditional IaaS deployment (see Figure 4). Even if cold starts were theoretically eliminated (e.g., in a workload where functions are

Linus Gustafsson, Trever Schirmer, and David Bermbach

constantly in use), even the best among the analyzed FaaS platforms cannot compete with the consistency of a comparable IaaS deployment. Applicability for Low-Latency Workloads. However, FaaS should also be analyzed in the context of its use cases. In particular, the paradigm is not designed to promise low-latency code execution and request processing. Its design principles follow the promise of simplicity and low operational overhead on the user’s side, as well as virtually infinite scalability [15]. Although latency plays a significant role in the latter, and platforms work to improve elasticity (e.g., through new virtualization technologies), it is not the main focus. Nevertheless, it is important for users and researchers to be aware of the impact that warm tail events can have, so as not to disregard warm starts as sources of substantial latency increases. Additionally, it is important to highlight that our analysis is designed to examine tail events, which requires isolating them. We did so by evaluating empty functions from the primary dataset or calculating platform delay in the additional datasets. However, in real-world use cases, functions are not empty, and longer runtimes decrease the relative impact of both warm tail events and cold starts. That is, users will experience lower relative tail latencies due to running actual workloads. However, a recent serverless workload characterization reports that 82 % of applications and 96 % of invocations exhibit average execution times below one second [35]. Consequently, even modest warm-start tail overheads can account for a significant fraction of total execution time in many real-world deployments. Mitigating Warm-Start Tails. Future work could explore mitigation strategies that reduce the user-visible impact of rare warm-start tail events. Mitigation is primarily the responsibility of platform operators, who can leverage occurrence patterns to identify and reduce platform variability. On the client side, mitigation could be implemented by detecting unusually slow requests that are expected to be warm starts, e.g., because the function was invoked recently, and retrying them, which would avoid long waiting times for the longest tail. The difficulty is in detecting whether a long in-flight request will be served by a warm or cold instance, since cancelling a cold start would lead to worse overall performance. This approach does, however, not address the root cause.

8

Conclusion

This paper studies latency tails in FaaS with a focus on warm-start behavior. We find that as cold-start impact decreases on modern offerings, warm-start tail events become a comparatively more prominent source of tail latency. Accordingly, improving perceived FaaS latency consistency increasingly requires understanding and mitigating warm-start tail events, not only cold starts. Moreover, we argue that percentiles beyond p99 should not be disregarded as unrepresentative outliers. In particular, p99.9 and p99.99 often capture rare slowdowns, even when only observing warm starts, that dominate the extreme tail and can meaningfully affect end-to-end latency. This matters especially for latency-critical and multi-function workflows, where many invocations are composed into a single user-visible request. At the same time, these

requirements may be fundamentally misaligned with the typical sweet spot of FaaS, which prioritizes operational convenience and elasticity over strict latency guarantees. Evaluations of FaaS platforms should report p99.9 and p99.99 separately for their cold and warm invocations, and also report the sample count behind these values. Even when completely ignoring cold starts and considering only warm invocations, FaaS platforms in our evaluation do not match the latency consistency of a comparable IaaS deployment. Therefore, for workloads that require tight tail guarantees, IaaS-style deployments remain difficult to replace with FaaS, even under favorable conditions. Finally, we observe similar tail-latency and warm-start effects in multiple existing datasets. This suggests that our observations are not artifacts of a single dataset or testing methodology, but recurring properties that have existed across platforms and over time.

Acknowledgments Funded by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) – 495343202. The authors want to thank Lucas Reinken, who supported this within the scope of a bachelor’s thesis.

References [1] Alexandru Agache, Marc Brooker, Alexandra Iordache, Anthony Liguori, Rolf Neugebauer, Phil Piwonka, and Diana-Maria Popa. 2020. Firecracker: Lightweight Virtualization for Serverless Applications. In 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20). USENIX Association, Santa Clara, CA, 419–434. https://www.usenix.org/conference/nsdi20/ presentation/agache [2] Istemi Ekin Akkus, Ruichuan Chen, Ivica Rimac, Manuel Stein, Klaus Satzke, Andre Beck, Paarijaat Aditya, and Volker Hilt. 2018. SAND: Towards HighPerformance Serverless Computing. In 2018 USENIX Annual Technical Conference (USENIX ATC 18). USENIX Association, Boston, MA, 923–935. https://www. usenix.org/conference/atc18/presentation/akkus [3] Amazon Web Services, Inc. 2014. AWS Lambda. Retrieved 2026-06-04 from https://aws.amazon.com/lambda/ [4] Lixiang Ao, George Porter, and Geoffrey M Voelker. 2022. Faasnap: Faas made fast using snapshot-based vms. In Proceedings of the Seventeenth European Conference on Computer Systems. Association for Computing Machinery, New York, NY, USA, 730–746. [5] Daniel Bardsley, Larry Ryan, and John Howard. 2018. Serverless Performance and Optimization Strategies. In 2018 IEEE International Conference on Smart Cloud (SmartCloud). IEEE, 19–26. doi:10.1109/SmartCloud.2018.00012 [6] David Bermbach, Ahmet-Serdar Karakaya, and Simon Buchholz. 2020. Using Application Knowledge to Reduce Cold Starts in FaaS Services. In Proceedings of the 35th ACM Symposium on Applied Computing (Brno, Czech Republic) (SAC ’20). Association for Computing Machinery (ACM), New York, NY, USA, 134–143. doi:10.1145/3341105.3373909 [7] Qiong Chen, Jianmin Qian, Yulin Che, Ziqi Lin, Jianfeng Wang, Jie Zhou, Licheng Song, Yi Liang, Jie Wu, Wei Zheng, Wei Liu, Linfeng Li, Fangming Liu, and Kun Tan. 2024. YuanRong: A Production General-purpose Serverless System for Distributed Applications in the Cloud. In Proceedings of the ACM SIGCOMM 2024 Conference (Sydney, NSW, Australia) (ACM SIGCOMM ’24). Association for Computing Machinery, New York, NY, USA, 843–859. doi:10.1145/3651890. 3672216 [8] Cloudflare, Inc. 2020. Cloudflare Workers. Retrieved 2026-06-04 from https: //workers.cloudflare.com/ [9] Marcin Copik, Grzegorz Kwasniewski, Maciej Besta, Michal Podstawski, and Torsten Hoefler. 2021. SeBS: a serverless benchmark suite for function-as-aservice computing. In Proceedings of the 22nd International Middleware Conference (Middleware ’21). Association for Computing Machinery, New York, NY, USA, 64–78. doi:10.1145/3464298.3476133 [10] Lazar Cvetković, François Costa, Mihajlo Djokic, Michal Friedman, and Ana Klimovic. 2024. Dirigent: Lightweight Serverless Orchestration. In Proceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles (SOSP ’24).

Tremulant

Association for Computing Machinery, New York, NY, USA, 369–384. doi:10. 1145/3694715.3695966 [11] Jeffrey Dean and Luiz André Barroso. 2013. The tail at scale. Commun. ACM 56, 2 (Feb. 2013), 74–80. doi:10.1145/2408776.2408794 [12] Deno Land, Inc. 2021. Deno Deploy. Retrieved 2026-06-04 from https://deno. com/deploy [13] Dong Du, Tianyi Yu, Yubin Xia, Binyu Zang, Guanglu Yan, Chenggang Qin, Qixuan Wu, and Haibo Chen. 2020. Catalyzer: Sub-millisecond Startup for Serverless Computing with Initialization-less Booting. In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems (Lausanne, Switzerland) (ASPLOS ’20). Association for Computing Machinery, New York, NY, USA, 467–481. doi:10.1145/3373376.3378512 [14] Ana Ebrahimi, Mostafa Ghobaei-Arani, and Hadi Saboohi. 2024. Cold start latency mitigation mechanisms in serverless computing: Taxonomy, review, and future directions. Journal of Systems Architecture 151 (June 2024), 103115. doi:10.1016/j.sysarc.2024.103115 [15] Simon Eismann, Joel Scheuner, Erwin van Eyk, Maximilian Schwinger, Johannes Grohmann, Nikolas Herbst, Cristina L. Abad, and Alexandru Iosup. 2021. A Review of Serverless Use Cases and their Characteristics. doi:10.48550/arXiv. 2008.11110 arXiv:2008.11110 [cs]. [16] Nnamdi Ekwe-Ekwe and Lucas Amos. 2024. The State of FaaS: An analysis of public Functions-as-a-Service providers. In 2024 IEEE 17th International Conference on Cloud Computing (CLOUD). IEEE, 430–438. doi:10.1109/CLOUD62652.2024.00055 arXiv:2408.03021 [cs]. [17] Fastly, Inc. 2019. Edge Compute. Retrieved 2026-06-04 from https://www.fastly. com/products/edge-compute [18] Fly.io. 2020. Fly.io. Retrieved 2026-06-04 from https://fly.io/ [19] Santiago Gallino, Nil Karacaoglu, and Antonio Moreno. 2023. Need for Speed: The Impact of In-Process Delays on Customer Behavior in Online Retail. Operations Research 71, 3 (May 2023), 876–894. doi:10.1287/opre.2022.2262 [20] Samuel Ginzburg and Michael J. Freedman. 2021. Serverless Isn’t Server-Less: Measuring and Exploiting Resource Variability on Cloud FaaS Platforms. In Proceedings of the 2020 Sixth International Workshop on Serverless Computing (Delft, Netherlands) (WoSC ’20). Association for Computing Machinery, New York, NY, USA, 43–48. doi:10.1145/3429880.3430099 [21] Google LLC. 2017. Google Cloud Run Functions. Retrieved 2026-06-04 from https://cloud.google.com/functions [22] Martin Grambow, Tobias Pfandzelter, Luk Burchard, Carsten Schubert, Max Zhao, and David Bermbach. 2021. BeFaaS: An Application-Centric Benchmarking Framework for FaaS Platforms. In Proceedings of the 9th IEEE International Conference on Cloud Engineering (San Francisco, CA, USA) (IC2E 2021). IEEE, New York, NY, USA, 1–8. doi:10.1109/IC2E52221.2021.00014 [23] Mingzhe Hao, Huaicheng Li, Michael Hao Tong, Chrisma Pakha, Riza O. Suminto, Cesar A. Stuardo, Andrew A. Chien, and Haryadi S. Gunawi. 2017. MittOS: Supporting Millisecond Tail Tolerance with Fast Rejecting SLO-Aware OS Interface. In Proceedings of the 26th Symposium on Operating Systems Principles (SOSP ’17). Association for Computing Machinery, New York, NY, USA, 168–183. doi:10.1145/3132747.3132774 [24] Scott Hendrickson, Stephen Sturdevant, Tyler Harter, Venkateshwaran Venkataramani, Andrea C Arpaci-Dusseau, and Remzi H Arpaci-Dusseau. 2016. Serverless Computation with OpenLambda. In 8th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 16). USENIX Association, Denver, CO, 33–39. https://www.usenix.org/conference/hotcloud16/workshop-program/ presentation/hendrickson [25] IBM Cloud. 2023. Deprecation Overview. Retrieved 2026-05-18 from https://web.archive.org/web/20240416171344/https://cloud.ibm.com/docs/ openwhisk?topic=openwhisk-dep-overview [26] Artjom Joosen, Ahmed Hassan, Martin Asenov, Rajkarn Singh, Luke Darlow, Jianfeng Wang, and Adam Barker. 2023. How Does It Function? Characterizing Long-term Trends in Production Serverless Workloads. In Proceedings of the 2023 ACM Symposium on Cloud Computing (Santa Cruz, CA, USA) (SoCC ’23). Association for Computing Machinery, New York, NY, USA, 443–458. doi:10. 1145/3620678.3624783 [27] Artjom Joosen, Ahmed Hassan, Martin Asenov, Rajkarn Singh, Luke Darlow, Jianfeng Wang, Qiwen Deng, and Adam Barker. 2025. Serverless Cold Starts and Where to Find Them. In Proceedings of the Twentieth European Conference on Computer Systems (Rotterdam, Netherlands) (EuroSys ’25). Association for Computing Machinery, New York, NY, USA, 938–953. doi:10.1145/3689031.3696073 [28] Jeongchul Kim and Kyungyong Lee. 2019. FunctionBench: A Suite of Workloads for Serverless Cloud Function Service. In 2019 IEEE 12th International Conference on Cloud Computing (CLOUD). IEEE, Milan, Italy, 502–504. doi:10.1109/CLOUD. 2019.00091 [29] Jörn Kuhlenkamp, Sebastian Werner, Maria C. Borges, Dominik Ernst, and Daniel Wenzel. 2020. Benchmarking elasticity of FaaS platforms as a foundation for objective-driven design of serverless applications. In Proceedings of the 35th Annual ACM Symposium on Applied Computing. ACM, Brno Czech Republic, 1576–1585. doi:10.1145/3341105.3373948

[30] Jialin Li, Naveen Kr Sharma, Dan RK Ports, and Steven D Gribble. 2014. Tales of the tail: Hardware, os, and application-level sources of tail latency. In Proceedings of the ACM Symposium on Cloud Computing. 1–14. [31] Xuanzhe Liu, Jinfeng Wen, Zhenpeng Chen, Ding Li, Junkai Chen, Yi Liu, Haoyu Wang, and Xin Jin. 2023. FaaSLight: General Application-level Cold-start Latency Optimization for Function-as-a-Service in Serverless Computing. ACM Trans. Softw. Eng. Methodol. 32, 5 (July 2023), 119:1–119:29. doi:10.1145/3585007 [32] Nima Mahmoudi and Hamzeh Khazaei. 2022. Performance Modeling of Serverless Computing Platforms. IEEE Transactions on Cloud Computing 10, 4 (2022), 2834– 2847. doi:10.1109/TCC.2020.3033373 [33] Pascal Maissen, Pascal Felber, Peter Kropf, and Valerio Schiavoni. 2020. FaaSdom: a benchmark suite for serverless computing. In Proceedings of the 14th ACM International Conference on Distributed and Event-Based Systems (Montreal, Quebec, Canada) (DEBS ’20). Association for Computing Machinery, New York, NY, USA, 73–84. doi:10.1145/3401025.3401738 [34] Johannes Manner, Martin Endreß, Tobias Heckel, and Guido Wirtz. 2018. Cold Start Influencing Factors in Function as a Service. In 2018 IEEE/ACM International Conference on Utility and Cloud Computing Companion (UCC Companion). IEEE, 181–188. doi:10.1109/UCC-Companion.2018.00054 [35] Nima Nasiri, Nalin Munshi, Simon Daniel Moser, Marius Pirvu, Vijay Sundaresan, Daryl Maier, Thatta Premnath, Norman Böwing, Sathish Gopalakrishnan, and Mohammad Shahrad. 2026. In-Production Characterization of an Open Source Serverless Platform and New Scaling Strategies. In Proceedings of the 21st European Conference on Computer Systems. ACM, McEwan Hall/The University of Edinburgh Edinburgh Scotland UK, 2054–2072. doi:10.1145/3767295.3769377 [36] Edward Oakes, Leon Yang, Dennis Zhou, Kevin Houck, Tyler Harter, Andrea Arpaci-Dusseau, and Remzi Arpaci-Dusseau. 2018. SOCK: Rapid Task Provisioning with Serverless-Optimized Containers. In 2018 USENIX Annual Technical Conference (USENIX ATC 18). USENIX Association, Boston, MA, 57–70. https://www.usenix.org/conference/atc18/presentation/oakes [37] Oracle Corporation. 2019. Oracle Cloud Infrastructure Functions. Retrieved 2026-06-04 from https://www.oracle.com/cloud/cloud-native/functions/ [38] David Schall, Artemiy Margaritov, Dmitrii Ustiugov, Andreas Sandberg, and Boris Grot. 2022. Lukewarm serverless functions: characterization and optimization. In Proceedings of the 49th Annual International Symposium on Computer Architecture (ISCA ’22). Association for Computing Machinery, New York, NY, USA, 757–770. doi:10.1145/3470496.3527390 [39] Joel Scheuner, Simon Eismann, Sacheendra Talluri, Erwin van Eyk, Cristina Abad, Philipp Leitner, and Alexandru Iosup. 2026. Let’s trace it: Fine-grained serverless benchmarking for synchronous and asynchronous applications. Future Generation Computer Systems 179 (2026), 108336. doi:10.1016/j.future.2025.108336 [40] Joel Scheuner and Philipp Leitner. 2020. Function-as-a-Service performance evaluation: A multivocal literature review. Journal of Systems and Software 170 (Dec. 2020), 110708. doi:10.1016/j.jss.2020.110708 [41] Trever Schirmer, Nils Japke, Sofia Greten, Tobias Pfandzelter, and David Bermbach. 2023. The Night Shift: Understanding Performance Variability of Cloud Serverless Platforms. In Proceedings of the 1st Workshop on SErverless Systems, Applications and MEthodologies (Rome, Italy) (SESAME ’23). Association for Computing Machinery (ACM), New York, NY, USA. doi:10.1145/3592533.3592808 [42] Trever Schirmer, Joel Scheuner, Tobias Pfandzelter, and David Bermbach. 2022. Fusionize: Improving Serverless Application Performance through FeedbackDriven Function Fusion. In Proceedings of the 10th IEEE International Conference on Cloud Engineering (Asilomar, CA, USA) (IC2E 2022). IEEE, New York, NY, USA, 85–95. doi:10.1109/IC2E55432.2022.00017 [43] Trever Schirmer, Aris Wiegand, Lucca di Benedetto, Linus Gustafsson, Natalie Carl, Tobias Pfandzelter, and David Bermbach. 2026. New Kids: An Architecture and Performance Investigation of Second-Generation Serverless Platforms. ACM Transactions on Internet Technology 26, 4 (Nov. 2026), 1–31. doi:10.1145/3841482 [44] Mohammad Shahrad, Rodrigo Fonseca, Íñigo Goiri, Gohar Chaudhry, Paul Batum, Jason Cooke, Eduardo Laureano, Colby Tresness, Mark Russinovich, and Ricardo Bianchini. 2020. Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider. In 2020 USENIX Annual Technical Conference (USENIX ATC 20). USENIX Association, 205–218. https://www.usenix. org/conference/atc20/presentation/shahrad [45] The Kubernetes Authors. 2026. Kubernetes Images. Retrieved 2026-06-04 from https://kubernetes.io/docs/concepts/containers/images/ [46] Dmitrii Ustiugov, Theodor Amariucai, and Boris Grot. 2021. Analyzing Tail Latency in Serverless Clouds with STeLLAR. In 2021 IEEE International Symposium on Workload Characterization (IISWC). IEEE, 51–62. doi:10.1109/IISWC53511. 2021.00016 [47] Ao Wang, Shuai Chang, Huangshi Tian, Hongqi Wang, Haoran Yang, Huiba Li, Rui Du, and Yue Cheng. 2021. FaaSNet: Scalable and Fast Provisioning of Custom Serverless Container Runtimes at Alibaba Cloud Function Compute. In 2021 USENIX Annual Technical Conference (USENIX ATC 21). USENIX Association, 443–457. https://www.usenix.org/conference/atc21/presentation/wang-ao [48] Kai-Ting Amy Wang, Rayson Ho, and Peng Wu. 2019. Replayable Execution Optimized for Page Sharing for a Managed Runtime Environment. In Proceedings of the Fourteenth EuroSys Conference 2019 (Dresden, Germany) (EuroSys ’19).

Linus Gustafsson, Trever Schirmer, and David Bermbach

Association for Computing Machinery, New York, NY, USA, Article 39, 16 pages. doi:10.1145/3302424.3303978 [49] Liang Wang, Mengyuan Li, Yinqian Zhang, Thomas Ristenpart, and Michael Swift. 2018. Peeking Behind the Curtains of Serverless Platforms. In 2018 USENIX Annual Technical Conference (USENIX ATC 18). USENIX Association, Boston, MA, 133–146. https://www.usenix.org/conference/atc18/presentation/wang-liang [50] Synthia Wang, Kyle MacMillan, Brennan Schaffner, Nick Feamster, and Marshini Chetty. 2024. Measuring the Consolidation of DNS and Web Hosting Providers. doi:10.48550/arXiv.2110.15345 arXiv:2110.15345 [cs]. [51] Yunjing Xu, Zachary Musgrave, Brian Noble, and Michael Bailey. 2013. Bobtail: Avoiding Long Tails in the Cloud. In 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13). USENIX Association, Lombard,

IL, 329–341. https://www.usenix.org/conference/nsdi13/technical-sessions/ presentation/xu_yunjing [52] Tianyi Yu, Qingyuan Liu, Dong Du, Yubin Xia, Binyu Zang, Ziqian Lu, Pingchao Yang, Chenggang Qin, and Haibo Chen. 2020. Characterizing serverless platforms with serverlessbench. In Proceedings of the 11th ACM Symposium on Cloud Computing (SoCC ’20). Association for Computing Machinery, New York, NY, USA, 30–44. doi:10.1145/3419111.3421280 [53] Yanqi Zhang, Íñigo Goiri, Gohar Irfan Chaudhry, Rodrigo Fonseca, Sameh Elnikety, Christina Delimitrou, and Ricardo Bianchini. 2021. Faster and Cheaper Serverless Computing on Harvested Resources. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles (Virtual Event, Germany) (SOSP ’21). Association for Computing Machinery, New York, NY, USA, 724–739. doi:10.1145/3477132.3483580

Related documents

• Tremulant: Latency in Serverless Platforms beyond the 99th Percentile#1344034
• Perbandingan Kinerja dan Efektivitas Algoritma FCFS dan SJF pada Sistem Antrian UMKM#1226232
• Flight Path: A Microservices Message-Passing Flight Software Architecture for CesiumAstro Element One Satellite#442315
• Scaling Distributed Spacecraft Autonomy Operations With Simple Temporal Networks: Introducing Splinter#814134
• Contribution of a synchronic teleneurology program to decrease the patient number waiting for a first consultation and their waiting time in Chile#281858