Joint Optimization of Parallelism and Resource Configuration For Serverless Func

560 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 35, NO.
4, APRIL 2024
Joint Optimization of Parallelism and Resource

Configuration for Serverless Function Steps
Zhaojie Wen , Qiong Chen , Yipei Niu , Zhen Song , Quanfeng Deng ,
and Fangming Liu , Senior Member, IEEE
Abstract—Function-as-a-Service (FaaS) offers a fine-grained re- only need to focus on business logic, which accelerates appli-
source provision model, enabling developers to build highly elastic cation development progress and saves operational costs. With
cloud applications. User requests are handled by a series of server- FaaS platforms like AWS Lambda [3], developers can rapidly
less functions step by step, which forms a multi-step workflow. The
developers are required to set proper configurations for functions leverage hundreds of CPU cores by invoking massive functions
to meet service level objectives (SLOs) and save costs. However, simultaneously.
developing the configuration strategy is challenging. This is mainly Benefiting from the fine-grained, high elasticity of FaaS, many
because the execution of serverless functions often suffers from applications have been developed based on serverless functions,
cold starts and performance fluctuation, which requires a dynamic including video processing [4], [5], [6], machine learning [7],
configuration strategy to guarantee the SLOs. In this article, we
present StepConf, a framework that automates the configuration [8], [9], [10], code compilation [11], big-data analytic [12], [13],
as the workflow runs. StepConf optimizes memory size for each [14], [15], [16], etc. To migrate applications to FaaS platforms,
function step in the workflow and takes inter and intra-function developers need to decouple monolithic applications into multi-
parallelism into consideration, which has been overlooked by ex- ple functions, resulting in complex multi-step serverless work-
isting work. StepConf intelligently predicts the potential configu- flows. However, developers face challenges in setting proper
rations for subsequent function steps, and proactively prewarms
function instances in a configuration-aware manner to reduce the configurations for workflows to optimize the cost and ensure
cold start overheads. We evaluate StepConf on AWS and Knative. performance. We summarize these challenges as follows:
Compared to existing work, StepConf improves performance by Vague Impact of Resource Configurations: The cost and
up to 5.6× under the same cost budget and achieves up to a 40% performance of functions in FaaS depend heavily on user-
cost reduction while maintaining the same level of performance. configured resource parameters. However, due to the unique
Index Terms—Serverless computing, resource management, resource allocation and pricing mechanisms of FaaS platforms,
resource configuration, function workflow. understanding the impact of resource configuration can be chal-
lenging. Therefore, it is difficult to determine the appropriate
resource parameters to achieve high performance and low cost.
I. INTRODUCTION As a result, developers often struggle to determine the optimal
UNCTION-AS-A-SERVICE (FaaS) is a new paradigm for resource configuration for their workflows [17], [18], [19].
F serverless computing that allows developers to run code
in the cloud without having to maintain and operate cloud
Performance Fluctuations in Workflows: FaaS frequently de-
pend on external storage services to enable extensive data ex-
resources [1], [2]. Developers need only submit function code change in workflows [20], [21]. Nevertheless, these external ser-
to FaaS platforms, where compute resources are provisioned vices demonstrate considerable variations in data transmission
and functions are executed seamlessly. Therefore, developers delay, ranging from a few hundred milliseconds to a couple of
seconds. Additionally, function cold starts prevent concurrent
mapping invocations from starting simultaneously, leading to
Manuscript received 2 July 2023; revised 16 December 2023; accepted 8
February 2024. Date of publication 13 February 2024; date of current version different mapping delays. These factors introduce fluctuations
28 February 2024. This work was supported in part by National Key Research in the performance of function steps, rendering it difficult to
& Development (R&D) Plan under Grant 2022YFB4501703, and in part by ensure end-to-end SLOs for workflows concerning configuration
the Major Key Project of PCL under Grant PCL2022A05. Recommended for
acceptance by J. Carretero Perez. (Corresponding author: Fangming Liu.) optimization.
Zhaojie Wen, Yipei Niu, Zhen Song, and Quanfeng Deng are with the National Exponential Growth of Configuration Space: FaaS app de-
Engineering Research Center for Big Data Technology and System, Services velopers are required to configure several parameters for each
Computing Technology and System Lab, Cluster and Grid Computing Lab in the
School of Computer Science and Technology, Huazhong University of Science function. As the number of functions in the workflow grows,
and Technology, Wuhan 430074, China (e-mail: [email protected]; the decision space for parameters grows exponentially, making
[email protected]; [email protected]; [email protected]). it difficult to find the optimal configuration. Adjusting the con-
Qiong Chen is with the Hangzhou Research Centre, Central Software Institute,
Distributed LAB, YuanRong Team, Huawei, Hangzhou 310000, China (e-mail: figuration according to different SLOs further complicates the
[email protected]). resource configuration problem.
Fangming Liu is with Peng Cheng Laboratory, Shenzhen 518066, China, and Challenge in Optimizing Parallelism of Function Step: The
also with the Huazhong University of Science and Technology, Wuhan 430074,
China (e-mail: [email protected]). stateless nature of FaaS functions combined with their robust
Digital Object Identifier 10.1109/TPDS.2024.3365134 scalability simplifies and enhances parallel execution. FaaS
1045-9219 © 2024 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See https://www.ieee.org/publications/rights/index.html for more information.
Authorized licensed use limited to: Indira Gandhi Centre for Atomic Research (IGCAR). Downloaded on April 08,2024 at 04:55:58 UTC from IEEE Xplore. Restrictions apply.
WEN et al.: JOINT OPTIMIZATION OF PARALLELISM AND RESOURCE CONFIGURATION 561
Third, we integrate an advanced workflow engine into Step-

Conf. This engine efficiently coordinates various functions ac-
cording to user-defined workflows and closely integrates with
the Configuration Optimizer, enabling dynamic configuration
optimization throughout the execution of the workflow. Addi-
tionally, we incorporate a Configuration-Aware function pre-
warming mechanism into the workflow engine. It utilizes the
dependency within the workflow to proactively prewarm func-
Fig. 1. Resource configuration parameters in a function step. The yellow tion instances. By accurately predicting the configuration needs
blocks represent concurrently running function instances, where each function for the next step and prewarming the requisite number and size
instance consists of multiple processes to achieve intra-function parallelism. of function instances in advance, this mechanism significantly
reduces the likelihood of cold starts in the following function
workflows are particularly suitable for both inter-function and steps. Moreover, we design a highly scalable Function Man-
intra-function parallelism. A function step can not only imple- ager, which not only facilitates efficient parallel processing of
ment inter-function parallelism via concurrent instances, but function steps but also enhances the flexibility and scalability of
it can also execute intra-function parallelism using multiple StepConf, enabling it to support a wide range of FaaS platforms,
processes within a single function instance. Therefore, besides including open-source and commercial platforms.
the function memory size, it is equally critical to optimize the Finally, extensive experimental results show that StepConf
parallelism within each function step in the workflow, which is improves performance by up to 5.6× under the same cost budget
overlooked by existing works [22], [23], [24]. and achieves up to a 40% cost reduction while maintaining the
To better solve these challenges, in this paper, we present same level of performance compared with baselines.
the design, implementation, and evaluation of StepConf, an Considering that this work is an extension based on our pre-
SLO-aware dynamic cost optimization framework for multi-step vious work [25], we highlight the key improvements as follows.
serverless workflows. Our approach is an online solution that r We enhance the accuracy of our performance estimation
dynamically determines the configuration for each function step model by integrating a quantile regression model, which
before its execution, jointly optimizing inter-function paral- effectively predicts mapping and data transmission delays,
lelism, intra-function parallelism, and function memory size, thus significantly improving the overall precision of our
as shown in Fig. 1. performance estimation.
In this way, we can not only improve resource efficiency r We design a new Configuration-Aware function prewarm-
through optimized parallelism, but also optimize the configu- ing mechanism to StepConf, which leverages the workflow
ration step-by-step in real time to correct workflow progress, dependencies and performance models to initialize the
mitigate the impact of function performance variations, and required function instances in advance for the next function
ensure workflow SLOs while reducing costs. We also developed step, reducing the mapping delay caused by cold starts.
a function prewarming mechanism to mitigate function cold start r We reconstruct the architecture of StepConf to support
to reduce performance fluctuations. open-source FaaS platforms. We design and implement
First, we perform extensive measurements on AWS Step a workflow engine and adapt it to different platforms by
Functions to analyze the underlying service mechanism of adding the Function Manager.
serverless workflows. Our discussion indicates that performance r We expand the experimental evaluation by introducing a
fluctuations are primarily driven by the data transmission of machine learning workflow and comparing it with addi-
external storage services and the cold start of functions. To tional baselines and evaluation metrics to better demon-
tackle this challenge, we have developed a model in performance strate the advantages of StepConf.
estimator that leverages historical data, applying piece-wise The rest of this paper is organized as follows: The back-
fitting for both single-core and multi-core scenarios. Meanwhile, ground and motivation are introduced in Section II; Section III
we use statistical quantile regression models to estimate the describes how StepConf establishes its performance estimation
mapping delays and data transmission delays of functions. These model; Section IV details the definition of the configuration
approaches resolve the vague impact of resource configuration optimization problem and the design of heuristic algorithms
on performance and provide accurate estimates of performance for its resolution; Section V presents the function prewarming
and cost for online dynamic configuration optimization. mechanism; Section VI discusses the design and implementation
Second, we formally model the workflow resource configu- details of StepConf’s system components; Section VII shows
ration optimization problem and show that it is NP-hard. To this the experimental evaluation of StepConf. The related work is
end, we transform the problem into a decision problem for each reviewed in Section VIII, with the conclusion of this study
function step and utilize a heuristic optimization algorithm based presented in Section IX.
on the critical path to satisfy real-time requirements at low costs.
It is an online method that dynamically optimizes the configura-
II. BACKGROUND AND MOTIVATION
tion of the entire workflow step by step. We employ the Config-
uration Optimizer to execute this algorithm. It achieves optimal In this section, we first introduce the background of function
resource utilization by dynamically optimizing each step of the workflows. Then, we summarize the shortcomings of existing
workflow in real-time while meeting SLO requirements. work and discover two key factors they overlook. Finally, we
562 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 35, NO. 4, APRIL 2024
discuss the design motivation behind workflow configuration

