arXiv CS open access

Characterizing Serverless Workloads: A Large-Scale Analysis of Function-as-a-Service Platforms

Saman Akbari et al. · arxiv_cs

arXiv CS · Papers

cloud distributed-computing parallel-computing

Serverless computing is a popular approach to application deployment without having to manage the underlying infrastructure. Its most common implementation is Function-as-a-Service (FaaS), in which applications are structured as fine-grained functions. FaaS providers face non-trivial tasks in the ma

Conceptio Open Archive

Analyze & explore related research in Conceptio

Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.

Explore in Search →Connect via MCP / API ↗

Characterizing Serverless Workloads: A Large-Scale Analysis of Function-as-a-Service Platforms Saman Akbari

a,∗

, Yassine Lazreg

, Mohammadreza Malekabbasi

, Manfred Hauswirth

a,b

a Technische Universität Berlin, Berlin, Germany b Fraunhofer Institute for Open Communication Systems (FOKUS), Berlin, Germany

Abstract Serverless computing is a popular approach to application deployment without having to manage the underlying infrastructure. Its most common implementation is Function-as-a-Service (FaaS), in which applications are structured as fine-grained functions. FaaS providers face non-trivial tasks in the management of their platforms, including cold starts, auto-scaling, and scheduling. The design of optimized platforms requires an accurate understanding of realistic serverless workloads. However, existing research and platforms rely on insights from single, often outdated datasets. In this work, we conduct a large-scale, cross-platform comparative analysis of eight publicly available FaaS workload traces from major cloud providers (Alibaba, Azure, Huawei, IBM) and a scientific computing platform (Globus). We provide a comprehensive and up-to-date view of the serverless ecosystem by characterizing key dimensions such as invocation patterns, latency, cold start behavior, and resource utilization. Our analysis shows that although invocation patterns remain universal, execution times have shortened, shifting the performance bottleneck toward platform scheduling and dependency management. We also observe an architectural shift toward “Serverless 2.0” models, where concurrent, long-lived containers are increasingly utilized to bypass cold start penalties. Furthermore, we found resource over-provisioning and extreme skew in user request volumes. These findings provide actionable insights for designing more efficient FaaS platforms, informing improved approaches to targeted cold start mitigation, predictive resource management, and dependency-aware scheduling. Keywords: Cloud computing, function-as-a-service, performance analysis, serverless computing, workload characterization

1. Introduction Function-as-a-Service (FaaS) has fundamentally altered application development by eliminating infrastructure management. Serverless platforms like AWS Lambda, Azure Functions, and Google Cloud Functions allow developers to deploy and execute code on demand, with the provider managing scaling, provisioning, scheduling, and other infrastructure tasks [1]. This application and execution model has seen rapid adoption, driven by the paradigm’s promise of reduced operational overhead and a pay-per-use pricing model, where users are billed only for the computation time their functions consume [2]. However, this user-centric convenience creates significant challenges for FaaS providers. To provide the illusion of infinite, instantaneous resources, providers must navigate a complex trade-off between performance and cost-efficiency. A central challenge is the “cold start,” the latency incurred when a new function instance must be initialized from scratch, which can dramatically increase response times [1, 3]. Providers mitigate this by keeping recently used instances “warm,” but ∗ Corresponding author

Email addresses: akbari@tu-berlin.de (Saman Akbari ), y.lazreg@tu-berlin.de (Yassine Lazreg ), malekabbasi@tu-berlin.de (Mohammadreza Malekabbasi ), manfred.hauswirth@tu-berlin.de (Manfred Hauswirth )

this consumes additional resources. Without a deep understanding of workload patterns, providers risk either overprovisioning resources, leading to high operational costs, or under-provisioning, resulting in poor user experience. Effective optimization strategies, such as predictive prewarming, intelligent keep-alive policies, or optimized scheduling, depend on an accurate characterization of production FaaS workloads. Beyond cold start mitigation, providers face numerous other operational challenges, such as dynamic autoscaling, efficient memory and CPU bin-packing, data locality and caching. The design of efficient management algorithms requires precise knowledge of serverless workloads. However, much of the existing research relies on a limited number of public datasets, with most studies referencing the Azure trace from 2019 [1]. This is problematic for two reasons: First, we cannot assume that the workload of a single platform is representative of the entire FaaS ecosystem. Second, the FaaS landscape is rapidly evolving and workload characteristics from several years ago may no longer reflect current usage patterns. This paper addresses this gap by conducting a large-scale, cross-platform comparative analysis of eight publicly available FaaS workload traces from major cloud providers (Alibaba, Azure, Huawei, IBM) and a scientific computing platform (Globus). By comparing these diverse datasets, we aim to identify common patterns, platform-specific differences, and temporal trends in serverless workloads. Our analysis focuses

Trigger

Request

User

Scheduler

FaaS Platform

on metrics that directly impact system design and performance, such as request arrival patterns, latencies, cold start behavior, resource usage, and application dependencies. Our contributions are twofold: (1) We provide a comprehensive characterization of modern serverless workloads across multiple platforms to identify universal patterns, as well as distinct nuances across diverse deployments. (2) We translate these findings into concrete recommendations for the design of FaaS systems, informing areas such as predictive resource management, targeted cold start mitigation, and efficient scheduling. By making these datasets and their characteristics systematically comparable, we aim to provide a solid empirical foundation for future research in serverless computing. Our findings show that the serverless ecosystem has evolved. Although strong diurnal request patterns and extreme skewness in function popularity and user request volumes remain universal, modern FaaS executions have become dramatically shorter, often completing in just a few milliseconds. This shift turns orchestration overhead, particularly scheduling delays and dependency deployment, into the primary performance bottleneck. Furthermore, we expose pervasive resource over-provisioning, a growing architectural shift toward “Serverless 2.0” models that favor persistent, concurrent containers, and a distinct divide between commercial “nano-service” platforms and heavytailed scientific execution environments. The rest of this paper is organized as follows: Section 2 provides the necessary context on FaaS concepts and optimization techniques. Section 3 describes the datasets and our analysis methodology. Section 4 presents our findings on workload characteristics. We discuss the implications of our results in Section 5, review related work in Section 6, and finish with our conclusions in Section 7. To support reproducibility and further research, we have open-sourced the complete analysis: https://github.com/saman-akbari/characterizing -serverless-workloads.

Worker

Memory Pool request memory

▲

Evictor

release destroy memory

▼

...

Legend: initializing

▲

idle / busy destroying

▼

Figure 1: Architectural overview of Function-as-a-Service platforms. Workers manage a memory pool and execute functions in response to events in virtualized execution environments (sandboxes).

instance processes the request and subsequently remains idle in memory for some time to serve potential future requests (“warm starts”). To maintain cluster efficiency and free up resources for new functions, an evictor component actively monitors the worker. It destroys instances that have been idle beyond a specified threshold or during memory pressure, releasing their allocated resources back to the memory pool. 2.2. Serverless Workload Traces Our analysis is based on a collection of publicly available serverless workload traces. These datasets originate from several platforms, including public cloud providers and scientific computing infrastructures, providing a broad perspective on FaaS usage. Previous work has analyzed these datasets individually, and many studies rely on the first Azure trace from 2019 [1]. This isolated and outdated approach can lead to conclusions that are not generalizable across the constantly evolving serverless ecosystem. Our work addresses this limitation by conducting a systematic comparison of existing traces to provide a more comprehensive and structured characterization of serverless workloads.

2. Background and Motivation This section recaps the FaaS execution model and reviews existing serverless workload traces. 2.1. Serverless Computing and Function-as-a-Service

Microsoft Azure Functions. Microsoft has released three datasets characterizing its FaaS platform, each spanning two weeks. The 2019 trace (Azure19) [1] provides request counts per minute, execution duration percentiles, and memory usage metrics for over 70 000 functions. The 2020 trace (Azure20) [4] focuses on data-centric behavior, logging interactions between functions and the Azure Blob Storage, including blob types, sizes, and access patterns. The 2021 trace (Azure21) [5] offers finer granularity with per-invocation start and end timestamps, enabling a precise concurrency and latency analysis.

Figure 1 shows the high-level architecture and execution flow of a typical FaaS platform. Following an event-driven programming model, workers execute stateless functions in response to specific triggers, such as HTTP requests, scheduled events, or messages from other services. A scheduler routes the incoming request to a worker node. Because FaaS functions are inherently stateless, workers often interact with external storage or databases to read or persist data during and between executions. Internally, each worker manages a dynamic set of virtualized execution environments (e.g., containers or microVMs). When a request arrives and no preexisting instance is available, the worker allocates resources from its memory pool. This creates a new instance, incurring a “cold start” latency as the environment boots and dependencies are loaded. Once prepared, the

Alibaba Cloud Function Compute. The Alibaba Cloud trace (Alibaba21) [6] characterizes 15 days of production workloads, specifically detailing cold start events. Unlike general in2

Table 1: Available metrics across serverless workload traces. Recent datasets provide significantly richer metadata, including cold start breakdowns and dependency information, compared to earlier traces.

Metric Request Arrival Rates Execution Time Response Time Cold Start Latency Memory Usage Memory Limit CPU Usage CPU Limit Instance Count Instance Concurrency Limit Minimum Instance Scale Imported Libraries Function Code Metrics Runtimes Triggers Users Data Access I/O

Azure19 ✓ ✓

Azure20

Azure21 ✓ ✓

Alibaba21

Huawei23 ✓ ✓ ✓

✓ ✓ ✓

✓ ✓ ✓ ✓ ✓

Huawei25 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Globus24 ✓ ✓ ✓ ✓

IBM26 ✓ ✓ ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓ ✓

✓ ✓

✓ ✓ ✓

✓

Table 2: Dataset statistics. Number of raw rows and the number of rows excluded during data cleaning.

