Provuse: Platform-Side Function Fusion for Performance and Efficiency in FaaS Environments

TL;DR

Results indicate that automatic function fusion is an effective platform-side strategy for reducing latency and RAM consumption in composed FaaS applications, highlighting the potential of transparent infrastructure-level optimizations in serverless systems.

Abstract

Function-as-a-Service (FaaS) platforms provide scalable and cost-efficient execution but suffer from increased latency and resource overheads in complex applications comprising multiple functions, particularly due to double billing when functions call each other. This paper presents Provuse, a transparent, platform-side optimization that automatically performs function fusion at runtime for independently deployed functions, thereby eliminating redundant function instances. This approach reduces both cost and latency without requiring users to change any code. Provusetargets provider-managed FaaS platforms that retain control over function entry points and deployment artifacts, enabling transparent, runtime execution consolidation without developer intervention. We provide two implementations for this approach using the tinyFaaS platform as well as Kubernetes, demonstrating compatibility with container orchestration frameworks. An evaluation shows consistent improvements, achieving an average end-to-end latency reduction of 26.33% and a mean RAM usage reduction of 53.57%. These results indicate that automatic function fusion is an effective platform-side strategy for reducing latency and RAM consumption in composed FaaS applications, highlighting the potential of transparent infrastructure-level optimizations in serverless systems.

Figures (6)

• Figure 1: Function Fusion optimizes FaaS applications for latency and resource efficiency by colocating developer-defined functions across fewer runtimes, allowing function calls to be inlined rather than executed via remote invocation.
• Figure 2: Design of the optimized FaaS platform. The Function Handler is deployed together with function code, waiting for requests to invoke functions and monitoring outgoing requests to invoke the merging process. The Merger interacts with the container runtime to extract file systems and build new function instances hosting the code of multiple functions.
• Figure 3: Call graph of the Fusionize++ IoT application schirmer2024fusionizepp. Solid edges denote synchronous invocations, dashed edges asynchronous execution. The workflow starts at AnalyzeSensor (I), combining sequential steps with parallel analysis of temperature, air quality, and traffic. Dashed shapes indicate the theoretical fusion groups that would result from fusing synchronous calls.
• Figure 4: Call graph of the TREE application from Fusionize++ schirmer2024fusionizepp, highlighting theoretical fusion groups based on synchronous calls with a dashed line. A synchronously invokes B, which calls D and E, while A also triggers an asynchronous branch via C to F and G. The asynchronous path dominates the workload, requiring far more computation than the synchronous branch.
• Figure 5: Time series of end-to-end latency for the IOT application on tinyFaaS. The vanilla deployment consistently exhibits higher latencies, while the function fusion deployment achieves a 28.9% latency reduction. The vertical lines represent the finished merge event, where a new combined function instance is healthy and running.