optimization.
A. Configuration for Multi-Step Serverless Workflows

Many real-world serverless applications are implemented as
multi-step function workflows, where incoming user requests
invoke a set of serverless function steps, and each function step
performs a specific task while coordinating with other function
steps to complete the entire workflow. These function steps can
be executed either serially or in parallel to improve processing Fig. 2. Working process of a function step. In a function step, concurrent
performance. instances start running one by one, with each instance having a different mapping
However, optimizing the resource configuration of functions delay.
within serverless workflows presents a major challenge for de-
velopers, as previously discussed. There has been some previous
work conducted in this area. For instance, AWS Lambda Power
Tuning Tools [18] provides a tool to help developers optimize
serverless function configurations, reducing costs while achiev-
ing performance goals. However, this tool is only suitable for
optimizing the configuration of a single node and does not
apply to serverless workflows. COSE [22] models and optimizes
resource configuration for chain-based workflows. It intelli-
gently collects samples using Bayesian statistical methods and
Fig. 3. Mapping delay of a function step with different function duration time
predicts the cost and execution time of serverless functions under and inter-function parallelism.
different configurations. It also uses integer linear programming
to solve the optimization problem, meeting the SLO of the user’s
workflow. However, this work does not consider complex DAG
workflows. ORION [23] establishes a performance model for
DAG-style function workflows and proposes a method for co-
locating multiple parallel function calls within a single Virtual
Machine (VM). It optimizes function resource configuration to
meet the E2E latency requirements of the workflow.
However, these works have shortcomings. They all overlook
the importance of jointly optimizing parallelism and resource
allocation in the function steps (Section II-B), and the need Fig. 4. Duration time of a function step with different memory size and inter-
to dynamically configure optimized workflows may lead to function parallelism.
difficulties in guaranteeing SLO (Section II-C). This gives us
the motivation for our research.
in a function step are not started simultaneously. Thus, they have
B. Jointly Optimize Parallelism in Function Steps different mapping delays. The time from the start of the function
In the FaaS environment, choosing the appropriate memory step to the start of the last invoked function instance is referred to
size for functions is crucial. However, beyond the configuration as the mapping delay. Mapping delay is caused by the overhead
dimension of resource specifications, the parallelism of function of function cold starts and is related to the elastic capabilities of
steps is also a very important dimension. the FaaS platform.
First, we can utilize the parallelism between concurrent func- We created function steps with different function execution
tion instances (inter-function parallelism). For example, in a time and invoked them with different inter-function parallelism
video processing workflow, we can simultaneously invoke dif- on the AWS Step Function. As shown in Fig. 3, the mapping
ferent functions to perform various tasks for processing video delay of the function steps is relatively small when the paral-
images, as shown in Fig. 14. Although each function has limited lelism between functions is less than 30. However, the mapping
computational capability, we can achieve exceptional perfor- delay increases rapidly when it exceeds 40. As shown in Fig. 4,
mance through high parallelism among function instances. continuously increasing the inter-function parallelism does not
However, higher parallelism between functions does not al- further speed up the computation. The reason is that the mapping
ways mean benefits. We evaluated the performance of Step delay becomes a bottleneck. Therefore, we need to optimize the
Function workflows on AWS by decomposing the total computa- selection of function memory size and inter-function parallelism
tional delay of a function step into two parts: mapping delay and between functions to achieve cost efficiency.
execution time. Fig. 2 shows the process of AWS Step Function Besides parallelism between function instances, there is also
executing a function step where different concurrent instances intra-function parallelism, as illustrated in Fig. 1. Tasks within
improving workflow performance and reducing costs. Jointly

optimizing parallelism while optimizing the resource configu-
ration of function steps is also very important.
C. Performance Fluctuations in Function Steps

Performance fluctuations in function steps during execution
pose a challenge to ensuring end-to-end SLOs for workflows.
Through our analysis, we find that the primary causes of perfor-
Fig. 5. Duration time of a function step with different memory size and intra-
function parallelism. mance fluctuation are the variability in data exchange overhead
and the unpredictable mapping delay caused by function cold
starts.
As shown in Fig. 2, due to the possibility of cold starts
in different function instances within the function step, the
mapping delay exhibits its own variability. Additionally, in the
FaaS architecture, the separation of storage and computation
necessitates the use of remote storage services to facilitate
data exchange between functions [20], [21]. Unfortunately, this
dependency often leads to significant latency, varying from
several hundred milliseconds to a few seconds. We also notice
Fig. 6. Duration time of a function with different memory size and multi-core
ratio.
significant variations in the performance of these third-party
storage services. To address this issue, we conduct a series of
tests to evaluate the performance of AWS S3 storage within the
AWS Lambda environment.
a function instance can be parallelized in a multi-process man-
We use Python lambda functions and the AWS Boto3 SDK to
ner to achieve parallelism. Therefore, applying intra-function
download objects of different sizes from S3 buckets. We measure
parallelism strategies can undoubtedly improve the resource
the total data transmission delay while varying the number of
utilization and computational efficiency of functions, espe-
objects and their size. The results show different distribution
cially for programs not optimized for multi-core processing. To
patterns, as illustrated in Fig. 7. We observe that the IO perfor-
demonstrate this, we prepared a program that can only utilize
mance of S3 exhibits characteristics of a long-tail distribution.
single-core capabilities and observed its performance under
The variation between the fastest and slowest cases can often
different levels of intra-function parallelism. As can be seen in
be several times. This phenomenon increases the complexity of
Fig. 5, AWS allocates different numbers of available vCPUs for
optimizing workflow performance.
functions with various memory sizes. Increasing intra-function
Therefore, it is necessary to dynamically adjust the configura-
parallelism in situations with multiple CPU resources available
tion of function steps within the workflow in real-time, promptly
allows functions to utilize more CPU resources to enhance
correct deviations in workflow progress.
performance. According to the AWS Lambda official documen-
tation [3], functions have only single-core CPU resources when
memory is less than 1769 MB, and multi-core CPU resources D. Design Principles
are available only when exceeding 1769 MB. Based on the above analyses and insights, we formulate the
To delve deeper into how increasing memory size affects the following core design principles for the system:
performance of functions with varying degrees of multi-core r Joint Optimization of Memory and Parallelism Config-
friendliness, we deploy a benchmark function on AWS Lambda urations for Function Steps: To achieve the best cost-
that assesses whether each large number in a list is a prime num- performance ratio, it is crucial to simultaneously consider
ber. We develop both single-threaded and multi-core optimized and optimize the memory configuration and parallelism
versions of this program. The multi-core ratio is set as a task ratio settings of function steps.
to fully exploit multi-core resources. The higher this ratio, the r Developing a Performance Estimation Model: Developing
more the program is optimized for multi-core processing. We a model capable of accurately predicting performance un-
measure the function’s performance across various multi-core der different configurations is essential. This will provide
ratios and memory sizes. The results, as shown in Fig. 6, indicate solid data support for configuration choices in a serverless
that the performance of single-thread optimized programs ceases environment, helping to resolve the ambiguity in configu-
to improve beyond a certain memory threshold. In contrast, the ration awareness.
duration of the multi-core optimized programs proportionally r Dynamic Online Configuration: Given the variability in
decreases as memory increases. This observation leads us to the performance across different steps of a workflow, online
conclusion that it is essential to distinguish between single-core dynamic configuration optimization is vital. This strat-
and multi-core scenarios. egy involves dynamically adjusting configuration choices
As a result, in addition to inter-function parallelism, choosing before the execution of each function step to ensure the
the appropriate level of intra-function parallelism is also key to achievement of workflow performance goals.
Fig. 7. CDF plots of data transmission time with different object sizes.
r Minimizing Function Cold Starts: Implementing strategies