vocation traces, this dataset records system-level latencies such as image pulling and container initialization. It includes metadata for function names, allocated memory, and runtime environments, making it particularly valuable for analyzing the costs of container provisioning. Huawei Cloud. Huawei has contributed two extensive datasets. The first (Huawei23) [7] spans over seven months and consists of two parts: a “Public” trace containing per-minute arrival rates for over 5 000 functions, and a “Private” trace capturing internal workloads with high-fidelity per-second metrics for requests, delays, and resource usage. The subsequent trace (Huawei25) [3], spanning 31 days across five data center regions, provides a unique component-level breakdown of cold start latencies, separating pod allocation, code deployment, dependency installation, and scheduling overheads.

Dataset

# Rows Raw

# Rows Excluded

Azure19 Azure20 Azure21 Alibaba21 Huawei23 Huawei25 Globus24 IBM26

1 488 281 44 282 912 1 980 951 1 629 445 13 806 720 17 373 334 2 399 438 1 900 376 220

7 50 063 2 606 2 0 5 0 0

3. Methodology Our methodology is centered around a comparative analysis of the publicly available FaaS workload traces. We aim to identify both commonalities and platform-specific differences to build a comprehensive understanding of serverless workloads.

Globus Compute Functions. The 2024 trace from Globus Compute (Globus24) [8] captures 31 weeks of activity on a federated FaaS platform used primarily for scientific computing. It logs task executions across various endpoints, ranging from local devices to HPC clusters. A key characteristic of this dataset is that it provides function source code metrics (lines of code, complexity, libraries) and detailed lifecycle timestamps to analyze queuing and overhead in federated environments.

3.1. Datasets We selected all eight publicly available serverless workload traces from Azure [1, 4, 5], Alibaba [6], Huawei [7, 3], Globus [8], and IBM [9]. For Huawei23, although the original release includes both public and private workloads, we exclusively analyzed the private trace because the public trace only provides a single metric (requests per minute), whereas the private trace offers higher-fidelity per-second data, such as latencies and resource metadata. In the following, we refer to the datasets using the name of the dataset and its publication year as shorthand, for example, Alibaba21 for the dataset published by Alibaba in 2021.

IBM Cloud Code Engine. The 2026 trace from IBM (IBM26) [9] characterizes a “Serverless 2.0” platform based on Knative. Spanning 66 days (≈ 9.5 weeks) with 1.9 billion invocations, it captures the behavior of general-purpose containers rather than just functions. Furthermore, it includes detailed user configurations absent in other traces, such as CPU and memory limits, minimum scale settings (allowing users to opt-out of scale-to-zero), and container concurrency limits. 3

2 3 4 5 Time (in days)

2 1.5 1 0.5 0

2 3 4 5 Time (in days)

Requests / Average

100

2 3 4 5 Time (in days)

50 40 30 20 10 0 50 40 30 20 10 0

3 2

Weekends

Weekdays

15 10 5 0

Weekends

15 10 5

Overall

60 50 40 30 20 10 0

Weekdays

60 50 40 30 20 10 0 60 50 40 30 20 10 0

Weekends

Hour of Day

(a) Azure19

(b) Azure21

1 0

2 3 4 5 Time (in days)

(d) Huawei25

500

10 5 0

(b) Azure21 Requests / Average

Requests / Average

(a) Azure19

2 3 4 5 Time (in days)

Weekdays

Requests (× 10000000)

3 2 1 0

(e) Globus24

2 3 4 5 Time (in days)

(f) IBM26

Overall

20 15 10 5 0

Weekdays

20 15 10 5 0 20 15 10 5 0

Weekends

Overall

100 80 60 40 20 0

Weekdays

100 80 60 40 20 0 100 80 60 40 20 0

Requests (× 100000)

Requests (× 10000000)

Overall

Requests (× 1000)

0.5

Overall

50 40 30 20 10 0

Requests (× 10)

30 25 20 15 10 5 0

Requests (× 1000000)

Requests / Average

1.5

Weekends

Overall

20 15 10 5 0

Weekdays

20 15 10 5 0 20 15 10 5 0

Weekends

Hour of Day

(d) Huawei25

(e) Globus24

(f) IBM26

Figure 2: Time series of request arrival rates (requests per minute, normalized by the mean) for the first week in all datasets. While platforms like Azure19 and Huawei23 maintain tight bands near their average, Azure21 and Globus24 show extreme burstiness, with sudden spikes reaching 25× and 310× their respective means.

Figure 3: Average request arrival rates per hour show distinct daily usage patterns. Each column presents the hourly average for all days (top), weekdays (middle), and weekends (bottom). The blue bars highlight the continuous 8hour window with the lowest overall activity, whereas orange bars represent the more active periods.

3.2. Metrics

dropped a small number of erroneous records, such as negative latencies resulting from clock synchronization issues. We also normalized the timestamp formats across all datasets to a relative time from the start of the trace, facilitating time-series analysis. We implemented a taxonomy for categorical metadata, mapping proprietary trigger names (e.g., Huawei’s “APIG” or “OBS”) to general equivalents (“HTTP” and “Storage”) and generalizing runtime environments (e.g., mapping python-3.9 to python). We provide statistics for the subsets of the eight traces that we used for our characterization in Table 2. The IBM26 dataset has a distinct structure in which the raw data consists of weekly records that each contain a list of invocation events (i.e., a list of lists). Therefore, we count each individual invocation event as one row in our statistics for this trace.

Table 1 provides an overview of the metrics available in the analyzed datasets. The traces collectively capture a wide variety of metrics, including request arrival rates, execution and response times, cold start latencies, and resource metrics such as CPU and memory usage versus their configured limits. Additionally, they provide insight into instance dynamics (e.g., active instance counts and scaling bounds), and application metadata, such as runtimes, triggers, I/O payloads, and code-level characteristics. The availability and granularity of these metrics reflect a clear evolution in serverless tracing. Earlier datasets, such as Azure19, offered only few metrics, such as timestamps and execution times, which were often aggregated per minute. In contrast, recent traces provide significantly higher granularity. For example, Huawei25 provides per-invocation records along with detailed latency breakdowns at the component-level of cold starts. Furthermore, modern traces expose configuration and structural details that were previously unavailable, such as instance concurrency settings in IBM26. This increasing number of metrics enables a deeper characterization of modern serverless platforms.

4. Characterization This section presents the findings of our cross-platform workload analysis. We structure our results by key characteristics. 4.1. Request Patterns

3.3. Data Processing and Normalization

We analyze request arrival patterns in Azure19, Azure21, Huawei23, Huawei25, Globus24, and IBM26, because these traces provide the necessary timestamped invocation data or arrival rates to study burstiness and diurnal cycles.

To perform our computations, we used Dask [10], an out-ofcore parallel computing framework that can process datasets larger than memory by operating on data in chunks. We 4

5 0

12 18 Hour of Day

(a) Azure21

100 50 0

12 18 Hour of Day

(b) Globus24

0.012 0.01 0.008 0.006 0.004 0.002 0

6 12 18 Hour of Day

0.15

Execution Time (s)

150

Execution Time (s)

0.1 0.05

6 12 18 Hour of Day

(d) Huawei25

0.8 0.6 0.4 0.2 0

12 18 Hour of Day

(e) IBM26

Bursty Workloads. A time-series view of request arrivals shows that the scale of short-term variability, or burstiness, differs between FaaS platforms. Figure 2 plots the number of requests per minute over several days, normalized by the overall mean of the platform. Platforms like Azure19 and Huawei23 show relatively smooth aggregate behavior, with tightly bounded maximum loads that do not exceed 2× their average. Huawei25 and IBM26 show moderate volatility, with peaks reaching roughly 3× the mean. In contrast, Azure21 and Globus24 experience extreme and sudden spikes in demand. Azure21 shows bursts that are up to 25× its average, whereas the scientific computing workloads in Globus24 reach peaks of up to 310× their baseline, due to large-scale, sudden batch submissions. This disparity implies that autoscaling and resource provisioning mechanisms cannot rely on a universal assumption of burstiness. They should be tailored to the specific volatility profile of the hosted workload, ranging from conservative buffering to highly aggressive, instantaneous scale-out.

Requests (%)

100

Azure19 Azure21 Globus24 Huawei23 Huawei25 IBM26

75 50

rm nifo

25 0

u trib

tio

Warm Starts (%)

Figure 4: Hourly variations in average execution time across five FaaS platforms over a 24-hour cycle. Azure21 and Globus24 show significant fluctuations with latency spikes, whereas Huawei23, Huawei25, and IBM26 maintain relatively stable execution times throughout the day.

Dis

U 0

25 50 75 Functions (%)

100

(a) Skewed Function Popularity

100 75 50 25 0 0.1

Azure21 Globus24 Huawei23 IBM26

1 10 100 1000 Keep-Alive Window (s)

(b) Function Idle Times

Figure 5: Function popularity and idle times. (a) A small fraction of functions consistently accounts for the majority of invocations across all platforms. (b) The probability of a warm start as a function of the keep-alive window duration shows diverse reuse patterns, from rapid reuse (Azure21) to periodic jobs (Globus24).

tency across all hours, other traces show significant swings during a day. For example, Azure21 ranges from ≈ 1.1 s during quiet periods to more than 17 s during peak spikes. End-toend response times follow a similar pattern of diurnal volatility, but are further exacerbated by platform congestion. Commercial platforms keep this scheduling overhead minimal. However, systems like Globus24 experience extreme queueing delays during peak submission windows. The average response time in Globus24 reaches nearly 1 400 s, which substantially exceeds its execution time fluctuations. Interestingly, comparing Figure 3(e) and Figure 4(b) shows that the execution time peak in Globus24 (around 11:00) strongly negatively correlates (−0.84) with the request volume. Therefore, service bottlenecks in batch-oriented systems are not necessarily caused by a high volume of requests, but rather by resource-heavy tasks.

