In Function as a Service (FaaS), a serverless computing variant, customers deploy functions instead of complete virtual machines or Linux containers. It is the cloud provider who maintains the runtime environment for these functions. FaaS products are offered by all major cloud providers (e.g. Amazon Lambda, Google Cloud Functions, Azure Functions); as well as standalone open-source software (e.g. Apache OpenWhisk) with their commercial variants (e.g. Adobe I/O Runtime or IBM Cloud Functions). We take the bottom-up perspective of a single node in a FaaS cluster. We assume that all the execution environments for a set of functions assigned to this node have been already installed. Our goal is to schedule individual invocations of functions, passed by a load balancer, to minimize performance metrics related to response time. Deployed functions are usually executed repeatedly in response to multiple invocations made by end-users. Thus, our scheduling decisions are based on the information gathered locally: the recorded call frequencies and execution times. We propose a number of heuristics, and we also adapt some theoretically-grounded ones like SEPT or SERPT. Our simulations use a recently-published Azure Functions Trace. We show that, compared to the baseline FIFO or round-robin, our data-driven scheduling decisions significantly improve the performance.

中文翻译：

---

无服务器计算中的数据驱动调度，以减少响应时间

在无服务器计算变体功能即服务（FaaS）中，客户部署功能而不是完整的虚拟机或Linux容器。云提供商负责维护这些功能的运行时环境。所有主要的云提供商（例如，Amazon Lambda，Google Cloud Functions，Azure Functions）都提供FaaS产品；以及带有其商业版本（例如Adobe I / O运行时或IBM Cloud Functions）的独立开源软件（例如Apache OpenWhisk）。我们采用FaaS集群中单个节点的自下而上的观点。我们假定已经安装了分配给该节点的一组功能的所有执行环境。我们的目标是安排负载平衡器传递的各个函数调用，以最大程度地减少与响应时间有关的性能指标。响应于最终用户的多次调用，通常会重复执行已部署的功能。因此，我们的调度决策是基于本地收集的信息：记录的呼叫频率和执行时间。我们提出了许多启发式方法，并且还改编了一些具有理论基础的方法，例如SEPT或SERPT。我们的模拟使用最近发布的Azure Functions跟踪。我们表明，与基线FIFO或循环机制相比，我们的数据驱动调度决策显着提高了性能。我们的模拟使用最近发布的Azure Functions跟踪。我们表明，与基线FIFO或循环机制相比，我们的数据驱动调度决策显着提高了性能。我们的模拟使用最近发布的Azure Functions跟踪。我们证明，与基线FIFO或循环机制相比，我们的数据驱动调度决策显着提高了性能。