to minimize or avoid cold starts of function instances is nec-
essary to enhance the execution efficiency of workflows.
This not only reduces latency but also improves resource
utilization efficiency.
Fig. 8. Decomposition of function step duration time. When the last invoked
III. ESTIMATING PERFORMANCE AND COST UNDER function instance completes its execution, the process of the function step ends.
DIFFERENT CONFIGURATIONS
In this section, we introduce how to establish a performance
estimation model to estimate the duration time and cost of a In addition, the creation of function sandboxes and initialization
function step under different configurations (parallelism and of function code, which also contribute to the mapping delay.
resource configuration). Since the tasks of concurrent instances within a function step
are evenly distributed, the execution times are similar. To this
A. The Importance of Performance Estimation end, we can define the mapping delay of a function step as the
mapping delay of the latest invoked function instance. Therefore,
To optimize the configuration of the function step, we need
the duration time of a function step can be divided into the
to obtain the performance and cost of the function step under
mapping delay plus the function execution time.
different configurations. One direct method is to conduct com-
As shown in Fig. 8, the total time for a function step consists of
prehensive profiling tests. However, performing profiling tests
the mapping delay of the last invoked function and the execution
on all possible configuration combinations in advance is both
time of its function instance. The execution time of each function
time-consuming and costly. We hope to estimate the relationship
instance in the function step mainly includes three parts: data
between different configuration parameters, performance, and
download, task computation, and data upload. Let’s denote a
cost using a smaller sample of profiling tests.
certain function step as vi , its end-to-end total delay as ti , the
mapping delay as tm i , the total delay for data download and
B. Decomposition of Function Step Duration Time upload as tdi and tui respectively, and the computation delay of
To accurately estimate the performance of function steps, we the function instance as tci , and we have: ti = tm
i + ti + ti + ti .
d c u
decompose the duration time of function steps. The execution Among these three parts, the time for downloading and up-
process of a function step corresponds to the completion of all loading data is usually determined by the function’s network
tasks in that function step during the execution of a workflow. bandwidth and is independent of the function’s computational
As we consider inter-function and intra-function parallelism complexity. The computation time depends on the function’s
within each function step, the entire process of a function step computational complexity and the resources used.
is equivalent to the execution of multiple concurrent instances Based on previous analysis, data transmission delay and map-
of a function, where each instance utilizes multiprocessing for ping delay have significant fluctuations. On the other hand, the
parallel computation. fluctuation of computation latency is relatively small. There-
Through our tests, we find that concurrently invoked function fore, we need to employ different estimation methods for these
instances are not started at the same time, and these concurrent components.
instances experience different mapping delays. The mapping
delay of a function instance is the waiting time from the start of
the function step until the function instance begins to execute. C. Piece-Wise Fitting Model for Computation Latency
The mapping delays of different concurrent function instances To accurately predict the computation latency of functions,
within the same function step form a stair-like distribution, as we propose a piece-wise fitting model. Since the duration of
shown in Fig. 2. This phenomenon is caused by the cold start function computation is usually influenced by the number of
time required for the elastic scaling of function instances, where tasks in function instances and the memory size, we consider
function instances are created one by one rather than all at once. these two key factors in the model. Let γi represent the total
number of tasks in a function step. Then, based on the inter- the square terms of these variables and their possible interac-
function parallelism pi , we define γi = γi pi , which represents tions. The model can be expressed as:
the number of tasks allocated to each function instance.
Based on the experimental data shown in Fig. 6, we find that
n
QY |X (ω) = β0 (ω) + βi (ω)Xi
the execution time of functions is inversely proportional to the i=1
memory size. Since performance is the reciprocal of time, this
indicates that the multi-core performance of function instances
n
+ γi (ω)Xi2 + δij (ω)Xi Xj (2)
is nearly linearly related to the memory size. At the same time, i=1 i<j
the performance of functions is also influenced by the internal
parallel optimization of function code. We use ms to represent Where ω is quantile, β0 (ω) is the intercept term, and βi (ω),
the memory size of single-core resources allocated by the cloud γi (ω), and δij (ω) respectively represent the coefficients for the
service provider (where s denotes single-core), and δs represents linear terms, square terms, and interaction terms. This model
the relative performance. We define min ( m mi
s
, qi ), where qi structure allows us to capture and predict the distribution of
represents the index of internal parallelism in the function. Here, the response variable Y at the quantile level, while considering
mi
ms represents the multiple of resources allocated to the function the nonlinear relationships and interaction effects among the
compared to the maximum multiple achievable by a single core, explanatory variables.
and qi represents the multiple of performance improvement These coefficients are estimated by minimizing the quantile
achievable by using internal function parallelism compared to loss function, which focuses on absolute deviations and assigns
a single thread. Taking the smaller value of these two factors different weights to errors above and below the ω quantile.
represents the upper limit of the multi-core acceleration ratio The estimated parameters are used to predict data transmission
for a single-thread optimized function with internal parallelism. time and mapping delay at the specific quantile ω. We use the
It is worth noting that if the program has already implemented number of objects and its size as parameters for predicting data
multi-core optimization, the impact of internal function paral- transmission delay, and the number of functions with a cold start
lelism will be weakened. In this case, the inverse relationship be- for predicting mapping delay. Although the quantile regression
tween execution time and memory size will change. Therefore, model does not directly estimate the complete probability dis-
we use an exponential function to improve prediction accuracy. tribution, it does provide significant insights into the conditional
Thus, we design a piece-wise fitting approach. For programs distribution of delays at the chosen quantile level.
applicable to multi-core scenarios (i.e., case 1), we use an
exponential function for fitting; while for programs that can only E. Cost Model of Function Step
utilize single-thread performance or have memory sizes lower
than ms (i.e., case 2), we use an inverse function for fitting: Let ci denote the cost of the function step vi in the workflow.
Different cloud vendors have similar pricing models for function
⎧ workflow. In the following, we take the pricing model of AWS
m
⎨(ai,1 · γi + bi,1 )e−ai,2 ·min ( msi ,qi ) + φi,1 , case 1 as a representation [17]. We denote the price for per GB-second
tci = ai,2 ·γi of function as μ0 , and the price for function requests and or-
⎩ + φi,2 , case 2
m
δs·min ( msi ,qi )+bi,2 chestration as μ1 , where μ0 and μ1 are constants. For a function
(1) step, given a intra-function parallelism pi , then we have the cost
of function step ci = pi · (ti · mi · μ0 + μ1 ).
In this formula, ai,1 , ai,2 , bi,1 , bi,2 , φi,1 , φi,2 are model pa-
IV. DYNAMIC OPTIMIZATION OF FUNCTION STEP
rameters obtained through data training.
CONFIGURATION
In this section, we introduce how to dynamically determine
D. Quantile Regression Model for Varying Delays the configuration for each function step.
Considering the inherent variability in data transmission and
mapping delays, making precise predictions poses a significant A. Problem Formulation
challenge. To address this issue, we adopt a quantile regres- A function workflow consists of a series of different function
sion model for prediction. This model is particularly suitable steps executed in sequence. We represent a serverless workflow
for predicting response variables like data transmission delay using a directed acyclic graph (DAG) G = (V, E). The vertices
and mapping delay at specific quantiles. Imagine we have a V = v1 , v2 , . . ., vn represent the n function steps within the
dataset containing numerous variables observed under various workflow. Vertices with an in-degree of 0 represent the starting
parameters. Here, Y represents the response variable, while point of the workflow, which corresponds to the first function
X = [X1 , X2 , . . . , Xn ] represents a set of explanatory variables. step to be executed. Vertices with an out-degree of 0 represent the
To more accurately capture the potential nonlinear relation- endpoint of the workflow, which corresponds to the last function
ships between X and Y , our quantile regression model considers step to be executed. The edges E = vi vj | 1 ≤ i = j ≤ N rep-
not only the effect of each individual Xi on Y , but also includes resent dependencies between function steps, where vi vj denotes
the edge vi → vj , meaning that the operation of function step TABLE I

MAIN NOTATIONS
vj depends on vi .
For function step vi , it will only begin execution once all
its dependencies are completed. Let L ∈ L represent the set of
vertices from the start to the endpoint. We define the execution
time of function step vi as ti and the completion time of the
function workflow as T . It is easy to see that the completion time
T depends on the longest running path and can be expressed as
T = maxL∈L vi ∈L ti .
Furthermore, we define the cost of function step vi as ci , and
the total
cost of processing the workflow can be calculated using
C = vi ∈V ci .
The memory size of all parallel functions in each function step
is the same as the memory configuration of the function step.
Let M represent the set of memory configurations provided
by the cloud platform, and P represent the set of optional
inter-function parallelism. We use Q to represent the set of
available optimal intra-function parallelism. We represent the
configuration of function step vi as θi = (mi , pi , qi ). We can
define the configuration settings of function step vi as:
Θi = (mi , pi , qi ) | mi ∈ M, pi ∈ P, qi ∈ Q. (3)
We use binary variable xi (θ) to indicate whether function step