Diurnal Cycles. When aggregated hourly, the workloads show distinct diurnal (24-hour) patterns with varying intensities (Figure 3). Although commercial platforms generally peak during typical working hours, they show different offpeak behaviors. For instance, IBM26’s volume decreases by 68.8% from its daily peak to its overnight minimum, whereas Huawei25 maintains a higher overnight baseline, with a smaller decrease of 55.1%. Weekend traffic reductions are similarly platform-dependent. Across the full trace, IBM26 averages a 58.0% weekend volume reduction, but this decrease is highly concentrated, exceeding 65% around midday compared to only 32% at 5:00 AM. Huawei25 experiences a much smaller weekend reduction of 17.6%. In contrast, Azure19 shows a significantly flatter profile, with a 16.1% diurnal reduction and a 2.3% weekend reduction, suggesting that globally distributed or background workloads smooth out daily peaks. The Globus24 trace exhibits an irregular pattern dominated by batch submission windows rather than human-driven demand patterns. Despite these variations, the least busy period consistently falls within a continuous eight-hour window (blue bars), offering a predictable daily timeframe for system maintenance or resource reclamation.

Skewed Function Popularity. The distribution of requests across individual functions is skewed across all platforms. As shown by the Lorenz curve in Figure 5(a), a small fraction of functions consistently accounts for the majority of invocations. For commercial platforms, the magnitude varies slightly: In IBM26, Azure19, and Huawei25, the skew is extreme; the top 1–5% of functions process more than 90% of requests. Specifically, in Huawei25, the top 1% of functions account for over 99% of all traffic. In Azure21 and Huawei23, the distribution is slightly broader but still highly concentrated, with the top 10% of functions accounting for over 90% of requests. The Globus24 trace shows a slightly less extreme skew, rising earlier than the others. This aligns with its scientific workload, where a wider array of specialized batch tasks are executed. However, it still starkly deviates from a uniform distribution.

In contrast to the predictable diurnal cycles of request arrivals, average function execution times can be highly volatile throughout the day, as shown in Figure 4. Although platforms like Huawei23 maintain a stable average execution la5

Table 3: Cold start latency statistics (s). Commercial platforms show subsecond medians with > 30 s tails, whereas Globus24 shows extreme tail latencies driven by batch scheduling queues.

0.86 0.01 1.29

3.85 298.89 3.25

19.2 371.2 11

P99 36 8 645.8 36.9

Max 193 130 818 287

50 25

0.02% 0.02% 0.02% 0.02%

Cold Start Rate (%)

P95

Cold Start Rate (%)

Mean

75 50 25 0

Day

(a) Huawei25

Functions

100

100 Day

200

100 75 50

2.11% 2.63% 5.59% 5.08%

250.01% 0.00% 0.01% 0.01% 0 0 20 40 60 Day

(b) Globus24

Figure 6: Cold start rate over time. A clear contrast exists between the perrequest and per-function cold start rates in Huawei25 due to extreme popularity skew. IBM26 maintains near-zero cold starts across both metrics due to minimum instance scale and high concurrency limits, whereas Globus24 shows high volatility typical of batch-oriented provisioning of scientific workloads.

The “hot” functions are likely to remain warm due to frequent reuse, naturally avoiding cold starts, whereas the long tail of rarely invoked functions is more likely to incur cold start penalties.

Allocation Deploy Code Requests CDF

1.00

Function Idle Times. To assess the potential effectiveness of keep-alive strategies, we examine the inter-arrival time (IAT) distributions, which represent function idle times between consecutive requests. Figure 5(b) plots the theoretical probability of warm-start versus the length of the keep-alive window (equivalent to the IAT CDF). The platforms show distinctly different temporal behaviors. Azure21 demonstrates high temporal locality, smoothly reaching a warm-start rate of 76.4% with a 1 s window. Huawei23 exhibits an almost continuous invocation, achieving near 98% warm starts even with a 0.1 s window. Because the Huawei23 dataset aggregates multiple request counts into 1 s buckets, we modeled concurrent invocations within the same second as a Poisson process using exponential inter-arrival times to approximate these sub-second dynamics. This trace captures 200 highly popular internal functions, rather than a general user workload, which explains this extreme frequency. In contrast, Globus24 shows a pronounced step-function pattern with a large vertical jump at 60 s from 62.5% to 87.4%. This strongly indicates periodic workloads driven by minute-level cron jobs or batch polling intervals. Like Huawei23, the IBM26 dataset truncates arrival timestamps to a 1 s integer resolution. After applying the same Poisson approximation to recover intra-second arrivals, IBM26 reveals a rapid progression, achieving an 80% warm start rate for a keep-alive window of just 100 ms, and crossing 90% at ≈ 188 ms. By 1 s, the warm start rate exceeds 99.5%. These contrasting behaviors show that a single static keep-alive window mismatches with the diverse temporal profiles of serverless workloads.

0.75 0.50

Alibaba21 Globus24 Huawei25

0.25 0.00

10 102 103 104 105 Cold Start Latency (s)

(a) Cold Start Latency CDF

Deploy Dependencies Network, Routing, Scheduling Cold Start Time (s)

Alibaba21 Globus24 Huawei25

Median

Cold Start Rate (%)

Dataset

Requests 100 82.84% 82.60% 83.85% 81.39%

5 4 3 2 1 0

Day

(b) Latency Breakdown (Huawei25)

Figure 7: Cold start latencies and components. (a) Cumulative distribution of cold start latencies shows commercial platforms with long tails up to 30 s, whereas scientific workloads (Globus24) show queuing delays. (b) Breakdown of latency components shows that network, routing, scheduling, and dependency deployment dominate the total initialization time. The chart also shows significant day-to-day variance in total latency.

4.2. Cold Starts We examine cold starts in Alibaba21, Huawei25, Globus24, and IBM26. These datasets are selected because they explicitly log cold start events, detailed latency breakdowns, or provide pod allocation timestamps that allow inferring initialization penalties. Cold Start Rate. We examine the frequency of cold starts on FaaS platforms in Figure 6. We distinguish between the cold start rate calculated across the total request volume versus the unweighted average rate across individual functions. For commercial platforms, this distinction shows a substantial disparity driven by workload skew. In Huawei25, the cold start rate perrequest is negligible at ≈ 0.02%, which means that the majority of user traffic is served by warm instances. However, the cold start rate per-function consistently exceeds 80%. This indicates that although heavily invoked “hot” functions remain persistently warm, the long tail of rarely invoked functions almost always suffers a cold start upon execution. As the IBM26 dataset does not explicitly include a cold start attribute, we infer these events by identifying the initialization of new pod instances that exceed the application’s configured minimum scale. Under this assumption, IBM26 shows a particularly low cold start rate for both requests (≈ 0.002–0.01%) and functions (≈ 2–6%). This sustained warmth across the function population is attributable to the platform’s “Serverless 2.0” configuration patterns: Users actively use minimum scale settings (> 0) and high concurrency limits, with a default of 100 requests per instance on IBM26,

Insight 1. The combination of high popularity skew, bursty arrivals, and diverse idle time profiles indicates that uniform resource management policies are inefficient. FaaS platforms should adopt asymmetric, perfunction strategies: High-volume functions can adopt extended keep-alive windows and dedicated capacity to handle sudden spikes, whereas the long-tail of sporadic or periodic functions can be scaled to zero coupled with predictive pre-warming.

Cold Start Time (s)

which eliminate cold start latency for most workloads. We discuss such instance metrics in more detail in Section 4.4. In contrast, Globus24 shows extreme volatility. During peak periods, the cold start rate for requests and functions increases to nearly 100%. This behavior confirms that its execution model is primarily on-demand, where resources are provisioned specifically for incoming task batches rather than being kept warm continuously.

200 100 10 1

e ) er C# ain untim T ( Cont R E m .N om sto st Cu Cu

Jav

js de.

n P PH Pytho

(a) Alibaba21 Cold Start Time (s)

Cold Start Latency. Cold start latency remains a primary performance bottleneck, although its magnitude varies by platform type. Figure 7(a) compares the cumulative distribution function (CDF) of cold start latencies. For commercial public clouds, such as Alibaba21 and Huawei25, median cold start times are comparable at ≈ 0.86 s and 1.29 s, respectively (Table 3). However, these distributions are heavily skewed. The 99th percentile (P99) reaches ≈ 36 s for both platforms. This implies that although the median user experience is acceptable, a significant fraction of requests suffers delays that are orders of magnitude longer than typical execution times. In contrast, the scientific workloads of Globus24 show a distinct, bimodal profile. Although the median cold start latency is negligible (≈ 0.01 s), likely reflecting rapid task dispatch to alreadyactive endpoints, the distribution has a long tail. The mean reaches 299 s (≈ 5 minutes) and the P99 exceeds 2.4 hours. This reflects the batch-scheduling nature of scientific computing, where a “cold start” often implies waiting for the underlying batch scheduler to allocate HPC nodes to the federated endpoint.

500 100 10 1

) er C# ntain T( o E C .N m sto Cu

a Jav

de.

n tho

(b) Huawei25 Figure 8: Cold start latencies by runtime. Custom containers consistently incur the highest initialization penalties. Although Java showed high latency in Alibaba21, it shows sub-second performance in the newer Huawei25 dataset, matching Python and Node.js.

a natively compiled language, benefits from a small runtime footprint and the absence of language-level VM startup overhead, leading to highly predictable performance with minimal variance and almost no extreme outliers. This is particularly evident in the Alibaba21 dataset, where Go largely mitigates the “long-tail” problem. However, this advantage is environmentdependent: In Huawei25, Go exhibits tail latencies similar to .NET (C#) and PHP, although still lower than most other runtimes. We also observe a significant difference in Java performance. In the Alibaba21 dataset, Java functions show high cold start penalties (median ≈ 15 s), reflecting the JVM startup overhead. In contrast, the Huawei25 platform achieves sub-second median cold starts for Java, putting it on par with lightweight interpreted runtimes like Python and Node.js. This behavior occurs because the platform maintains reserved resource pools of pre-warmed environments for default runtimes like Java.

Breakdown of Cold Start Latency. To understand the sources of these delays, we analyze the daily breakdown of the cold start components in the Huawei25 dataset (Figure 7(b)). Our statistical analysis shows that network, routing, and scheduling overhead is the dominant factor, with a mean of ≈ 1.17 s. Dependency deployment closely follows at 0.95 s, and pod allocation averages 0.66 s. The code deployment is the fastest component, averaging only 0.43 s. This suggests that platform orchestration overhead and the management of heavy runtime environments contribute more to latency than the network transfer of the function logic itself. Furthermore, heavier resource requests (larger CPU/memory limits) increase these delays, because the scheduler requires more time to find suitable nodes for bin-packing. We also observe a cyclic pattern over the 31-day period. The total cold start times fluctuate noticeably between 2.2 s and 4.1 s depending on the day. This variance indicates that initialization performance is significantly affected by overall cluster congestion and diurnal load patterns.

Insight 2. The dominance of scheduling and dependency deployment in cold start latency indicates that orchestration overhead and environment setup are critical bottlenecks. Optimizations such as dependencyaware scheduling or predictive pre-fetching can yield large performance gains. Additionally, the disparity between per-request and per-function cold start rates confirms that initialization latency is primarily a problem for the “long tail” of unpopular functions. Finally, the near-elimination of cold starts in the IBM26 trace suggests that exposing control, such as minimum instance scaling and concurrency limits, allows users to effectively bypass these penalties for latency-sensitive applications.

Impact of Runtimes. The choice of runtime environment affects initialization overhead. As visualized in Figure 8, custom containers consistently show higher median latencies (≈ 30 s in Alibaba21 and ≈ 10 s in Huawei25) along with a high variance. This confirms the performance penalty associated with unmanaged environments that cannot leverage the platform’s standard pre-warmed pools. In contrast, lightweight runtimes like Node.js, Python, and Go maintain low median latencies (≈ 1 s) across both datasets. In particular, Go, being 7

1.00 Azure19 Azure21 Globus24 Huawei23 Huawei25 IBM26

0.75 0.50 0.25 0.00

Requests CDF

1.00

100

1000 10000 100000 Execution Time (ms)

0.75

0.25 0.00

3600000

Globus24 Huawei23 Huawei25 IBM26

0.50

108 106 104 102 1 Azure19

Azure21

Globus24

1000 10000 100000 Response Time (ms)

3600000

(a) CDF

Response Time (ms)

Execution Time (ms)

(a) CDF

100

Huawei23

Huawei25

IBM26

109 106 104 102 1 Globus24

Huawei23

Huawei25

IBM26

(b) Distribution

Figure 9: Function execution times. Modern workloads (Azure21, Globus24, Huawei23, Huawei25, IBM26) show significantly lower median latencies (< 35 ms) compared to the older Azure19 trace, although all show heavy tails.

Figure 11: End-to-end response times. Commercial platforms (Huawei23, Huawei25, IBM26) maintain low median response times (< 15 ms), whereas Globus24 shows higher mean latency and a heavy tail.

4.3. Latency

handled in milliseconds, the typical function logic deployed by developers often involves longer-running tasks that are invoked less frequently. The Globus24 dataset offers a unique perspective on how the underlying computing infrastructure influences execution time. Figure 10 illustrates the execution time CDF for functions running on cloud, local, and high-performance computing (HPC) endpoints. As a federated platform, Globus Compute allows users to deploy endpoints on arbitrary remote resources. Tasks routed to cloud endpoints are short-lived, with a median below 1 ms. “Local” endpoints, which represent single-node resources such as edge devices and account for ≈ 75% of the platform’s endpoints, show a median execution time of ≈ 63 ms. In contrast, tasks executed on HPC endpoints show a pronounced heavy tail. The median execution time on HPC resources jumps to ≈ 3 s, with the tail extending up to several hours. The choice of runtime environment also introduces distinct performance characteristics. Huawei25 breaks down execution times by runtime for the dataset. Java functions show the lowest median latencies (≈ 0.3 ms), likely due to pre-warmed internal microservices keeping the JVM hot. Node.js and Python also display low medians (1.7 ms and 6.5 ms), confirming their suitability for high-frequency “glue” code. In contrast, custom containers show a higher median latency (≈ 43 ms).

To characterize execution and response times, we focus on Azure19, Azure21, Globus24, Huawei23, Huawei25, and IBM26, which record latency metrics. Execution Time. The median execution time of functions in modern traces (Globus24, Huawei23, Huawei25, IBM26) is low, typically ranging from 2 ms to 35 ms, as shown by the CDF in Figure 9. This represents a significant performance evolution compared to the older Azure19 trace, where the median was ≈ 140 ms (Table 4). This trend towards “nanoservice”style functions makes the relative impact of system overheads, especially cold starts, even more pronounced. To further contextualize this behavior, we also analyze the execution time aggregated by function rather than by individual request. Because the invocation frequency is highly skewed across FaaS platforms, per-request metrics are heavily dominated by a few popular, fast-running functions. When averaging execution time per function, the median increases significantly (e.g., from 31 ms to 677 ms for Azure21, and 13 ms to 131 ms for IBM26). This indicates that although the typical request is

Requests CDF

1.00 0.75

Globus24

0.50 0.25 0.00

Response Time. The end-to-end response time represents the total latency experienced by the user, which includes execution time, cold starts, queueing, and network transit. As shown in Figure 11, although the median response times for commercial platforms are low (2.9 ms for Huawei23 and 15 ms for IBM26), the distributions are heavy-tailed (Table 4). The P99 response times are often two to three orders of magnitude higher than the median. For example, Huawei25 has a median response time of 12 ms but a P99 of 1.78 s. This discrepancy

Cloud HPC Local

100

1000 10000 100000 Execution Time (ms)

3600000

Figure 10: CDF of execution time by infrastructure type in the Globus24 trace. Cloud endpoints execute sub-second tasks, whereas HPC endpoints handle heavy-tailed scientific workloads.

Table 4: Latency characterization (ms). Recent traces show double-digit millisecond median execution times and minimal system overhead (≈ 1 ms), whereas Globus24 incurs high wait times due to remote scheduling.

Dataset

Metric

Median

Mean

P95

P99

Azure19

Execution

139.84

826.39

1.7e3

9.4e3

Azure21

Execution

31.00

3.3e3

1.4e4

7.2e4

Globus24

Execution Response Overhead

32.04 339.28 112.07

4.9e4 1.4e6 4.3e5

3.8e5 5.5e5 2.0e4

6.5e5 3.2e7 2.2e6

Huawei23

Execution Response Overhead

2.36 2.89 0.50

9.90 10.59 0.69

35.57 39.02 0.97

132.53 136.72 3.26

Huawei25

Execution Response Overhead

9.86 12.03 1.94

88.93 92.82 4.84

249.09 270.03 10.67

1.7e3 1.8e3 28.42

IBM26

Execution Response Overhead

13.00 15.00 1.00

177.99 217.98 39.99

624.00 644.00 2.00

2.5e3 2.8e3 7.00

1 082 s. In serverless workloads, where the execution itself often lasts only a few milliseconds, even a moderate P95 overhead of 2–11 ms (as seen in IBM26 and Huawei25) can represent a performance penalty of 50–100% relative to the computation. For Globus24, the overhead is naturally high (median 112 ms, mean 426 s), because it includes the time tasks spend traversing the batch scheduler queues of remote endpoints, reflecting an architectural trade-off that favors high-throughput batch computing over low-latency responsiveness. Insight 3. The shift towards “nanoservices”, where median execution times are often in the double-digit milliseconds, changes the performance bottleneck of FaaS platforms. When a function executes in 2 ms, even a highly optimized system overhead of 1–2 ms imposes a 50–100% overhead. The divergence between fast executions and a heavy tail of slow, resource-intensive outliers suggests that FaaS architectures should move toward workload-aware isolation, differentiating the execution paths and resource management policies for high-volume, latency-sensitive functions versus long-running, resource-intensive outliers to prevent platform-level congestion.

indicates that although the warm start path is highly optimized, a significant minority of requests suffers from severe performance degradation due to cold starts or resource contention. Furthermore, we observe that the response time is subject to diurnal pressure, even when the execution time is relatively constant. In the IBM26 dataset, the average hourly response time fluctuates based on system load, ranging from 161 ms to 309 ms. Since the function logic itself does not change, this latency increase is attributable to platform-level congestion and queueing delays during peak load hours. In contrast, the Globus24 platform shows the extreme impact of queueing in federated and scientific systems. Although its median response time is relatively fast at ≈ 339 ms, its mean response time substantially increases to nearly 1 400 s (≈ 23 minutes), because some tasks wait in queues for HPC nodes to become available. System Overhead. We isolate the system overhead by calculating the difference between the end-to-end response time and the execution time of the function. This metric represents the “tax” paid by the user for the convenience of the serverless abstraction. We clamped negative values to zero to compensate for distributed clock skews. This correction does not affect our tail latency estimates (e.g., P95 and P99), because clock synchronization errors are orders of magnitude smaller than tail latencies. For Globus24, overhead specifically measures the queue delay before execution. Because records with missing timestamps (e.g., timeouts) are filtered independently per metric, mean overheads do not strictly equal the arithmetic difference of the mean response and execution times. As detailed in Table 4, commercial FaaS platforms have optimized this overhead to negligible levels for the median request: Huawei23, IBM26, and Huawei25 show median overheads of 0.50 ms, 1.00 ms, and 1.94 ms, respectively. This implies that for warm requests, the platform introduces almost no perceptible delay. For IBM26, although the median overhead is 1 ms, the mean is ≈ 40 ms, and the maximum observed overhead stretches to over

4.4. Instances Our analysis of instance dynamics uses Huawei23, Huawei25, and IBM26, because these traces uniquely capture active instance counts, container lifespans, and scaling configurations (e.g., concurrency limits). Instance Lifespan and Peak Instances. The lifecycle of a function instance varies significantly depending on the underlying execution model. Although traditional FaaS platforms typically enforce request isolation (one request per instance), newer platforms allow general-purpose containers to handle multiple concurrent requests. This difference is observable in the lifespan of active instances shown in Figure 12(a). Instances in the Huawei25 trace are highly ephemeral, with a 90th percentile lifespan of only 45 s. This aligns with a requestisolated model where instances are provisioned on-demand and reclaimed shortly after execution. In contrast, the IBM26 trace shows significantly greater persistence with a heavy tail: The 90th percentile reaches over 7 days (6.16 × 105 s) and some instances persist for as long as the full duration of the trace (≈ 9.5 weeks). Despite these long-running instances, the overall median instance lifespan in the IBM26 trace remains relatively low at ≈ 284 s. Concurrency and Scale. The capacity to process multiple requests within a single instance alters the relationship between the volume of requests and the required infrastructure. Figure 12(b) compares the peak concurrent instances per function. The Huawei23 trace shows a higher propensity to scale out, with a 99th percentile of ≈ 90 instances per function. This is characteristic of request-isolated platforms, where high throughput requires a linear increase in pod count. In contrast, the IBM26 9

0.00

0.25 0.00

1m 1h 1d 1w Active Instance Lifespan (s)

(a) Active Instance Lifespan

Huawei23 Huawei25 IBM26

10 100 1000 10000 Peak Concurrent Instances

(b) Peak Concurrent Instances

0.50 0.25 0.00

250 500 750 1000 Instance Concurrency Limit

(a) Instance Concurrency Limit

0.50 0.25 0

0 25 50 75 100 Memory Usage (%)

0.00

0.004

0.002

25 0

0 25 50 75 100 Memory Usage (%)

0.000

(b) Huawei25

4.5. Resource Usage We evaluate resource utilization and provisioning in Azure19, Alibaba21, Huawei23, Huawei25, and IBM26, which are the only traces that provide data on allocated limits and/or CPU and memory usage. Memory and CPU Usage. The analysis of the Huawei23 and Huawei25 traces shows a pattern of resource overprovisioning, although its severity varies. Figure 14 presents a density plot of CPU utilization versus memory utilization. For Huawei23, a dense cluster is visible at low utilization, with functions that use less than 15% of allocated memory and less than 5% of allocated CPU. This severe over-provisioning likely stems from the lack of direct cost constraints in this private cloud environment. In contrast, Huawei25 being a public platform shows improved relative utilization, featuring a distinct vertical band at ≈ 25% memory usage and a wider spread of CPU utilization. Nevertheless, the fact that most functions still use significantly less than their allocated bounds points to widespread resource inefficiency. Table 5 quantifies the memory usage. The memory usage for Huawei25 is low, with a median of only 34 MB and a 99th percentile (P99) of just 423 MB. This supports the assumption that the majority of functions are lightweight and good candidates for snapshotting, which benefits from small memory footprints. However, the distribution has a long tail, with maximum usage reaching over 19 GB, indicating the presence of rare, memoryintensive outliers that require distinct management strategies. In contrast, Huawei23 shows higher absolute usage (median ≈ 320 MB), whereas Azure19 falls between the two with a median usage of 152 MB and a tighter overall distribution. Memory and CPU Limits. This inefficiency is further shown by comparing the resource usage with the configured limits. Figure 15 shows the CDF of the memory and CPU limits. For Huawei25, the median memory limit is 128 MB (Table 5), which is nearly 4× higher than the median usage of 34 MB. Similarly, Alibaba21 shows a median limit of 512 MB. IBM26 and Huawei23 show much higher configurations, with median memory limits of ≈ 2 GB. This disparity suggests that users often default to generous allocations or lack the tools to right-size their functions. CPU limits follow a similar trend. Huawei25 has a median limit of 0.3 cores, but the median usage is only 0.09 cores (Table 5). IBM26 users configure a median of 1 core, whereas

0.75

0.00

0.01

100

Figure 14: Density of CPU vs. memory utilization. Huawei23 (left) shows extreme over-provisioning with a dense cluster near 0% for both resources. Huawei25 (right) shows improved relative utilization, with memory usage clustering sharply at ≈ 25% and a wider spread in CPU utilization.

1.00 Functions CDF

Default (100)

Functions CDF

0.75

(a) Huawei23

Figure 12: Instance dynamics. (a) IBM26 containers persist for days due to concurrency mechanics and minimum scale configurations, whereas Huawei25 instances are highly ephemeral. (b) Consequently, IBM26 workloads require fewer simultaneous instances (P99 of 6) compared to Huawei23 (P99 of 90) to handle traffic peaks.

1.00

0.02

Density

0.50

100

CPU Usage (%)

Huawei25 IBM26

0.25

0.75

Density

0.50

CPU Usage (%)

1.00

0.75

Functions CDF

Instances CDF

1.00

5 10 15 Minimum Instance Scale

(b) Minimum Instance Scale

Figure 13: Instance configuration for IBM26. (a) 90% of users use the default concurrency limit of 100 requests per instance. (b) Over 50% of workloads are configured with a minimum scale ≥ 1, opting out of scale-to-zero.

trace indicates that 90% of applications never exceed two active instances. Two configuration factors drive this combined behavior of increased longevity and low peak instances in the IBM26 workload. First, the platform relies on an instance concurrency limit. As shown in Figure 13(a), the median of the configured limit is 100 requests per instance. By multiplexing requests onto a single container, the platform absorbs traffic bursts without scaling out the number of pods, while overlapping requests naturally reset idle timers and extend the instance’s lifespan. Second, users actively use the minimum instance scale configuration to address their requirements. Our analysis in Figure 13(b) indicates that the median minimum scale is 1, which means that at least 50% of workloads effectively opt out of the scale-to-zero model to maintain readiness. This model reduces the aggregate memory footprint and cold start frequency compared to the 1 : 1 mapping of request-isolated platforms, although it introduces the potential for resource contention within a single instance if not properly tuned. Insight 4. Although the low median lifespan of instances confirms that many functions remain ephemeral, the operational reality of modern serverless computing is converging with traditional PaaS: Users are deploying long-lived, concurrent containers to ensure readiness, using the FaaS platform primarily for its simplified deployment and burst-handling capabilities rather than for ephemeral requests and perrequest billing. 10

Median

Mean

P95

P99

Max

152

163

240

398

1 368

Alibaba21

Limit

512

612

1 536

3 072

32 768

Huawei23

Usage Limit

320 1 963

895 3 562

4 248 8 000

8 766 31 963

9 713 32 000

Huawei25

Usage Limit

34 128

64 343

115 1 024

423 4 096

19 338 32 768

IBM26

Limit

2 048

2 725

4 096

16 384

49 152

Usage Limit

0.01 1.43

0.05 1.88

0.30 4.73

0.39 7.98

0.75 9.69

Huawei25

Usage Limit

0.09 0.30

0.14 0.47

0.30 1.00

0.86 3.40

6.51 25.80

IBM26

Limit

1.00

0.78

1.00

4.00

8.00

0.75 0.50 Huawei23 Huawei25 IBM26

0.25 0.00

2 4 6 CPU Limit (Cores)

(b) CPU Limit

Figure 15: CDFs of configured resource limits. (a) Huawei25 and Alibaba21 favor small memory allocations (< 512 MB), whereas IBM26 and Huawei23 use larger containers (≈ 2 GB). (b) CPU limits show a similar split, with IBM26 defaulting to 1 core.

CPU (Cores) Huawei23

Alibaba21 Huawei23 Huawei25 IBM26 13 14 15

0.25

1.00

(a) Memory Limit

Functions CDF

Usage

0.50

0.00 7 8 9 10 11 12 2 2 2 2 2 2 2 2 Memory Limit (MB)

Memory (MB) Azure19

0.75

Functions CDF

Metric

1.00

Functions CDF

Dataset

Functions CDF

Table 5: Resource usage and limits. Comparing memory and CPU consumption against configured limits shows significant over-provisioning across platforms. Limits are often set generously, and actual usage is typically much lower.

0.75 0.50 Memory CPU

0.25 0.00

25 50 75 Resource Usage (%)

(a) Huawei23

100

1.00 0.75 0.50 Memory CPU

0.25 0.00

25 50 75 Resource Usage (%)

100

(b) Huawei25

Figure 16: CDFs of resource utilization (as % of allocated). While Huawei23 functions predominantly use less than 20% of their allocations, Huawei25 shows higher relative utilization, including a sharp increase at ≈ 25% memory usage.

Huawei23 users configure a median of ≈ 1.4 cores. In Figure 16, the gap between these limits and the low utilization (often below 10% in Huawei23) confirms substantial room for optimization, although newer platforms such as Huawei25 push limits closer to actual usage.

ecuted in managed runtimes, despite the higher startup costs associated with the JVM. Custom containers remain a persistent minority (≈ 2.4– 2.5%), likely due to the performance penalties associated with unmanaged initialization. For custom runtimes, which accounted for 1.7% in Alibaba21, there is no information provided in the Huawei25 trace.

Insight 5. The prevalent underutilization of resources suggests that providers can co-locate more functions on the same physical hardware through resource oversubscription. Furthermore, platforms should provide developers with automated “right-sizing” recommendations based on historical usage data to reduce costs and improve cluster efficiency.

Insight 6. Reducing interpreter startup overhead and caching commonly used libraries can provide performance improvements, because Python represents the majority of functions. At the same time, the growing share of Java makes snapshotting techniques important for addressing the relatively expensive initialization of the JVM.

4.6. Runtimes The runtime environment determines both the initialization overhead and the execution performance of serverless functions. We compare function runtimes using Alibaba21 and Huawei25 in Table 6, because they are the only traces that publish runtime metadata. Alibaba21 only logs cold starts, so its distribution reflects initialized functions rather than all functions and potentially skews results. In both traces, Python is the dominant runtime, accounting for 46.8% of functions in the Alibaba21 trace and 65.6% in the more recent Huawei25 trace. This aligns with the broader popularity of Python for data-centric tasks and general scripting. We observe a shift in other runtimes. Although Node.js was a popular runtime in the previous Alibaba21 dataset (34.6%), its share drops to 6.6% in Huawei25. Similarly, PHP usage declines from 7.6% to 1.6%. In contrast, Java usage has tripled, rising from 6.2% in Alibaba21 to 18.6% in Huawei25. This indicates a growing reliance on statically typed languages ex-

4.7. Imported Libraries & Function Code Metrics The Globus24 dataset provides function-level metrics for the number of package imports, lines of code (LoC), and cyclomatic complexity. This platform exclusively supports Python functions, which naturally shapes these specific code and dependency characteristics. Figure 17(a) shows that dependency trees are shallow: Over 90% of functions import one or two libraries, with two imports being overwhelmingly the most common (≈ 80%). The median function has only 15 lines of code, and the median cyclomatic complexity is 2. This distribution suggests that developers primarily use FaaS for lightweight coordination or simple processing tasks rather than complex, monolithic application logic. 11

Table 6: Distribution of function runtimes. Python remains the primary runtime and Java usage increases significantly in the newer Huawei dataset, whereas usage of Node.js and PHP drops significantly.

Runtime Python Node.js Java PHP Custom Container Custom Runtime .NET (C#) Go Others Unknown

Alibaba21 (% Functions)

Table 7: Distribution of function triggers. Timer triggers have surpassed HTTP as the primary invocation source in the modern Huawei25 trace compared to the older Azure19 trace.

Huawei25 (% Functions) 46.8 34.6 6.2 7.6 2.5 1.7 0.6 0.03 0.03 –

Trigger

65.6 6.6 18.6 1.6 2.4 – 0.2 0.9 3.0 1.3

Azure19 (% Functions)

HTTP Timer Queue Orchestration Event Storage Others

To understand how these metrics impact performance, we computed the Spearman correlation between them and the endto-end response time. Figure 17(b) visualizes the results. The number of imports shows a positive correlation (0.28) with the response time, suggesting that functions with more dependencies tend to have higher latency, likely due to increased initialization overhead. Heavy dependency chains increase initialization time, contributing to the long-tail latency distribution discussed in Section 4.2. Counterintuitively, both LoC (−0.30) and cyclomatic complexity (−0.40) show a moderate negative correlation with response time. This suggests that in this scientific workload, longer or more complex code does not necessarily result in longer end-to-end response times. A plausible explanation is that such functions are often I/O-bound or used for orchestration, where compute time is not the dominant factor, whereas short scripts might invoke heavy computation through external library calls. As expected, LoC and cyclomatic complexity are strongly correlated with each other (0.87).

41.9 27.6 14.6 7.9 2.6 2.2 3.3

36.9 42.2 0.1 2.2 1.8 2.5 14.2

Resp. Time (s) 1.00 0.28 -0.30 -0.40

1.00 Functions CDF

Huawei25 (% Functions)

Imports 0.28 1.00 0.20 -0.09

0.75

Lines of Code -0.30 0.20 1.00 0.87

0.50

Cyc. Complexity -0.40 -0.09 0.87 1.00

0.25 0.00

1 2 Imports

(a) Imported Libraries

sp Re

s) orts ode xity p C le Im s of omp e C n i . L yc C

( me

0 −1

(b) Response Time Correlation

Figure 17: Imported libraries, lines of code, and cyclomatic complexity of functions in the Globus24 trace. (a) The majority of functions have one or two dependencies. (b) Spearman correlation matrix for function code metrics and response time. The number of imports is the only code metric positively correlated with latency.

vocations. Timer triggers increased from 27.6% in Azure19 to 42.2% in Huawei25, surpassing HTTP (36.9%) as the primary invocation source in the newer dataset. This trend aligns with our findings in Section 4.6 regarding the decline in webcentric technologies (Node.js, PHP). Together, these shifts suggest that FaaS is increasingly used for scheduled background tasks and orchestration rather than solely for user-facing web APIs. Queue-based triggers, which were significant in Azure19 (14.6%), appear negligible in the Huawei25 dataset (0.1%), although this disparity may partly reflect platform categorization differences where internal messaging is grouped under “Others” (14.2%).

Insight 7. The number of dependencies is a better predictor of response time than the size or complexity of the code itself. This suggests that cold start optimizations should prioritize efficient dependency loading, caching, and layer sharing over simple code size reduction. The combination of shallow dependency trees and popular runtimes (e.g., Python), creates a clear opportunity for package-aware caching. Since most functions rely on a small set of libraries, providers can provision base images pre-loaded with high-frequency packages to eliminate this overhead.

Insight 8. The shift from HTTP to timer triggers allows providers to treat resource allocation as a planning problem rather than a prediction problem. Serverless workloads are becoming less driven by user interactions and more by scheduled machine tasks.

4.8. Triggers Trigger mechanisms define the arrival patterns of function invocations. We analyze trigger mechanisms in Azure19 and Huawei25, which provide categorized distributions of invocation sources. Table 7 compares the trigger distributions between the older Azure19 dataset and the modern Huawei25 dataset to illustrate the evolution of usage patterns. We observe a distinct shift from HTTP-dominated workloads to timer-based in-

4.9. Data Interaction & I/O Serverless functions interact with external storage services to maintain state, process datasets, or log results. We analyze the Azure20 trace, which captures interactions between functions and Azure Blob Storage, to characterize these I/O patterns, focusing on object sizes, access frequencies, and temporal regu12

Blob Access CDF

1.00

1.42 TB 108 GB Binary 702 GB Archive 541 MB 355 GB Unknown 37.4 MB JSON/XML 4.94 MB 129 GB Operation 50.0 GB Text 61.8 MB Read 24.5 GB Document 107 MB Write 11.9 GB Image 111 KB 0B 250 GB 500 GB 750 GB 1.00 TB 1.25 TB 1.50 TB

0.75 0.50

Read Write All

0.25 0.00 1B

1 KB

1 MB

1 GB

Blob Size

Figure 20: Transfer volume by content type (Azure20). Volume is heavily dominated by Binary, Unknown, and Archive blobs, with significantly smaller contributions from structured formats like JSON/XML and Text.

Figure 18: Blob Object Sizes (Azure20). Reads show a heavier tail than writes, whereas writes have a significantly larger median size.

0.75 Invocations/Blob Invocations Blobs

0.25 0.00 0.01

0.1

10 100 1 K 10 K 100 K 1 M 10 M Invocations per Blob

Mean

Median

P95

P99

68 426 46 278

11 049

1 10 100 1000 10000 Request Body Size (KB)

0.50 0.25 0.00 −6 10

Read Body Write Response

10−4 10−2 I/O Latency (s)

(b) I/O Latency (Huawei25)

CV than 376 000 times. This skewed distribution suggests that although most data is transient, a small tail of objects dominates the I/O throughput. Further analysis reveals that data sharing across applications is minimal. Specifically, 99.5% of all blobs are bound to a single application. Even for “hot” blobs (those accessed 10 or more times), this figure remains high at nearly 89%. Consequently, contention is heavily localized within individual application boundaries rather than broadly distributed across the platform. Temporal Regularity. We analyzed the regularity of data accesses using the coefficient of variation (CV) of inter-arrival times (IAT). Data access patterns show moderate burstiness rather than strict regularity. The median IAT CV is 1.23, with a mean of 1.20. A CV > 1 indicates that data accesses are generally more clustered/bursty than a Poisson process (random arrivals), contradicting the assumption that storage I/O is purely periodic (i.e., CV ≈ 0). This suggests that data caching policies should be resilient to irregular and bursty access intervals rather than relying on predictable schedules. Transfer Volume by Blob Category. To understand what types of data dominate Azure Functions storage traffic, we group each access by high-level Blob Category and aggregate transferred bytes from Azure20. Figure 20 shows that the overall volume is heavily skewed toward Binary and Unknown payloads. Binary objects total ≈ 1.4 TB for reads and 108 GB for writes. This category is primarily driven by the default content type assigned by the Azure Functions platform when users do not explicitly specify one, indicating that most bandwidth is spent moving opaque binary objects. Unknown payloads (objects that lack a specific content type) account for a massive 355 GB for writes, but only ≈ 37 MB for reads. Archive formats (e.g., zip/compressed), contribute the next largest share

28 1 436

36 242 23 320

725 398 147 476

25.9 42.1

1.1

14 491

376 762

7.5

Access Frequency Inv. per Blob

0.75

Figure 21: Request body size and I/O latency. (a) The CDF of request body sizes in the Globus24 trace is dominated by small control messages, but features an extreme tail of larger payloads. (b) The I/O latency for Huawei25 shows that reading request bodies dominates the frontend overhead compared to writing rapid responses.

Size per Access (Bytes) Read Size Write Size

Globus24 Huawei25

0.25

(a) Request Body Size

Table 8: Blob access statistics (Azure20). Read operations show a heavier tail distribution than writes, whereas the Coefficient of Variation (CV) for interarrival times indicates bursty access patterns (CV > 1).

Metric

0.50

0.00

Figure 19: Data ephemerality and contention (Azure20). The median blob is accessed only once, indicating high data ephemerality, whereas the long tail represents highly contended shared objects.

1.00

0.75

Requests CDF

1.00

0.50

Requests CDF

Apps CDF

1.00

larity. Furthermore, we use the Globus24 and Huawei25 traces to examine payload sizes and I/O latency. External Storage Access Patterns. Figure 18 illustrates the Cumulative Distribution Function (CDF) of blob sizes for read and write operations. The distribution is heavy-tailed, spanning nine orders of magnitude from bytes to gigabytes. Table 8 presents the statistical summary of these accesses. An inversion exists between the mean and median values for reads versus writes. The median write size (1 436 B) is larger than the median read size (28 B), likely due to functions writing structured logs or state checkpoints compared to reading tiny configuration files or metadata. However, the mean read size (68 KB) exceeds the mean write size (46 KB), driven by the long tail of large object reads (e.g., media files or ML models). The 99th percentile for reads is nearly 5× higher than that for writes. Data Access Frequency. Figure 19 depicts the distribution of access frequencies (invocations per blob). The data show that the majority of storage objects are ephemeral. The median number of invocations per blob is ≈ 1.1, indicating that at least 50% of objects are accessed only once during the trace period. Conversely, the distribution tail is long. The mean is 11 049 invocations, and the top 1% of blobs (P99) are accessed more 13

0.75 0.50

Azure19 Azure20 Huawei25 IBM26

0.25 0.00

Table 9: User tenancy and workload distribution. Commercial platforms generally host many users with few functions (low median), but request volume is heavily skewed toward a small fraction of high-volume users (high CV and Max).

1.00

10 102 103 104 Functions per User

(a) Functions per User

105

Users CDF

1.00

0.75

Azure19 Azure20 Globus24 Huawei25 IBM26

0.50 0.25 0.00

Dataset

10 103 105 107 109 Daily Requests per User

Median

Mean

Max

4.9 1.7 7.6 7.6

4.8 1.2 15.1 1.2

2 242 26 4 757 58

6.1e4 4.7e3 38.8 1.6e6 2.0e5

26.3 10.4 6.1 19.5 5.7

1.3e8 1.0e6 3.1e3 9.2e8 1.2e7

Functions per User

(b) Daily Requests per User

Azure19 Azure20 Huawei25 IBM26

Figure 22: Functions and daily requests per user. Both distributions show heavy tails, demonstrating that a minority of users accounts for the majority of both registered functions and system invocations.

2 1 2 5

Daily Requests per User Azure19 Azure20 Globus24 Huawei25 IBM26

for reads at about 700 GB (despite fewer than 100 000 accesses), suggesting the packaging of dependencies or datasets. JSON/XML traffic contributes ≈ 130 GB, and Text traffic contributes ≈ 50 GB. Notably, although Text and JSON/XML formats represent the majority of individual accesses (over 25 million combined), their small average sizes limit their total bandwidth footprint compared to the fewer but much larger Binary, Unknown, and Archive blobs. Spatially, this transfer volume is dense: Among the 28 regions studied, the top 4 regions account for more than 86% of the total data transfer volume. Overall, the size distribution indicates that bandwidth demand is driven primarily by binary and compressed objects rather than by strongly typed, human-centric content.

77.3 4.6 0.1 4.0 690.0

Insight 9. The dichotomy between the high volume of ephemeral data and the small set of highly frequent objects suggests that traditional LRU caching policies are ineffective for the majority of FaaS I/O, because they will be polluted by single-access objects across tenants. Instead, caching strategies should be sizeaware and selective to mitigate the severe tail latencies associated with transferring large payloads. Furthermore, because nearly 90% of highly accessed objects are bound to a single application, providers can largely rely on application-scoped localized caching tiers rather than cross-tenant distributed caches.

Request Body Size. The Globus24 and Huawei25 traces provide insight into the data transfer characteristics of scientific and commercial FaaS workloads, respectively, by capturing the size of function arguments (request bodies). Figure 21(a) illustrates the CDF of these request sizes. For the scientific Globus24 workload, the distribution is heavily skewed: Although the median request size is small at 60 B, the mean is significantly larger at ≈ 16.9 KB. This disparity is driven by a long tail of data-intensive invocations where the P99 reaches 129 KB and the maximum exceeds 10 MB (CV ≈ 12.4). This aligns with “bag of tasks” use cases where functions occasionally receive large data payloads. In contrast, the commercial Huawei25 trace shows a larger median of 1.13 KB but a smaller coefficient of variation (CV ≈ 4.0), suggesting more consistent payload sizes typical of standardized web APIs, although it still shows a heavy tail with a P99 of 319 KB.

4.10. Users We characterize the tenancy patterns of FaaS platforms by analyzing the number of functions registered per user and the request volume generated by each user. This analysis helps to understand user behavior and the structural composition of the workload, which is essential for capacity planning. We use Azure19, Azure20, Globus24, Huawei25, and IBM26, because these datasets include anonymized user identifiers allowing peruser aggregation. Functions per User. Figure 22(a) presents the CDF of the number of functions registered by individual users. We exclude Globus24 from this analysis because its trace logs the user submitting the task rather than the owner of the function. The distribution is heavily skewed toward users with few functions. As detailed in Table 9, platforms such as Azure19, Azure20, and Huawei25 typically show a median of only 1 or 2 functions per user. This suggests that a substantial portion of the user base consists of developers deploying simple applications or microservices with stable configurations. IBM26 has a slightly higher median of 5 functions, but shows a tight distribution (CV ≈ 1.2) with a maximum of only 58 functions, reflecting a container-centric model where users deploy a constrained set of related services rather than distributed function architectures.

I/O Latency. To understand the network overhead of transferring data in and out of functions, we analyze the frontend I/O latencies from the Huawei25 trace in Figure 21(b). Frontend I/O is highly optimized. Writing responses is nearly instantaneous, showing a median latency of just 7.4 µs and a P99 of 11.4 µs. This tight distribution indicates that function outputs in this environment are typically small (e.g., status codes or acknowledgments). In contrast, reading request bodies shows a noticeably heavier tail. Although the median read latency is still low at 26 µs, the mean is 301 µs, and the P99 latency reaches 6.2 ms. This disparity directly correlates with the skewed request body sizes observed earlier. Most incoming payloads are tiny, whereas the tail of larger data payloads requires significantly more time to transfer. 14

Daily Requests per User. The disparity in workload intensity among users is pronounced. Figure 22(b) illustrates the CDF of average daily requests per user, showing a heavy-tailed distribution across all datasets. Table 9 shows the magnitude of this inequality. For Huawei25, the median user sends only 4.0 requests per day, but the mean is 1.56 million, driven by high-volume users that generate up to 915 million daily requests (CV ≈ 19.5). Azure19 follows a similar trend, where the mean daily request count (60 797) is nearly three orders of magnitude higher than the median (77.3). IBM26 stands out with a significantly higher baseline, showing a median of 690 daily requests, although it still exhibits a heavy tail with a maximum of 11.6 million daily requests. Azure20, tracking specific storage interactions, mirrors this high skew (CV ≈ 10.4) despite a low median of 4.6 daily requests. Globus24 shows a lower overall volume consistent with sporadic scientific processing (median 0.1 daily requests), yet maintains a high coefficient of variation (CV ≈ 6.1). This confirms that even in scientific computing, a small fraction of users drives the majority of the system load, whereas most users submit tasks sporadically.

Finally, the extreme skew in function popularity, per-user request volumes, and data access volume has direct implications for keep-alive and eviction strategies. High-volume “whale” users naturally keep their functions warm, whereas the long tail of low-volume users generates the majority of cold starts and resource fragmentation. Platforms should therefore apply asymmetric policies: sustained keep-alive for popular functions and aggressive idle-resource reclamation for the long tail, with per-function keep-alive windows tuned to empirical IAT distributions. 5.2. Implications for FaaS Benchmark Design A recurring theme across all datasets is that summary statistics such as mean or median are poor representatives of production workloads. Execution times, cold start latencies, request patterns, and other characteristics all show heavy tails. Therefore, simple generative models fail to capture the characteristics of serverless workloads. Future benchmarks should adopt trace-driven replay to accurately reflect these structural and temporal dynamics. Furthermore, we emphasize the importance of multi-trace evaluation. An algorithm tuned to an older trace (e.g., Azure19) will likely fail under the high-concurrency workloads of IBM26 or the scientific workloads of Globus24. Systems should be evaluated across multiple, diverse traces to ensure generalizability.

Insight 10. The high skew in request generation creates a dichotomy in system management. Highvolume “whale” users naturally keep their functions warm, whereas the long tail of low-volume users generates the majority of cold starts and resource fragmentation. Providers should therefore balance dedicated capacity and isolation for heavy hitters with aggressive idle-resource reclamation strategies for the long tail.

5.3. Limitations Although our study provides a general overview, it is subject to several limitations. First, we analyzed “black box” systems. The observed performance metrics are a result of both the inherent workload characteristics and the specific policies (e.g., cold start optimization, scheduling, caching) of the underlying platform. Without insight into these internal mechanisms, it is challenging to definitively separate workload effects from platform effects. For example, a low cold start rate could stem from high keep-alive times. Second, each dataset represents the user base and common use cases of a specific platform. For example, the Globus24 trace is dominated by scientific computing tasks and may therefore not be representative of Azure workloads, whereas the Huawei23 trace captures internal private-cloud workloads that may not generalize to public cloud workloads. Therefore, although we identified common patterns, generalizing findings to other FaaS platforms should be done with caution. Finally, the FaaS ecosystem is evolving rapidly. Some of our datasets, particularly Azure19, are several years old. As our comparison between the Azure19 and Azure21 traces showed, workload characteristics can change significantly in a relatively short period. Our findings represent a snapshot in time, and continuous characterization with new public datasets will be necessary to track the ongoing evolution of serverless workloads.

5. Discussion 5.1. Implications for FaaS Platform Design As function execution times have dropped to double-digit milliseconds, the relative cost of platform overhead has grown proportionally. Critically, our breakdown of cold start latency in Huawei25 shows that scheduling (mean: 1.17 s) and dependency deployment (0.95 s) dominate over code download (0.43 s). Combined with the strong positive correlation between dependency count and response time in Globus24, this points clearly toward data-aware scheduling and proactive dependency pre-fetching as higher-value targets than code-size reduction. The growing dominance of timer-based triggers (42.2% in Huawei25) and diurnal cycles further amplify this opportunity, since invocation schedules are known to the platform in advance, enabling precise rather than statistical pre-warming. The resource over-provisioning we observe represents a largely untapped efficiency gain. The IBM26 trace reinforces this direction from a different angle: The “Serverless 2.0” concurrency model, where a single container multiplexes up to 100 concurrent requests, achieves a P99 instance count of just 6 compared to 90 for the request-isolated Huawei23, demonstrating that concurrency-aware container management is a more resource-efficient path than linear scale-out.

6. Related Work Workload characterization is fundamental for understanding the behavior of serverless platforms and designing system opti15

mizations. The literature in this field mainly divides into empirical studies analyzing production traces from cloud providers and efforts to generate synthetic workloads when real-world data are unavailable. We review key contributions in both areas to contextualize our cross-platform analysis.

Our work directly addresses this gap by synthesizing the findings from these disparate traces into a unified characterization. By analyzing eight datasets spanning four major public cloud providers and a specialized scientific platform over a seven-year period, we provide a more robust and generalizable understanding of serverless workloads.

6.1. Production Workload Traces 6.2. Synthetic Workload Traces

Researchers rely on these traces to design and validate system optimizations, e.g., observed workload patterns have motivated new policies for resource management [1], caching [11], predictive pre-warming [12], autoscaling [13], and scheduling [14]. Beyond motivating new algorithms, these same traces often serve as a benchmark to evaluate the performance of algorithms by replaying real-world request patterns from a trace. Our work builds on this foundation by synthesizing insights from the key public traces that have shaped the field. The foundational work by Shahrad et al. [1] on the Azure Functions trace (Azure19) was one of the first large-scale characterizations of a production FaaS workload. The authors identified key properties such as the bimodal distribution of function lifetimes and strong diurnal patterns, which motivated their design of a predictive keep-alive policy. Many subsequent works have used this trace to evaluate new ideas, from caching techniques [11] to novel pre-warming strategies [12]. Our study re-examines this seminal work in newer traces to understand how these initial findings have evolved. Subsequent workload studies have broadened the scope to other platforms and use cases. In 2021, Romero et al. [4] released an additional Azure trace (Azure20) that specifically captured interactions with Blob Storage, allowing for the first detailed analysis of data access patterns in FaaS applications. Zhang et al. [5] released a newer Azure trace (Azure21), highlighting the prevalence of short-lived functions and exploring the potential for using “harvested” VMs. Wang et al. [6] provided a view into the Alibaba Cloud Function Compute platform (Alibaba21), which was used to inform the design of a container provisioning system. Joosen et al. have released two datasets from Huawei Cloud (Huawei23 and Huawei25) [7, 3], with the former characterizing long-term trends and the latter offering deep insights into cold start events, their internal components, and multi-region deployments. Concurrently, Bauer et al. [8] provided a unique perspective on a federated FaaS model from the scientific computing domain with the Globus Compute trace (Globus24), capturing edge-to-cloud endpoint characteristics. Recently, Nasiri et al. [9] provided a trace from the IBM Cloud Code Engine (IBM26), offering insights into a Knative-based “Serverless 2.0” environment that supports both functions and general-purpose containers alongside advanced user configurations like pod concurrency. Although these individual studies have provided snapshots, they have largely been analyzed in isolation. A few studies have performed limited comparisons of different traces, for example, Li et al. [15] referenced the burstiness characteristics of both Azure traces to motivate a system for deep learning serving. However, a comprehensive, side-by-side comparative analysis has been missing across this wide range of modern datasets.

In the absence of sufficient public production data, some research has turned to simulated or synthetic workloads. Benchmarking suites such as the Serverless Benchmark Suite (SeBS) [16] and FunctionBench [17] provide a standardized set of functions for performance evaluation, whereas SeBS also provides simulated workloads. Others have developed entire simulation platforms, such as SimFaaS [18], to predict performance metrics. Although simulated data are useful for controlled experiments, they often simplify real-world complexities and may not capture the full spectrum of behaviors such as burstiness or heavy-tailed distributions. Synthetic data can offer more realism by statistically mirroring production traces, but its quality is fundamentally dependent on the availability of representative real-world data. Therefore, these approaches cannot fully replace the analysis of large-scale production traces, which remains the “gold standard” for understanding real-world system behavior. 7. Conclusions & Future Work In this paper, we conducted a large-scale, cross-platform characterization of serverless workloads using eight publicly available FaaS workload traces. Our analysis provides a comprehensive and up-to-date view of the state of FaaS, moving beyond the reliance on single, often outdated, data sources. We found that despite the diversity of platforms, several key patterns hold true: FaaS workloads are driven by strong, predictable diurnal cycles and extreme skewness in function popularity and user request volumes. Performance is characterized by fast execution times, which are becoming increasingly short, coupled with heavy-tailed latency distributions. This makes system overheads such as cold starts even more critical to mitigate. Our analysis further showed widespread resource overprovisioning, a shift toward persistent “Serverless 2.0” concurrency models, and a dependency landscape where most functions import few libraries, pointing to clear avenues for optimization in resource allocation and data locality. To support reproducibility and further research, we have open-sourced our analysis: https://github.com/saman-akbari/characte rizing-serverless-workloads. Future work should build on these findings in two main directions: First, we encourage the development of algorithms grounded in our empirical data, such as predictive autoscalers and dependency-aware schedulers. Second, establishing a common data format for new public traces would greatly accelerate research and help the community track the ongoing evolution of serverless computing. 16

Acknowledgments

[9] N. Nasiri, N. Munshi, S. D. Moser, M. Pirvu, V. Sundaresan, D. Maier, T. Premnath, N. Böwing, S. Gopalakrishnan, M. Shahrad, In-production characterization of an open source serverless platform and new scaling strategies, in: Proceedings of the ACM European Conference on Computer Systems (EuroSys), 2026.

We thank Jonathan Wörner who supported this work in the scope of a bachelor’s thesis. References

[10] Dask Development Team, Dask: Library for dynamic task scheduling (2016). URL https://www.dask.org/

[1] M. Shahrad, R. Fonseca, Í. Goiri, G. Chaudhry, P. Batum, J. Cooke, E. Laureano, C. Tresness, M. Russinovich, R. Bianchini, Serverless in the wild: Characterizing and optimizing the serverless workload at a large cloud provider, in: Proceedings of the USENIX Annual Technical Conference (ATC), 2020, pp. 205–218, trace released in 2019.

[11] A. Fuerst, P. Sharma, FaasCache: keeping serverless computing alive with greedy-dual caching, in: Proceedings of the ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2021, pp. 386–400.

[2] Amazon Web Services, AWS Lambda (2014). URL https://aws.amazon.com/lambda/

[12] R. B. Roy, T. Patel, D. Tiwari, IceBreaker: Warming serverless functions better with heterogeneity, in: Proceedings of the ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2022, pp. 753–767.

[3] A. Joosen, A. Hassan, M. Asenov, R. Singh, L. Darlow, J. Wang, Q. Deng, A. Barker, Serverless cold starts and where to find them, in: Proceedings of the ACM European Conference on Computer Systems (EuroSys), 2025, pp. 938–953.

[13] H. Qiu, W. Mao, C. Wang, H. Franke, A. Youssef, Z. T. Kalbarczyk, T. Başar, R. K. Iyer, AWARE: Automate workload autoscaling with reinforcement learning in production cloud systems, in: Proceedings of the USENIX Annual Technical Conference (ATC), 2023, pp. 387–402.

[4] F. Romero, G. I. Chaudhry, Í. Goiri, P. Gopa, P. Batum, N. J. Yadwadkar, R. Fonseca, C. Kozyrakis, R. Bianchini, Faa$t: A transparent auto-scaling cache for serverless applications, in: Proceedings of the ACM Symposium on Cloud Computing (SoCC), 2021, pp. 122–137.

[14] S. Akbari, M. Hauswirth, Hiku: Pull-based scheduling for serverless computing, in: Proceedings of the IEEE International Symposium on Cluster, Cloud and Internet Computing (CCGrid), 2025, pp. 450–461.

[5] Y. Zhang, Í. Goiri, G. I. Chaudhry, R. Fonseca, S. Elnikety, C. Delimitrou, R. Bianchini, Faster and cheaper serverless computing on harvested resources, in: Proceedings of the ACM Symposium on Operating Systems Principles (SOSP), 2021, pp. 724–739.

[15] Z. Li, L. Zheng, Y. Zhong, V. Liu, Y. Sheng, X. Jin, Y. Huang, Z. Chen, H. Zhang, J. E. Gonzalez, I. Stoica, AlpaServe: Statistical multiplexing with model parallelism for deep learning serving, in: Proceedings of the USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2023, pp. 663–679.

[6] A. Wang, S. Chang, H. Tian, H. Wang, H. Yang, H. Li, R. Du, Y. Cheng, FaaSNet: Scalable and fast provisioning of custom serverless container runtimes at Alibaba Cloud Function Compute, in: Proceedings of the USENIX Annual Technical Conference (ATC), 2021, pp. 443–457.

[16] M. Copik, G. Kwasniewski, M. Besta, M. Podstawski, T. Hoefler, SeBS: a serverless benchmark suite for function-as-a-service computing, in: Proceedings of the ACM/IFIP Middleware Conference, 2021, pp. 64–78.

[7] A. Joosen, A. Hassan, M. Asenov, R. Singh, L. Darlow, J. Wang, A. Barker, How does it function? Characterizing long-term trends in production serverless workloads, in: Proceedings of the ACM Symposium on Cloud Computing (SoCC), 2023, pp. 443–458.

[17] J. Kim, K. Lee, FunctionBench: A suite of workloads for serverless cloud function service, in: Proceedings of the IEEE International Conference on Cloud Computing (CLOUD), 2019, pp. 502–504.

[8] A. Bauer, H. Pan, R. Chard, Y. Babuji, J. Bryan, D. Tiwari, I. Foster, K. Chard, The Globus Compute dataset: An open function-as-a-service dataset from the edge to the cloud, Future Generation Computer Systems 153 (2024) 558–574.

[18] N. Mahmoudi, H. Khazaei, SimFaaS: A performance simulator for serverless computing platforms, in: International Conference on Cloud Computing and Services Science (CLOSER), 2021, pp. 23–33.

Characterizing Serverless Workloads: A Large-Scale Analysis of Function-as-a-Service Platforms

Analyze & explore related research in Conceptio

Related documents