vi is configured as θ: B. Computation Complexity
Theorem 1 shows that the problem (7) is NP-hard, which
0, function step vi is not configured as θ
xi (θ) = . (4) makes it impractical to find the optimal configuration.
1, function step vi is configured as θ
Theorem 1: Problem FWCP (7) is NP-hard.
Since each function can only use one configuration, we have: Proof: We construct a polynomial-time reduction to (7) from
the multiple-choices knapsack problem (8)(9), a classic opti-
mization problem which is known to be NP-hard.
xi (θ) = 1, ∀vi ∈ V. (5)
θ∈Θi
m
max μij xij (8)
Our goal is to optimize the end-to-end performance of the i=1 j∈Ni
workflow and minimize cost while satisfying the workflow’s ⎧m
⎪
⎨ i=1 j∈Ni wij xij ≤ C
Service Level Objective (SLO). Let S represent the SLO of the
workflow request. We have the following SLO constraint: subject to : xij ∈ {0, 1}, 1 ≤ i ≤ m, j ∈ Ni . (9)
⎩
⎪
j∈Ni xij = 1, 1 ≤ i ≤ m
T = max ti (θ) · xi (θ) < S. (6)
L∈L
vi ∈L θ∈Θi
Given an instance A = (m, μij , wij , C, xij ) of the knapsack
problem, we map it to an instance of the (7) with A = (n ←
Our Function Workflow Configuration Problem (FWCP) can be m, −ci (θ) ← μij , ti (θ) ← wij , S ← C, xi (θ) ← xij ). Clearly,
formulated as: the above mapping problem can be solved in polynomial time.
Then, if there exists an algorithm that solves problem A , it solves
min C = min ci (θ) · xi (θ) the corresponding knapsack problem as well. As a result, the
vi ∈V θ∈Θi multiple-choices knapsack problem can be treated as a special
case of (7). Given the NP-hardness of the multiple-choices
subject to: (3)(4)(5)(6). (7) knapsack problem, (7) must be NP-hard as well.
In summary, the FWCP aims to find the optimal configuration
for each function step in the workflow to minimize the total cost C. Problem Relaxation and Global-Cached Most
while ensuring that the end-to-end performance meets the given Cost-Effective Critical Path Algorithm
SLO constraint. The problem is formulated using a series of As shown above, we need to reduce the computation complex-
equations and constraints that take into account the execution ity and propose a practical algorithm to configure each function
time, cost, and configuration of each function step, as well as step efficiently.
the dependencies between function steps in the workflow. Main Note that (6) restricts the maximum duration of all paths L
notations are listed in Table I. in the graph G by the request SLO. Therefore, we can set a
Algorithm 1: Global-Cached Most Cost-Effective Critical

Path Algorithm.
Fig. 9. Algorithm description diagram.
sub-SLO si for each function step, where

∀L ∈ L, si ≤ S. (10)
vi ∈L
By doing this, we relax the constraint (6) by:

ti = ti (θ) · xi (θ) < si . (11)
θ∈Θi
Then we can reduce the problem (7) of optimizing a DAG to

optimize the configuration of each function step vi with sub-SLO
constraints, which is formulated as follows:

min ci = min ci (θ) · xi (θ)
θ∈Θi
to the most cost-effective one also demonstrate relatively high
subject to: (4)(11). (12)
cost-effectiveness. Building on this, we utilize performance es-
In the following discussion, we will demonstrate how to timation model to identify the most cost-effective configuration
allocate sub-SLOs to each function step. Based on the critical for each node, using its duration to set weights. This approach
path method [26], our approach identifies the longest path in the allows us to approximate the sub-SLO for each function step
workflow as the critical path. The execution time of each node on closer to the most cost-effective configuration choice, even
this critical path is considered its corresponding weight. These when we cannot pre-determine the best weight distribution. This
weights then serve as the basis for fairly distributing the SLO strategy helps in enhancing the overall computational efficiency
among the nodes (function steps). This allocation mechanism is of the workflow and reducing costs.
visually represented in Fig. 9, where the critical path is assumed In our problem, the performance is evaluated by the multi-
to be the red path in the diagram (A1-A3-A8-A14). We can easily plicative inverse of the duration time, i.e., t−1 , and hence the
c
allocate sub-SLOs to all nodes on the critical path and find the cost-effective ratio is t−1 . The best cost-effective configuration
∗
optimal configuration for the current node (A1). Subsequently, θ can be obtained by:
we identify two sub-graphs connected to the critical path (yellow ci (θ)
and green). As the workflow progresses and encounters the θ∗ = arg max . (13)
θ t−1
i (θ)
starting nodes of the sub-graphs (A4), we can recursively apply
our method. With the workflow’s execution, the size of the We further denote ti (θ∗ ) as the duration time of its function step
sub-graphs decreases (A9 and A11), finally achieving online with the configuration of the most cost-effective ratio. And the
dynamic resource allocation optimization for each node in the sub-SLO for current function step vi is given by:
workflow. ti (θ∗ )
However, in our online problem, we are unable to know the si = ∗)
· S. (14)
configuration choices and their runtime for future functional vi ∈Lcritical ti (θ
steps, making it challenging to determine the weights to find As our online strategy is essentially a distributed decision
the critical path. Based on our insights, each functional step progress. There is no need for each configurator of function step
has a most cost-effective configuration, defined by the ratio to obtain the global information of the graph. As a result, we
of performance to cost. We rank configurations according to establish a shared global cache for them to access the necessary
their cost-effectiveness and observe that configurations close data, which can also reduce the amount of local computation.
argue that searching for the best configuration with (12) is hard
when the configuration space is large. To deal with it, we can
maintain a local record of optimal configuration and replace the
sub-optimal configuration when there is a configuration choice
with better performance at the same cost or less cost with the
same performance. Once established, we do not have to traverse
all configuration choices every time, which can improve the
Fig. 10. Diagram of Configuration-Aware function prewarm. efficiency of our algorithm.
Based on this, we propose Global-cached Most Cost-effective V. CONFIGURATION-AWARE FUNCTION PREWARM

Critical Path Algorithm in Algorithm 1. In this section, we introduce a solution to solve the cold start
To implement the Algorithm 1, we define a timestamp called problem of the workflow functions with dynamic configuration.
the latest completion time τi for each function step vi according In essence, by leveraging dependencies between different
to their SLOs. The latest completion time indicates the deadline function steps in the workflow, we can prewarm function in-
of the function step to finish. It can be calculated by adding the stances as needed based on the real-time progress of the work-
timestamp of entering the current function step with its SLO. flow for future executions, as shown in Fig. 10. However, the
Before the first node of the workflow is executed, we first put key to this process lies in the accurate prediction of the function
the entire workflow G and the corresponding latest completion execution process. If the estimation of the workflow’s progress is
timestamp T for G into the global cache. For each subsequent inaccurate, it may lead to incorrect timing for function prewarm-
function step that is executed, before entering the execution of ing, thus failing to effectively mitigate the cold start problem.
the function step, we run Algorithm 1 to optimize the resource In the previous Section III, we have already introduced a
configuration choice for that function step. The algorithm first method for performance estimation that can predict the exe-
obtains the current function step vi and the current timestamp cution times of different function steps under different config-
τi (Line 1). Then, it retrieves the sub-graph starting from the urations, including the mapping delay of function instances,
current node and the planned latest completion time from the in the form of percentiles. Therefore, we can choose the ap-
global cache (Line 2). Next, we can calculate the SLO for the propriate percentile of performance prediction data based on
current sub-graph (Line 3). After that, we determine the weight specific prewarming requirements to accurately determine the
of each function step in the sub-graph according to the best optimal timing for function prewarming. If we wish to prewarm
cost-effectiveness strategy and identify the critical path (Line functions more conservatively and minimize the occurrence of
4-7). Subsequently, we can divide the sub-SLO for each function function cold starts, we can choose larger percentiles, such as
step on the critical path based on their weights (Line 8-9). The p90. Conversely, we can select smaller percentiles, if we want
optimal configuration choice for the current step is derived from a less conservative approach. With performance estimation in
the sub-SLO and the formula (12) (Line 10). place, we can identify the suitable timing to prewarm functions.
Next, we will identify all sub-graphs connected to the critical For a function step vi , its prewarming timing τip can be
path and calculate the latest completion time for each sub-graph determined based on the mapping delay tm i of function step vi
(Line 11-15). We store each sub-graph and its latest completion under configuration θ, its latest completion time τi , and its SLO
time as a pair in the global cache (Line 16). Finally, we save si , by τip = τi − tmi − si .
the remaining critical path as a sub-graph, along with its latest Furthermore, another significant challenge we face in the
completion time, in the global cache (Line 17-19). In this way, as process of dynamic configuration optimization is the difficulty
each function step of the workflow is executed, the scale of the in accurately predicting the specific instance specifications and
optimization algorithm’s optimization is continuously reduced. their concurrency required for the next function step. To address
In the final process, a single node acts as a sub-graph, as nodes this issue, we adopt a Configuration-Aware strategy. We first
(A9,A11) shown in Fig. 9. assume that the current function step can be completed as
Theorem 2: The time complexity of Algorithm 1 is O(|V | + scheduled. Based on this assumption, we subsequently imple-
|E| + |Θ|), where |E| is the number of edges in the current ment Algorithm 1 for the next function step that depends on it,
sub-graph, |V | is the number of function steps in the current sub- optimize its configuration in advance.
graph, |Θ| is the number of configuration combination choices. By predicting the resource and parallelism configurations
Proof: For Lines 1-3, the time complexity is at most O(1). For likely to be used in the next function step, we have achieved
Lines 4-6, the time complexity is at most O(|V |). For Lines 7, the Configuration-Aware function prewarming. Even if deviations
time complexity of getting the critical path and setting weights in workflow performance may lead to variations in the final con-
of a DAG is O(|V | + |E|). For Line 10, the time complexity of figuration selection, employing this strategy always prewarms
solving (12) is at most O(|Θ|). And for Lines 11-18, the time some function instances. This prewarmed configuration holds a
complexity of getting the sub-graph and latest finish timestamp greater possibility during the optimization of the next function
is at most O(|V | + |E|). step, as it reduces the mapping delay.
Theorem 2 shows the time complexity of our solution. It We achieve prewarming of function instances by using a
shows our solution can be solved in polynomial time. Some may method known as “dummy function invoke” [27]. We assign a
serves as the core component of StepConf, executes each func-

tion step by step based on the dependencies defined in the
workflow. The executor tracks the execution status of each
function step and initiates execution when the dependencies
for the next step are satisfied. Within the Workflow Engine,
the Configuration Optimizer plays a central role in StepConf,
dynamically optimizing resource allocation based on real-time
runtime constraints and function performance models to ensure
optimal execution of each function step within the workflow.
In addition, StepConf’s workflow engine includes a Func-
tion Prewarmer that addresses the challenge of cold starts. By
leveraging performance models, it predicts the expected comple-
tion time for each function step and warms up the subsequent
step accordingly. It also uses the Configuration Optimizer to
determine the most likely configuration for the next step and
Fig. 11. System architecture overview of StepConf.
prewarms functions based on that configuration. In the StepConf
framework, the Function Manager serves as an intermediary for
function execution. It manages the entire function step lifecycle
special invocation endpoint for each function. When invoked, it and invokes the functions deployed on the FaaS cluster based
triggers the initialization process of the function instance without on the step input, function name, and function configuration
actually executing the real task processing. Leveraging the cloud provided by the Workflow Engine.
platform’s function keep-alive policies, concurrent invocations These components work together to ensure StepConf effec-
of a certain number of dummy functions can effectively accom- tively uses resources and meets SLOs for serverless workflows
plish the prewarming of different numbers of function instances. while minimizing operational costs. The following sections
explain each of these components in more detail.
VI. SYSTEM IMPLEMENTATION
In this section, we delve into the implementation details of B. Workflow Engine
the entire system, known as StepConf.
The workflow engine is used to schedule and sequentially
execute each function step based on the dependencies defined
A. StepConf Overview in the workflow. Many commercial FaaS platforms have in-
To address a range of issues and challenges in optimiz- troduced corresponding workflow engines, such as AWS Step
ing resource configuration for serverless workflow, this paper Functions [28], Azure Logic Apps [29], etc. However, these
introduces StepConf. StepConf combines dynamic optimiza- workflow engines do not support dynamic resource configura-
tion of function step parallelism with resource configuration, tion for workflows, which means they cannot perform real-time
achieving minimal resource consumption while meeting the resource configuration optimization for each workflow request.
SLOs of multi-step serverless workflows. During workflow To solve this problem, we implement a workflow engine that
execution, developers only need to specify the desired SLOs, focuses on dynamic resource configuration based on Luigi [30].
and StepConf dynamically and in real-time makes decisions It not only implements on-demand invocation of function steps
to optimize resource allocation before each functional step. according to workflow dependencies but also integrates the
Moreover, the Workflow Engine within StepConf employs a Performance Estimator (Section III) and the Configuration Op-
Configuration-Aware proactive function prewarm mechanism, timizer (Section IV). These two components are used for the
significantly reducing the additional overhead caused by cold dynamic resource configuration of the workflow.
starts. The system architecture of StepConf, as shown in Fig. 11,
encompasses both offline and online phases.
During the offline phase, developers need to prepare the C. Function Packager
workflow definition, which contains the source code of the Another important component of StepConf is the function
functions and the dependencies between the function steps. The packager. It is a program for helping developers to deploy
Function Packager compiles and packages the user-supplied workflows. It is a Python package that provides a convenient
source code along with the Function Wrapper code into func- API, allowing users to conveniently package their application
tion images, which are then deployed. At the same time, the workflow code into function images and deploy them to the FaaS
Performance Estimator performs performance profiling of the platform. The function packager only requires the user’s appli-
functions, collecting profile data during function execution and cation workflow function’s handler code and a dependency de-
creating performance models for each function. scription file. It then creates the corresponding function Docker
During the online phase, developers send requests through the image and deploys it to the corresponding cloud platform. The
API gateway containing the workflow’s input and the desired user’s provided handler code only needs to follow the template
SLO to invoke the workflow. The Workflow Engine, which shown in Fig. 12, and the function packager will incorporate the
TABLE II
EXPERIMENTAL ENVIRONMENT CONFIGURATIONS
Fig. 12. User code example of object detection function step.
Function Wrapper class we designed to override the user’s entry

function.
D. Function Wrapper
other platforms, including various open-source and commercial
The Function Wrapper is a Python class responsible for in- platforms.
voking the user-provided handler function within the function
instance using multiprocessing, thereby enabling intra-function
parallelism. Before executing each function step, the Configu- VII. EXPERIMENTAL EVALUATION
ration Optimizer optimizes the configuration selection for the In this section, we demonstrate the advantages of the com-
current step by considering both inter-function parallelism and ponents of StepConf through a series of experiments. Our ex-
intra-function parallelism. The workflow engine concurrently perimental evaluation aims to answer the following research
invokes the specified number of function instance based on questions (RQs):
inter-function parallelism. Within each function instance, the r RQ1: Can StepConf accurately estimate the performance
Function Wrapper takes over the entire process of data down- and cost under different configurations?
loading, computation, and data uploading. It invokes the given r RQ2: Can StepConf dynamic resource allocation scheme
number of processes based on intra-function parallelism. The guarantee the SLOs of workflows?
Function Wrapper is responsible for splitting the data and r RQ3: Can StepConf resource allocation optimization algo-
mapping it to each process and then waits for all processes rithm reduce the cost of workflows?
to complete before merging the outputs. Additionally, we have r RQ4: Does considering parallelism in StepConf optimiza-
rewritten the SDK for accessing storage media in the Function tion improve the performance and reduce the cost of work-
Wrapper using multithreading, enabling parallel data uploading flows?
and downloading to improve data transfer efficiency. r RQ5: Can the StepConf heuristic algorithm approach the
In particular, since the current FaaS platform does not support theoretical optimum with a small overhead?
dynamically adjusting the configuration of function resources, r RQ6: Can the StepConf function prewarmer reduce the
how can we dynamically invoke functions with corresponding cold start overheads in workflows?
memory sizes on demand? To address this, we deploy duplicate
functions with different memory sizes. We use different versions A. Experimental Setup
of the same function to be configured with different memory
sizes, using tags like “helloworld:1024 MB”. In this way, we Cluster and Software Information: We build a highly avail-
can select the desired function memory by invoking the function able Kubernetes cluster and installed Knative Serving as the
with different URL tags. serverless platform, where HAproxy [31] and Keepalived [32]
are installed. The cluster comprises 3 master nodes and 6 worker
nodes. Each worker node was allocated 16 cores and 32 GB
E. Function Manager of memory, while each master node was allocated 8 cores
Within the StepConf, the Function Manager plays a central and 16 GB of memory. For data exchange between functions,
role as middleware and assumes comprehensive control over we utilized an AWS S3 storage bucket located in the nearest
the execution of function steps. It manages the entire lifecycle region to our experimental environment, ensuring ample pub-
of function steps and facilitates parallel processing between lic network bandwidth over 1 Gbps and low storage access
functions by invoking a certain number of function instances latency to replicate the resource conditions of mainstream cloud
simultaneously. After the workflow engine provides the step applications [33], [34]. Table II provides detailed information
input, function name, and function configuration information, on the hardware facilities and software versions used in our
the function manager starts working. experiments.
To achieve this, we designed the Function Manager as an Workflow Applications: We select three different workflows
internal proxy service within the cluster. During its operation, the implemented in Python 3.8 to evaluate the performance of
Function Manager, guided by the Workflow Engine directives, StepConf as follows:
invokes specific functions that were previously provisioned in r Machine Learning Workflow (ML): Machine learning is
the FaaS cluster. Importantly, by using Function Manager, we a typical use case of serverless workflow. We adopt the
ensured compatibility not only with AWS Lambda, but also with ML workflow introduced in [23]. It primarily consists of
TABLE III
COMPARISON OF STEPCONF WITH BASELINES
Fig. 13. Machine learning workflow.
We refer to [17] to define the cost expenses of the Knative

Fig. 14. Video processing workflow. FaaS platform. For every single function, we configure different
specifications based on the ratio of 1 vCPU to 2048 MB of
memory.
Baselines: Based on our analysis of recent works outlined in
Section II, we select the following baselines for comparison with
StepConf:
r Vanilla [26]: Static workflow configuration optimization
without considering inter-function or intra-function paral-
lelism, which is based on critical path method.
r Oracle: Employs an brute-force algorithm to find the
optimal solution for static workflow configuration opti-
Fig. 15. Synthesized DAG workflow.
mization, jointly optimizing memory size and both inter-
function and intra-function parallelism, the same as Step-
Conf.
three function steps, including Preprocess (dimensionality r Orion [23]: Static workflow configuration without consid-
reduction of raw data), Train (training decision trees), and ering inter-function parallelism.
Merge (merge the results). Our workflow includes three r COSE [22]: Dynamic workflow configuration without con-
independent ML pipelines, forming the workflow as shown sidering inter-function or intra-function parallelism.
in Fig. 13. We aim to find out the influence of considering both inter and
r Video Processing Workflow (VP): Video processing re- intra-function parallelism and we design baselines as follows:
quires a significant amount of computational resources and r StepConf-Inter: StepConf’s dynamic workflow configu-
is well-suited for leveraging the parallelism of serverless ration without considering intra-function parallelism but
functions to accelerate the processing. Inspired by [4], we consider inter-function parallelism.
establish a complex video workflow. It includes 8 different r StepConf-Intra: StepConf’s dynamic workflow configu-
function steps: pull frame, object detection, watermarking, ration without considering inter-function parallelism but
super-resolution, color filtering, text addition, frame inter- considering intra-function parallelism.
polation, and merge frame. The pull frame step decodes the Table III describes the characteristics of each baseline.
video input into a set of frames, and then each subsequent
function step processes this set of frames. The final function
B. Performance Prediction Accuracy
step is merge frame to encode the video, as shown in
Fig. 14. In this section, we evaluate the performance estimator of
r DAG Workflow (DAG): To thoroughly evaluate the perfor- StepConf through experiments to answer RQ1 (performance
mance of StepConf in a complex workflow environment, estimation). We aim to examine whether our models can ac-
we design a complex synthetic workflow application con- curately fit the performance of different functions under dif-
sisting of 16 steps, following [24]. As shown in Fig. 15, ferent memory sizes. We select two benchmark functions from
we select CPU compute-intensive benchmark applications Section II, representing functions optimized for a single core
(is-prime) with four different computational complexities, only and functions optimized for multiple cores. By performing
covering a range of upload and download data transmission performance profiling tests on the function steps and collecting
volumes. Different colors in the figure represent function the computational delays for different task numbers, memory
of varying difficulty. In these 16 steps, we randomly assign sizes, and parallelization strategies, we then use StepConf’s
tasks of different difficulties. Although this workflow does performance estimator to fit the test data.
not have a specific practical use, this method allows us to For each function, we conduct profiling for different numbers
simulate complex situations that may be encountered in of jobs using five memory points (512 MB, 1024 MB, 2048 MB,
the real world, even though these situations are difficult to 4192 MB, 10240 MB). Regarding the varying mapping delay
fully replicate in a single experiment. and data transmission, we initially collect actual performance
Fig. 16. Comparison of fitting results for functions in different types.
Fig. 17. Comparison of relative prediction error for different functions in different types.
data from a total of 100 recent invocations across different work- than 8%. This accuracy is achieved with relatively low profiling
flows on the cloud platform, to initialize the quantile regression costs, owing to our combined use of piece-wise and quantile
model. As more data is collected by the cloud platform, the models, providing accurate performance estimations.
quantile model will be able to more accurately reflect the actual
performance characteristics and fluctuation trends. The quantile
is set as P90 and we repeat the experiment 10 times for average. C. Performance Guarantee and Cost Saving
Fig. 16(a) describes a function that is optimized for a single To answer RQ2 (SLO) and RQ3 (Cost Saving), we present
thread and does not have intra-function parallelism configured. experimental results of our workflow executions.
Therefore, even though the function instances have access to First, we select four different SLOs for each workflow and
multiple CPU cores, the function cannot utilize them once ran the workflows multiple times, measuring the end-to-end
the memory size exceeds 1769 MB. This results in a nearly completion time. We collect the performance of the workflow
horizontal line shape in the figures. repeated 20 times to see how the SLO fluctuated. As shown
However, when we configure intra-function parallelism for in Fig. 18, the x-axis represents different SLOs for workflow
the single-thread optimized function, the function can utilize configurations, and the y-axis represents the normalized work-
the multiple core resources, as shown in Fig. 16(b). Compared flow end-to-end runtime, which is the actual workflow execution
to the previous case, enabling intra-function parallelism allows time divided by the SLO. Values closer to 1 indicate that the
the function to make better use of the allocated resources of actual duration time of the workflow is closer to the expected
function instances, thereby improving performance, given the SLO. We can observe that compared to the baseline, StepConf’s
same memory specifications. workflow duration has lower fluctuations and mostly remains
Fig. 16(c) describes a function that is already optimized for below 1. This indicates that StepConf, with its real-time dy-
multiple cores. From the goodness of fit of the curve in the graph, namic workflow configuration, better meets the SLOs. It’s worth
we can see that the piece-wise fitting model of the performance noting that although we can dynamically adjust the workflow
estimator can accurately fit the performance of the function configuration in real-time to correct the workflow’s execution,
under different configuration parameters. the performance fluctuations caused by the last function step
Fig. 17 shows the prediction errors for the average end-to-end cannot be completely eliminated, which is why StepConf cannot
performance of three different function steps. From the color completely eliminate performance fluctuations.
depth in the graph, it can be observed that, for different memory Next, we compare the cost of running the workflows under dif-
sizes and different numbers of tasks, the prediction errors for the ferent SLOs. We use Vanilla’s performance and cost as the base-
functions are mostly within 4%, with the largest error being less line and compare the performance and cost of other solutions.
Fig. 18. End to End duration time under different SLOs.
Fig. 19. Performance and cost compared with different baselines (Lower is the better).
Fig. 20. Cost of workflows under different SLOs.
As shown in Fig. 19, StepConf can achieve cost savings of up to to fully utilize both intra-function and inter-function parallelism,
40% while improving performance by up to 5.6× compared to resulting in higher resource utilization efficiency and better
the vanilla approach. In comparison to other baselines, StepConf performance under the same cost.
can save costs by 5% to 22.3% while enhancing performance by
1.91× to 3.3×.
E. Algorithm Effectiveness and Overhead
To answer RQ5 (Heuristic), we compare our algorithm with
D. Impact of Optimizing Parallelism
the theoretical optimal configuration namely Oracle. Since on-
To answer RQ4 (Parallelism), we investigate the impact of line algorithms cannot guide the real-time execution of actual
optimizing parallelism in the function steps of workflows and workflows, the theoretical optimal solution exists only in of-
conducted experiments comparing StepConf with partial paral- fline algorithms. Therefore, we adopt the offline version of
lelism optimization. the StepConf algorithm, ignoring performance fluctuations in
Fig. 20 shows that individually optimizing intra-function par- workflow function steps, to make a fair comparison with the
allelism or inter-function parallelism has less impact compared oracle algorithm. The oracle algorithm uses a traversal method
to optimizing both simultaneously. The key point of StepConf is to find the optimal solution. As shown in Fig. 21, our algorithm
Fig. 21. Avg cost of workflows compared with oracle. Fig. 23. Reduction of average mapping delay with function prewarmer.
manager tailored for interactive cloud microservices. Mao et

al. [37] leverage deep reinforcement learning to optimize the
scheduling of data processing jobs on distributed compute clus-
ters. Li et al. [38] propose a dynamic VM scaling approach
for cost-efficient MapReduce workload management. Romero
et al. [39] create an automated, model-agnostic system for
distributed inference serving, allowing developers to specify per-
formance and accuracy requirements without choosing specific
model variants for each query.
Fig. 22. Breakdown of end-to-end latency with different workflows. In the serverless domain, Caerus [12] is a task sched-
uler for serverless analytics, featuring an advanced algorithm
that optimizes both execution costs and job completion time.
consistently demonstrates outstanding performance across three Wukong [13] is a FaaS computing framework for DAG work-
workflows, with costs slightly higher than the theoretical optimal flows, enhancing data locality and emphasizing decentralized
solution by less than 5%, respectively 4.1%, 3.5%, and 2.6%. scheduling’s benefits in serverless parallel computations, like
To demonstrate the efficiency of our scheduling algorithm, resource elasticity and cost efficiency. FaaSFlow [14] tackle
we analyzed the delay decomposition in the critical path of the inefficiency of central schedulers by implementing a worker
the workflow. Fig. 22 shows that the delay in configuration node-based scheduling strategy, coupled with an adaptive stor-
decisions accounts for a low percentage, not exceeding 1% of age repository for faster data transfers between co-located func-
the workflow. In summary, our algorithm performs well in terms tions. Lastly, Atoll [40] introduce a serverless platform ensuring
of effectiveness and overhead, and it is efficient and feasible enhanced latency performance through deadline-aware schedul-
in practical applications. For the majority of workflow tasks, ing, proactive sandbox allocation, and load balancing.
the configuration optimization overheads can be considered Optimization of Configuration: Optimizing configurations in
negligible. cloud computing is crucial. Systems like CherryPick [41] and
Ernest [42] enhance performance and reduce cost by accu-
F. Function Cold Start Overhead rately predicting VM configuration impacts. In the serverless
context, this translates to predicting function performance and
To answer RQ6 (Cold Start), we conduct experiments to
costs for optimal configuration. Eismann et al. [43] employ
evaluate our function prewarming mechanism. According to the
mixture density models for predicting function execution times,
definition and description in Section II, the cold start time of
while Akhtar et al. [22] use statistical learning to optimize
functions falls into the category of mapping delay. Therefore,
function chain configurations. Elgamal et al. [44] investigate
we compare the proportion of mapping delay in the workflow
cost-effective strategies for function placement and sizing. In
before and after enabling the function prewarming mechanism,
addition to previous work [18], [22], [23] discussed in Section II,
in relation to the overall end-to-end runtime of the workflow.
Kijak et al. [45] propose a deadline-aware resource scheduling
Fig. 23 shows a significant reduction in the average pro-
approach for scientific workflows, focusing on cost-efficiency.
portion of mapping delay in the workflow. This indicates that
Lin et al. [24] describes function workflows as non-DAG mod-
the StepConf workflow engine, by incorporating the function
els, including loops and self-loops. They propose a probabilistic
prewarming mechanism, reduces cold start overhead, further
refinement of the critical path algorithm to address the problem
improving workflow performance and cost savings.
of finding the optimal cost under performance constraints and
the optimal performance within budget constraints. StepConf
VIII. RELATED WORK addresses this issue through an online approach, jointly optimiz-
SLO-Aware Resource Scheduling: There are some existing ing parallelism to significantly save cost while ensuring SLOs.
works that study SLO guarantees [35], [36], [37], [38]. Zhang Function Cold Start: The cold start overhead of serverless
et al. [36] develop an online, QoS-aware, data-driven cluster functions presents a significant challenge, as highlighted in [2],
[46], [47]. Some researchers focus on accelerating the startup [13] B. Carver, J. Zhang, A. Wang, A. Anwar, P. Wu, and Y. Cheng,
time of sandboxes [48], [49], [50], [51], [52], [53], while others “Wukong: A scalable and locality-enhanced framework for server-
less parallel computing,” in Proc. ACM Symp. Cloud Comput., 2020,
aim to reduce the frequency of cold starts [54], [55], [56], [57]. pp. 1–15.
Defuse [58] utilizes historical invocation data to analyze func- [14] Z. Li et al., “FaaSFlow: Enable efficient workflow execution for function-
tion relationships, prewarming functions to avoid cold starts. as-a-service,” in Proc. ACM Int. Conf. Architectural Support Program.
Lang. Operating Syst., 2022, pp. 782–796.
Xanadu [59] has also designed a prewarming mechanism for [15] E. Jonas, Q. Pu, S. Venkataraman, I. Stoica, and B. Recht, “Occupy the
cascading function work chains. Unlike these approaches, Step- cloud: Distributed computing for the 99%,” in Proc. ACM Symp. Cloud
Conf introduces a Configuration-Aware function prewarming Comput., 2017, pp. 445–451.
[16] V. Shankar et al., “Serverless linear algebra,” in Proc. ACM SoCC, 2020,
mechanism, considering the memory configurations and deter- pp. 281–295.
mining the number of prewarmed container instances based on [17] AWS lambda power tuning, 2021. [Online]. Available: https://aws.
parallelism, thereby reducing cold start overhead more effec- amazon.com/lambda/pricing
[18] A. Casalboni, “AWS lambda power tuning,” 2020. [Online]. Available:
tively. https://github.com/alexcasalboni/aws-lambda-power-tuning
[19] F. Liu and Y. Niu, “Demystifying the cost of serverless computing: Towards
a win-win deal,” IEEE Trans. Parallel Distrib. Syst., vol. 35, no. 1, pp. 59–
IX. CONCLUSION 72, Jan. 2024.
[20] Databases on AWS, 2024. [Online]. Available: https://aws.amazon.com/
We propose StepConf, an SLO-aware dynamic resource con- products/databases
figuration framework for serverless function workflows. We [21] Amazon S3: Object storage built to retrieve any amount of data from
develop a heuristic algorithm to dynamically configure each anywhere, 2024. [Online]. Available: https://aws.amazon.com/s3
[22] N. Akhtar, A. Raza, V. Ishakian, and I. Matta, “COSE: Configuring server-
function step, ensuring end-to-end SLOs for the workflow. Fur- less functions using statistical learning,” in Proc. IEEE Conf. Comput.
thermore, StepConf utilizes piece-wise fitting models and quan- Commun., 2020, pp. 129–138.
tile regression models to accurately estimate the performance of [23] A. Mahgoub, E. B. Yi, K. Shankar, S. Elnikety, S. Chaterji, and S.
Bagchi, “{ORION } and the three rights: Sizing, bundling, and prewarming
function steps under different configuration parameters. In ad- for serverless { DAGs},” in Proc. USENIX Symp. Operating Syst. Des.
dition, we design a workflow engine and Function Manager that Implementation, 2022, pp. 303–320.
support various FaaS platforms and reduce cold start overhead [24] C. Lin and H. Khazaei, “Modeling and optimization of performance and
cost of serverless applications,” IEEE Trans. Parallel Distrib. Syst., vol. 32,
through Configuration-Aware function prewarming. Compared no. 3, pp. 615–632, Mar. 2021.
to existing strategies, StepConf can improve performance by up [25] Z. Wen, Y. Wang, and F. Liu, “StepConf: SLO-aware dynamic resource
to 5.6 × under the same cost budget and achieve up to a 40% configuration for serverless function workflows,” in Proc. IEEE Conf.
Comput. Commun., 2022, pp. 1868–1877.
cost reduction while maintaining the same level of performance. [26] Y.-K. Kwok and I. Ahmad, “Dynamic critical-path scheduling: An effec-
tive technique for allocating task graphs to multiprocessors,” IEEE Trans.
Parallel Distrib. Syst., vol. 7, no. 5, pp. 506–521, May 1996.
REFERENCES [27] Serverless warmup plugin, 2022. [Online]. Available: https://github.com/
juanjoDiaz/serverless-plugin-warmup
[1] I. Baldini et al., “Serverless computing: Current trends and open problems,”
[28] AWS step functions: Visual workflows for modern applications, 2024.
in Research Advances in Cloud Computing, Berlin, Germany: Springer,
[Online]. Available: https://aws.amazon.com/step-functions
2017, pp. 1–20.
[29] Azure logic apps, 2024. [Online]. Available: https://learn.microsoft.com/
[2] Z. Li, L. Guo, J. Cheng, Q. Chen, B. He, and M. Guo, “The serverless
zh-cn/azure/logic-apps/logic-apps-overview
computing survey: A technical primer for design architecture,” ACM
[30] E. Bernhardsson et al., “Luigi,” 2022. [Online]. Available: https://github.
Comput. Surv., vol. 54, no. 10s, pp. 1–34, 2022.
com/spotify/luigi, Spotify.
[3] Amazon AWS lambda, 2024. [Online]. Available: https://aws.amazon.
[31] Haproxy load balancer, 2023. [Online]. Available: https://github.com/
com/lambda/
haproxy/haproxy
[4] F. Romero, M. Zhao, N. J. Yadwadkar, and C. Kozyrakis, “Llama: A
[32] Keepalived: Loadbalancing and high-availability, 2023. [Online]. Avail-
heterogeneous & serverless framework for auto-tuning video analytics
able: https://github.com/acassen/keepalived
pipelines,” in Proc. ACM Symp. Cloud Comput., 2021, pp. 1–17.
[33] E. Jonas et al., “Cloud programming simplified: A berkeley view on
[5] L. Ao, L. Izhikevich, G. M. Voelker, and G. Porter, “Sprocket: A serverless
serverless computing,” 2019, arXiv: 1902.03383.
video processing framework,” in Proc. ACM Symp. Cloud Comput., 2018,
[34] F. Wu, Q. Wu, and Y. Tan, “Workflow scheduling in cloud: A survey,” J.
pp. 263–274.
Supercomputing, vol. 71, no. 9, pp. 3373–3418, 2015.
[6] S. Fouladi et al., “Encoding, fast and slow: Low-latency video processing
[35] R. S. Kannan, L. Subramanian, A. Raju, J. Ahn, J. Mars, and L. Tang,
using thousands of tiny threads,” in Proc. USENIX Conf. Netw. Syst. Des.
“GrandSLAm: Guaranteeing SLAs for jobs in microservices execution
Implementation, 2017, pp. 363–376.
frameworks,” in Proc. 14th ACM EuroSys Conf., 2019, pp. 1–16.
[7] J. Carreira, P. Fonseca, A. Tumanov, A. Zhang, and R. Katz, “Cirrus: A
[36] Y. Zhang, W. Hua, Z. Zhou, G. E. Suh, and C. Delimitrou, “Sinan: ML-
serverless framework for end-to-end ML workflows,” in Proc. ACM Symp.
based and QoS-aware resource management for cloud microservices,” in
Cloud Comput., 2019, pp. 13–24.
Proc. ACM Int. Conf. Architectural Support Program. Lang. Operating
[8] F. Xu, Y. Qin, L. Chen, Z. Zhou, and F. Liu, “λDNN: Achieving predictable
Syst., 2021, pp. 167–181.
distributed DNN training with serverless architectures,” IEEE Trans. Com-
[37] H. Mao, M. Schwarzkopf, S. B. Venkatakrishnan, Z. Meng, and
put., vol. 71, no. 2, pp. 450–463, Feb. 2022.
M. Alizadeh, “Learning scheduling algorithms for data processing
[9] J. Thorpe et al., “Dorylus: Affordable, scalable, and accurate GNN training
clusters,” in Proc. ACM Special Int. Group Data Commun., 2019,
with distributed CPU servers and serverless threads,” in Proc. USENIX
pp. 270–288.
Symp. Operating Syst. Des. Implementation, 2021, pp. 495–514.
[38] Y. Li, F. Liu, Q. Chen, Y. Sheng, M. Zhao, and J. Wang, “MarVeLScaler:
[10] V. Sreekanti, H. Subbaraj, C. Wu, J. E. Gonzalez, and J. M. Heller-
A multi-view learning based auto-scaling system for MapReduce,” IEEE
stein, “Optimizing prediction serving on low-latency serverless dataflow,”
Trans. Cloud Comput., vol. 10, no. 1, pp. 506–520, First Quarter, 2022.
2020, arXiv: 2007.05832.
[39] F. Romero, Q. Li, N. J. Yadwadkar, and C. Kozyrakis, “INFaaS: Automated
[11] S. Fouladi et al., “From laptop to lambda: Outsourcing everyday jobs
model-less inference serving,” in Proc. USENIX Annu. Tech. Conf., 2021,
to thousands of transient functional containers,” in Proc. USENIX Conf.
pp. 397–411.
Usenix Annu. Tech. Conf., 2019, pp. 475–488.
[40] A. Singhvi, A. Balasubramanian, K. Houck, M. D. Shaikh, S. Venkatara-
[12] H. Zhang, Y. Tang, A. Khandelwal, J. Chen, and I. Stoica, “Caerus: Nimble
man, and A. Akella, “Atoll: A scalable low-latency serverless platform,”
task scheduling for serverless analytics,” in Proc. USENIX Conf. Netw.
in Proc. ACM Symp. Cloud Comput., 2021, pp. 138–152.
Syst. Des. Implementation, 2021, pp. 653–669.
[41] O. Alipourfard, H. H. Liu, J. Chen, S. Venkataraman, M. Yu, and M. Zhang, Qiong Chen received the BEng and MEng degrees
“CherryPick: Adaptively unearthing the best cloud configurations for big from the School of Computer Science and Technol-
data analytics,” in Proc. USENIX Conf. Netw. Syst. Des. Implementation, ogy, Huazhong University of Science and Technol-
2017, pp. 469–482. ogy, Wuhan, China. He is currently a research staff
[42] S. Venkataraman, Z. Yang, M. Franklin, B. Recht, and I. Stoica, “Ernest: with the Central Software Institute of Huawei. His
Efficient performance prediction for {Large-Scale} advanced analytics,” in research interests include applied machine learning
Proc. USENIX Conf. Netw. Syst. Des. Implementation, 2016, pp. 363–378. and serverless computing. He received the Best Paper
[43] S. Eismann, J. Grohmann, E. Van Eyk, N. Herbst, and S. Kounev, “Pre- Award of ACM International Conference on Future
dicting the costs of serverless workflows,” in Proc. ACM/SPEC Int. Conf. Energy Systems (ACM e-Energy) in 2018.
Perform. Eng., 2020, pp. 265–276.
[44] T. Elgamal, “Costless: Optimizing cost of serverless computing through
function fusion and placement,” in Proc. IEEE Symp. Edge Comput., 2018,
pp. 300–312.
[45] J. Kijak, P. Martyna, M. Pawlik, B. Balis, and M. Malawski, “Challenges
for scheduling scientific workflows on cloud functions,” in Proc. IEEE
11th Int. Conf. Cloud Comput., 2018, pp. 460–467.
[46] J. M. Hellerstein et al., “Serverless computing: One step forward, two steps Yipei Niu received the BEng degree from Henan
back,” 2018, arXiv: 1812.03651. University, and the PhD degree from the Huazhong
[47] Q. Pei, Y. Yuan, H. Hu, Q. Chen, and F. Liu, “AsyFunc: A high-performance University of Science and Technology. His research
and resource-efficient serverless inference system via asymmetric func- interests include cloud computing, serverless comput-
tions,” in Proc. ACM Symp. Cloud Comput., 2023, pp. 324–340. ing, container networking, and FPGA acceleration.
[48] D. Du et al., “Catalyzer: Sub-millisecond startup for serverless computing
with initialization-less booting,” in Proc. ACM Int. Conf. Architectural
Support Program. Lang. Operating Syst., 2020, pp. 467–481.
[49] E. Oakes et al., “SOCK: Rapid task provisioning with serverless-optimized
containers,” in Proc. USENIX Conf. Usenix Annu. Tech. Conf., 2018,
pp. 57–70.
[50] Z. Li et al., “RunD: A lightweight secure container runtime for high-density
deployment and high-concurrency startup in serverless computing,” in Zhen Song is currently working toward the master’s
Proc. USENIX Annu. Tech. Conf., 2022, pp. 53–68. degree with the School of Computer Science and
[51] A. Mohan, H. S. Sane, K. Doshi, S. Edupuganti, N. Nayak, and V. Technology, Huazhong University of Science and
Sukhomlinov, “Agile cold starts for scalable serverless,” in Proc. 11th Technology, China. His research interests include
USENIX Conf. Hot Top. Cloud Comput., 2019, pp. 3 357 034–3 357 060. serverless computing and WebAssembly.
[52] A. Agache et al., “Firecracker: Lightweight virtualization for serverless
applications,” in Proc. USENIX Conf. Netw. Syst. Des. Implementation,
2020, pp. 419–434.
[53] J. Cadden, T. Unger, Y. Awad, H. Dong, O. Krieger, and J. Appavoo,
“SEUSS: Skip redundant paths to make serverless fast,” in Proc. 15th Eur.
Conf. Comput. Syst., 2020, pp. 1–15.
[54] M. Shahrad et al., “Serverless in the wild: Characterizing and optimizing
the serverless workload at a large cloud provider,” in Proc. USENIX Conf. Quanfeng Deng is currently working toward the
Usenix Annu. Tech. Conf., 2020, pp. 205–218. PhD degree with the School of Computer Science
[55] R. B. Roy, T. Patel, and D. Tiwari, “IceBreaker: Warming serverless and Technology, Huazhong University of Science
functions better with heterogeneity,” in Proc. ACM Int. Conf. Architectural and Technology, China. His research interests include
Support Program. Lang. Operating Syst., 2022, pp. 753–767. serverless computing and cloud-native networking.
[56] A. Fuerst and P. Sharma, “FaasCache: Keeping serverless computing alive
with greedy-dual caching,” in Proc. ACM Int. Conf. Architectural Support
Program. Lang. Operating Syst., 2021, pp. 386–400.
[57] L. Pan, L. Wang, S. Chen, and F. Liu, “Retention-aware container caching
for serverless edge computing,” in Proc. IEEE Conf. Comput. Commun.,
2022, pp. 1069–1078.
[58] J. Shen, T. Yang, Y. Su, Y. Zhou, and M. R. Lyu, “Defuse: A dependency-
guided function scheduler to mitigate cold starts on FaaS platforms,” in Fangming Liu (Senior Member, IEEE) received the
Proc. IEEE 41st Int. Conf. Distrib. Comput. Syst., 2021, pp. 194–204. BEng degree from the Tsinghua University, Beijing,
[59] N. Daw, U. Bellur, and P. Kulkarni, “Xanadu: Mitigating cascading cold and the PhD degree from the Hong Kong Univer-
starts in serverless function chain deployments,” in Proc. 21st Int. Middle- sity of Science and Technology, Hong Kong. He is
ware Conf., 2020, pp. 356–370. currently a full professor with the Huazhong Uni-
versity of Science and Technology, Wuhan, China.
His research interests include cloud computing and
edge computing, data center and green computing,
Zhaojie Wen is currently working toward the PhD SDN/NFV/5 G, and applied ML/AI. He received the
degree with the School of Computer Science and National Natural Science Fund (NSFC) for Excellent
Technology, Huazhong University of Science and Young Scholars and the National Program Special
Technology, China. His research interests include Support for Top-Notch Young Professionals. He is a recipient of the Best
serverless computing, resource allocation, and task Paper Award of IEEE/ACM IWQoS 2019, ACM e-Energy 2018 and IEEE
scheduling. GLOBECOM 2011, the First Class Prize of Natural Science of the Ministry
of Education in China, as well as the Second Class Prize of National Natural
Science Award in China.

Joint Optimization of Parallelism and Resource Configuration For Serverless Func

Uploaded by

Copyright:

Available Formats

Joint Optimization of Parallelism and Resource Configuration For Serverless Func

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Joint Optimization of Parallelism and Resource Configuration For Serverless Func

Uploaded by

Copyright:

Available Formats

560 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 35, NO.

Joint Optimization of Parallelism and Resource

Third, we integrate an advanced workflow engine into Step-

discuss the design motivation behind workflow configuration

A. Configuration for Multi-Step Serverless Workflows

improving workflow performance and reducing costs. Jointly

C. Performance Fluctuations in Function Steps

r Minimizing Function Cold Starts: Implementing strategies

the edge vi → vj , meaning that the operation of function step TABLE I

We use binary variable xi (θ) to indicate whether function step

Algorithm 1: Global-Cached Most Cost-Effective Critical

Fig. 9. Algorithm description diagram.

sub-SLO si for each function step, where

By doing this, we relax the constraint (6) by:

Then we can reduce the problem (7) of optimizing a DAG to

Based on this, we propose Global-cached Most Cost-effective V. CONFIGURATION-AWARE FUNCTION PREWARM

serves as the core component of StepConf, executes each func-

Fig. 12. User code example of object detection function step.

Function Wrapper class we designed to override the user’s entry

Fig. 13. Machine learning workflow.

We refer to [17] to define the cost expenses of the Knative

Fig. 16. Comparison of fitting results for functions in different types.

Fig. 18. End to End duration time under different SLOs.

Fig. 20. Cost of workflows under different SLOs.

manager tailored for interactive cloud microservices. Mao et

You might also like