Response Time Aware Operator Placement for Complex Event Processing in Edge Computing

Abstract

A typical complex event processing (CEP) service is composed by a set of operators organized as a directed acyclic graph. This kind of service is usually used to handle large amounts of real-time data. Meanwhile, edge computing has been widely accepted as a new paradigm to improve the QoS of deployed services by making the services closer to the data. Thus, the response time, which is a crucial QoS metric for CEP services, can be significantly reduced by deploying CEP services on the edge network. However, it is often unlikely for a single node of the edge network to host all operators of a CEP service due to the limited computing resources. Therefore, it is desirable for a CEP service to place its operators on different nodes of the edge network to keep the response time low, especially when the input rate of the CEP service significantly increases. In this paper, we reduce the average response time of CEP services by deploying the operators on the edge nodes dynamically according to the predicted response time of CEP services. Specifically, we first propose a system model to capture the response time of the CEP services, based on which we formulate the problem of the optimal placement of CEP operators in the edge network. We then propose an algorithm that predicts the response time of CEP services and deploys the operators on the edge nodes with the minimum predicted delay. A simulation-based evaluation demonstrates that, compared with two state-of-the art algorithms, our algorithm can reduce the total response time by 33$\%$ and 45$\%$ on average, respectively.

1 Introduction

Typically, a complex event processing (CEP) service is used to handle large amounts of real-time data by using a set of operators organized as a directed acyclic graph called operator graph. In practice, CEP services are usually deployed on cloud data centers. However, this deployment results in delivering data from the edge of the network to remote cloud data centers and thus seriously reduces QoS of CEP services due to the long distance between data sources and remote cloud data centers, as well as the mass data transmission.

To address this issue, a new paradigm, called edge computing [12], has been proposed to improve the QoS of deployed services by moving services from cloud data centers to the edge of network. Consequently, a growing body of work [2, 4, 14] focuses on deploying CEP services on the edge network (i.e., nearest to the user [14]) to improve the QoS of CEP services, e.g., to reduce the response time. However, due to the limited computing capacity, lots of users queries, and large amounts of input events, congestion can easily occur at the nearest edge node and increase the response time of CEP services dramatically. Therefore, it is important to be aware of the response time of a CEP service during the placement of its operators on suitable nodes of the edge network to keep the response time low, especially when the input rate of the CEP service significantly increases. We use the following example to demonstrate this situation.

Consider the example shown in Fig. 1. This figure depicts the placement of a CEP service that queries traffic accident events, which are defined as a lane switch event after a decreased speed event. The CEP service has an operator graph consisting of a lane operator, a speed operator, and an accident operator. The edge network contains three edge nodes: $v_0$, $v_{1}$, and $v_{2}$. The resources capacity of the nodes $v_0$, $v_{1}$, and $v_{2}$ are 1, 2, and 2, respectively. The resources refers to computing resources, such as CPU, etc. Connected devices deliver and cache original data to the nearest node $v_{0}$ in the edge network. An intuitive strategy of reducing the response time is to deploy operators on the nearest edge node [14]. As Fig. 1 shows, the lane operator is deployed on the nearest edge node $v_{0}$. At this moment, $v_{0}$ has no resources to host other operators. Thus, the speed operator and the accident operator are deployed on the edge node $v_{1}$ which is the second nearest edge node except $v_{0}$. However, when the input rate of the CEP services largely increases, large amounts of data have to be delivered from the edge node $v_{0}$ to $v_{1}$. The congestion will occur and result in increasing the response time. On the other hand, another placement strategy is to deploy operators distributed in the edge network to balance the load between edge nodes in advance [6]; for example, deploying the accident operator to the edge node $v_{2}$ to reduce the load of $v_{1}$. When the input rate is high, this placement can reduce the response time compared to the first placement. However, when the input rate remains low, this placement increases the transmission delay between edge nodes and makes the response time even worse. In this paper, we argue that it is important to balance the load of different edge nodes during the placement of CEP operators by being aware of the response time of the operator graphs.

To achieve this goal, we first propose a combined model including CEP model and edge model to capture the response time of CEP services. Based on the models, we predict the delay of these edge nodes according to the monitored information. We then prove the optimal operator placement for CEP in edge computing is NP-hard. Finally, we propose a novel approximation-based algorithm that deploys the operators on the edge node with the lowest predicted delay. We generate 100 operator graphs and 30 edge networks for our simulation-based evaluation. The result demonstrates that our approach is able to maintain low response time when the input rate of CEP services significantly increases.

This paper makes the following three contributions: (1) We propose a system model to capture the response time of CEP services, and formulate a novel optimization problem, that is, to find an optimal placement of CEP operators in the edge network such that the response time of the CEP services is minimized. (2) We prove the optimal operator placement problem for CEP in edge computing is NP-hard. (3) We propose a novel response time aware operator placement algorithm that keeps the average response time of the operator graphs low.

The rest of the paper is structured as follows. Section 2 reviews related work. Section 3 describes the system models and problem formulation. Section 4 presents our response time aware operator placement algorithm. Section 5 reports the evaluation results, and finally, Sect. 6 concludes the paper.

Fig. 1.

Deploy operators of a CEP service that queries accident events on the edge network.

2 Related Work

Operator placement problem has been widely studied in the last decades. The basic form of the operator placement problem is stated as: given a network of N nodes with some or all of them generating data processed by an operator, place the operator in the network so as to reduce the network traffic [16]. Several placement algorithms [2, 10, 11, 16] have been proposed. These algorithms are characterized by different assumptions and optimization goals. Pietzuch et al. [10] design a stream-based overlay network for operator placement in distributed stream-processing (DSP) systems that minimizes the network usage of a query, while keeping the query delay low and picking nodes with adequate bandwidth. However, their operator model is not organized as operator graphs. Rizou et al. [11] present a distributed placement algorithm that minimizes the bandwidth-delay product of data streams between operators. However, their approach does not take the resources of the nodes into consider. Tziritas et al. [16] propose an approach enabling both single and group operator migrations using evictions of hosted operators. Although this work takes resources of nodes in the network into consider, it focuses on how to migrate operators to improve a placement of operators. Cardellini et al. [2] propose a general formulation of DSP placement in distributed network. This work focuses on the scenes that data sources are distributed in large scale network and do not take the input rate of CEP service into consideration. In contrast, we focus on deploying CEP services to process data near an edge node to infer meaningful events, especially when the input rate of CEP services significantly increases.

Edge computing is the computational infrastructures that make services closer to the end users [12]. The same concept is also called as cloudlet [13] or fog computing [1]. Taneja et al. [15] conduct experiments to demonstrate that edge computing can effectively improve its QoS. Hong et al. [4] proposed an opportunistic spatio-temporal CEP hosted by edge computing. As far as we know, this is the earliest work to deploy CEP on edge computing. How to offload applications to edge nodes [8, 18] is another research interest that quite close to the operator placement problem in edge computing. The goal of this work is to minimize the cost of a user. However, our goal is to minimize the average response time of the CEP services queries. Saurez et al. [14] propose an incremental deployment approach to greedily deploy operators on the nearest edge node. However, they all do not consider the change of the input rate. Jia et al. propose an user to edge computing allocation in wireless metropolitan area networks [5] and a load balance approach to finding an optimal redirection of tasks between edge nodes [6]. However, the task model of this work has no graph structure. Our work is designed for CEP operator graphs whose input rate change according to the data sources.

3 Models and Problem Formulation

In this section, we first discuss our CEP model and edge computing model. Then we use these models to calculate the response time of CEP services, to give the operator placement problem statement, and to prove this problem is NP-hard. Table 1 summarizes the symbols that are used in this paper.

Table 1. Main notation adopted in the paper

3.1 CEP Model

We assume that $N_{cep}$ CEP services queries are sent to an edge node. A CEP service can be represented as an operator graph $G_{cep}$ = ($\varOmega$, L). $\varOmega$ denotes the set of operators. L denotes the event streams between the data sources, the operators, and the consumer. Each operator $\omega _{i} \in \varOmega$ has the attributes c($\omega _{i}$), denoting the amount of resources required for the operator $\omega _{i}$ execution. The resources required to execute an operator include CPU, memory, etc. We simplified these resource models as unit resources, like other works [2, 6].

For example, in Fig. 1, $\varOmega$ contains the speed operator $\omega _{speed}$, the lane operator $\omega _{lane}$, and the accident operator $\omega _{accident}$. L contains (source, $\omega _{speed}$), (source, $\omega _{lane}$), ($\omega _{speed}$, $\omega _{accident}$), ($\omega _{lane}$, $\omega _{accident}$), and ($\omega _{accident}$, user). c($\omega _{speed}$), c($\omega _{lane}$), and c($\omega _{accident}$) are all one-resource units.

3.2 Edge Computing Model

Edge nodes are represented as vertexes $V_{edge}$. The network connections between edge nodes are represented as $E_{edge}$. The edge network are represented as $G_{edge}$ = ($V_{edge}$, $E_{edge}$). Every node $v_{i}$ in the edge network has two attributes: (1) c($v_{i}$), the amount of resources available in the edge node $v_{i}$; (2) $\lambda (v_{i})$, the events execution rate of the edge node $v_{i}$. Every network connection ($v_{i}$, $v_{j}$) has the attribute w($v_{i}$, $v_{j}$), the transmission rate between the edge nodes $v_{i}$ and $v_{j}$.

When a user sends a query to the nearest edge node for computing resources, the edge node manages the placement of the operator graph. This edge node is called as manage edge node. The manage edge node monitors the information of the nearby edge nodes within H hops. These nearby edge nodes are called candidate edge nodes. The operators can be placed on either the manage edge node or candidate edge nodes. Thus, the size of the edge network is limited by the number of hops H. H becomes larger when the operators have no suitable edge nodes to be placed.

3.3 Response Time

The response time of an operator graph $G_{cep}$ can be calculated as:

$$\begin{aligned} T_{r}(G_{cep}) = \max \limits _{p \in \pi _{G_{cep}}} T_{p} \end{aligned}$$

(1)

where $\max \limits _{p \in \pi _{G_{cep}}} T_{p}$ means the worst end-to-end delay from a data source to the consumer. $T_{p}$ denotes the delay of a path in the operator graph $G_{cep}$. The path p can be represented as $(\omega _{p_{1}}, \omega _{p_{2}}, \dots , \omega _{p_{n_{p}}} )$, where $n_{p}$ denotes the number of operators in p. These operators are deployed on the edge nodes $(v_{p_{1}}, v_{p_{2}}, \dots , v_{p_{n_{p}}} )$.

For example, in Fig. 2, the end-to-end delay of $path_{1}$ is the worst. Thus, the response time of operator graph $G_{0}$ is $T_{r}(G_{0})$ that equals to 120 ms. $path_{1}$ is (source, $\omega _{speed}$, $\omega _{accident}$, user). In Fig. 1(a), X($path_{1}$) = ($v_{0}$, $v_{1}$, $v_{1}$, $v_{0}$).

For $T_{p}$, we have:

$$\begin{aligned} T_{p} = \sum ^{n_{p}-1}_{i = 0} d(v_{p_{i}}, v_{p_{i+1}}) + \sum ^{n_{p}}_{i=0} T_{E}(\omega _{i}) + \sum ^{n_{p}}_{i=0}T_{q}(\omega _{i}) \end{aligned}$$

(2)

where $d(v_{p_{i}}, v_{p_{i+1}})$ denotes the transmission delay between the edge nodes $v_{p_{i}}$ and $v_{p_{i+1}}$. $T_{E}(\omega _{i})$ denotes the processing delay of events in the operator $\omega _{i}$. $T_{q}(\omega _{i})$ denotes the queuing delay of events in the operator $\omega _{i}$. In addition to the above three delays, there is also the propagation delay. However, in the edge network, the propagation delay, which is too low, can be ignored.

The transmission delay $d(v_{p_{i}}, v_{p_{i+1}})$ can be calculated as:

$$\begin{aligned} d(v_{p_{i}}, v_{p_{i+1}}) = \frac{sz}{w(v_{p_{i}}, v_{p_{i+1}})} \end{aligned}$$

(3)

where sz is the size of an event packet.

The processing delay of events in the operator $\omega _{i}$ can be calculated as:

$$\begin{aligned} T_{E}(\omega _{i}) = \frac{1}{\lambda _(v_{p_{i})}} \end{aligned}$$

(4)

where the average event process rate of $v_{p_{i}}$ is $\lambda ({v_{p_{i}}})$ events per second (eps).

The queuing delay mainly depends on the congestion level of the router. The event rate from $v_{p_{i}}$ to $v_{p_{i+1}}$ can be represented as $r(p_{i},p_{i+1})$ eps. The number of channel between edge node $v_{p_{i}}$ and $v_{p_{i+1}}$ is n$(v_{p_{i}},v_{p_{i+1}})$. The queuing delay of an operator $\omega _{i}$ in a period t is calculated as:

$$\begin{aligned} T_{q}(\omega _{i}) = {\left\{ \begin{array}{ll} \frac{t \times \textit{sz} \times r(p_{i},p_{i+1})}{w(v_{p_{i}},v_{p_{i+1}})}, &{} \text { if}\, E_{c}(p_{i}) > 1\\ \frac{E_{c}(p_{i})}{w(v_{p_{i}},v_{p_{i+1}})-r(p_{i},p_{i+1})} + \frac{1}{w(v_{p_{i}},v_{p_{i+1}})}, &{} \text { if}\, E_{c}(p_{i}) <= 1 \end{array}\right. } \end{aligned}$$

(5)

$$\begin{aligned} E_{c}(p_{i}) = E_{c}(n(v_{p_{i}},v_{p_{i+1}}),\frac{\textit{sz} \times r(p_{i},p_{i+1})}{w(v_{p_{i}},v_{p_{i+1}})}) \end{aligned}$$

(6)

$$\begin{aligned} E_{c}(n,u) = \frac{\frac{u^{n}}{n!}}{\frac{u^{n}}{n!}+(1-u/n)\sum ^{n-1}_{k}\frac{u^{k}}{k!}} \end{aligned}$$

(7)

Equation 7 is known as Erlang’s C formula to calculate the queuing delay [7].

If the bandwidth is larger than the event rate in the connection, the queuing time is calculated as Erlang’s C formula. Otherwise, the queuing time is calculated as $\frac{N_{t}}{w(v_{p_{i}},v_{p_{i+1}})}$, $N_{t} = t \times sz \times r(p_{i},p_{i+1})$. $N_{t}$ is the size of the data sent to the queue in a period t. To avoid frequent replacements caused by excessive changes in the input rate of operator graphs, we calculate the average event rate in the last ten seconds as r($p_{i}$,$p_{i+1}$).

Initially, when an operator $\omega _{i}$ has not been decided where to be deployed, the transmission delay is calculated as $\frac{sz}{\bar{w}}$, where $\bar{w}$ denotes the average transmission rate of the connections in the edge network. The execution time is calculated as $\frac{1}{\bar{\lambda }}$, where $\bar{\lambda }$ denotes the average event process rate of edge nodes.

3.4 Operator Placement Problem in Edge Computing

When the manage edge node receives a CEP service query, the operator graph is pushed into an operator-graphs-queue Q = $\{G_{cep}(1),\dots ,G_{cep}(N_{cep})\}$. Optimal operator placement problem in edge computing consists in determining a suitable mapping between operators $\varOmega$ and edge nodes $V_{edge}$ to minimize the average response time of operator graphs. For every operator $\omega _{i}$, we can get an edge node $v_{u}$ that place $\omega _{i}$ on $v_{u}$, to minimize the average response time $T_{r}(Q)$:

$$\begin{aligned} T_{r}(Q) = \frac{\sum _{k=1}^{N_{cep}}T_{r}(G_{cep}(k))}{N_{cep}} \end{aligned}$$

(8)

and to satisfy:

$$\begin{aligned} \forall v_{u} \in V_{edge}, c(v_{u}) \ge \sum ^{|\varOmega |}_{i=1}((X(\omega _{i}) == v_{u})?c(\omega _{i}):0) \end{aligned}$$

(9)

Then, we prove this optimal problem is a NP-hard problem.

Theorem 1

Optimal operator placement problem for CEP in edge computing is an NP-hard problem.

Proof

First, we prove the decision problem of the optimal operator placement problem is NP-hard. The decision problem is stated as: $N_{cep}$ operator graphs containing $|\varOmega |$ operators and an edge network, can the operator graphs have a feasible placement? In the special case: the input rate of $N_{cep}$ operator graphs are the same; the edge network has only two edge nodes, $V_{edge}$ = $\{v_{i}$,$v_{j}\}$, with capacity c($v_{i}$) = c($v_{j}$) = ($\sum ^{|\varOmega |}_{k=1}{c(\omega _{k})})/2$; w($v_{i}$, $v_{j}$) is infinite, $\lambda$($v_{i}$) = $\lambda$($v_{j}$). The resulting problem is the Partition problem [3] which is known to be NP-hard. Finally, because the special case is NP-hard, the general decision problem is NP-hard as well. The optimization problem is at least as hard as the decision problem. Thus, optimal operator placement problem for CEP in edge computing is an NP-hard problem.

Thus, if P $\ne$ NP, optimal operator placement problem for CEP in edge computing cannot be solved in polynomial time. Thus, we propose an approximation-based algorithm to solve this problem.

4 Algorithm

In this section, we propose a novel algorithm that balances the response time of different paths to achieve the minimum average response time of operator graphs (Eq. 8). The basic idea is to predict the end-to-end delay of all paths, and then improve the placement of the path with the worst end-to-end delay, which can directly improve the response time of the operator graph. The algorithm deploys the operator logically closest to data source in the path on the edge node with the minimum delay.

Fig. 2.

Algorithm 1 preferentially deploys the speed operator.

4.1 Response Time Aware Operator Placement Algorithm

The response time of the operator graphs is calculated by Eq. 1. Algorithm 1 first calculates the response time of different paths in an operator graph, and then improves the placement of the path with the largest end-to-end delay. We first find the operator graph $g_i$ with the maximum response time (line 15) and the path $p_i$ with the maximum end-to-end delay in gi (line 16). The end-to-end delay of the path $p_i$ limits the response time of the operator graph $g_i$. Thus, we try to improve the placement of $p_i$. Then, we find the operator $\omega _{tar}$ whose input stream is the output stream of last deployed operator $\omega _{src}$ in the path $p_i$, and the edge node $v_{tar}$ that has the minimum delay of the connection to $\omega _{src}$. Algorithm 1 deploys the operator $\omega _{tar}$ (line 18) on the edge node $v_{tar}$ (line 19).

For example, in the case of Fig. 1, at the moment that only the operator $\omega _{lane}$ is deployed, Fig. 2 shows how to select the operator $\omega _{tar}$ in the operator graph. Because the response time of $path_{1}$ is the largest response time in the paths ($path_{1}$ and $path_{2}$) and $\omega _{speed}$ is the undeployed operator connecting to the output stream of data source in $path_{1}$, the Algorithm 1 preferentially makes placement decision on $\omega _{speed}$. Then, only the edge nodes $v_{1}$ and $v_{2}$ have capacity to host $\omega _{speed}$. The algorithm first assumes that $\omega _{speed}$ is deployed on $v_{1}$ and $v_{2}$, calculates the response time of these two placements, and selects the placement with the minimum response time. Thus, $\omega _{speed}$ is deployed on the edge node $v_{1}$.

If all edge nodes within H hops have no resources, return $\emptyset$ (line 20). The hops number of candidate edge nodes should be increased (line 21). the algorithm is then restarted based on the new monitored information (line 22).

When the algorithm gets $\omega _{tar}$ and $v_{tar}$, the request is sent to the edge node $v_{tar}$ for hosting the operator $\omega _{tar}$. If $v_{tar}$ accepts the request, system deploys the operator $\omega _{tar}$ on the edge node $v_{tar}$ (line 24). Otherwise, the algorithm deletes the edge node and finds $v_{tar}$ again.

The manage edge node monitors information every $\varDelta _{t}$ second. If the response time of an operator graph exceeds the thread $\theta _{t}$, the manage edge node redeploys operators to improve the response time of the operator graphs. To avoid fluctuation in the edge network transmission or the input rate of the operator graphs, this replacement judgement is performed every $\varDelta _{t}$ second.

4.2 Time Complexity

Algorithm 1 makes placement decision for every operator. The number of operators is $|\varOmega |$. For every operator graph, Algorithm 1 calculates its response time. The number of operator graphs is $N_{cep}$. The length of an path $p_{i}$ is $n_{p_{i}}$. The time complexity of calculating the response time for an operator graph is O($\sum ^{N_{p}}_{i=1}n_{p_{i}}$. The largest number of operators in an operator graph is $|G_{cep}|$. The worst case time complexity of calculating the response time for an operator graph is O($|G_{cep}|^{2}$). The time complexity of finding the edge node with minimum delay is O($|V_{edge}|$). Thus, the time complexity of Algorithm 1 is O($|\varOmega |\times |G_{cep}|^2 \times N_{cep}+|\varOmega |\times |V_{edge}|$).

5 Evaluation

We conduct simulations by using Omnet++ [17] that is a network simulation tool widely used in the field of the discrete event simulation, e.g. the simulation of MCEP [9]. There is no widely accepted real data set for CEP currently. By using Omnet++, we change the input rate of the CEP services to evaluate the performance of our algorithm in different workloads. We discuss the results of the simulations in this section.

5.1 Reference Algorithms

As a reference for the results achieved by response time aware operator placement algorithm, we compare our algorithm with two baseline algorithms: greedy algorithm and load balance algorithm. Because both the load balance algorithm and the greedy algorithm do not consider the application structure, we formulate the following rule for both algorithms: the order of placing operators is determined by the shortest logical distance from the data source.

Greedy Algorithm. Greedy algorithm [14] deploys operators on the edge node closest to the input streams of the operators except the edge nodes which do not have sufficient resources.

Load Balance Algorithm. Load balance algorithm [6] calculates the average response time of every edge node, and then reduces the load of the overloaded edge nodes by redirecting some of the operators to the underloaded edge nodes.

5.2 Simulation Environment

We randomly generate 30 different topologies of edge networks and 100 operator graphs to evaluate the response time aware operator placement algorithm. We run two sets of simulation. In the first set of simulations, we run our algorithm and two baseline algorithms in the different edge networks where the same operator graphs are deployed. The initial capacity of edge nodes are 3, 4, and 5 resource units, respectively. In the second set of simulations, we run the algorithms in a network where different operator graphs are deployed. The network is the one whose simulation result is the most similar to the average result in the first set simulation. In this network, the resources capacity of the edge nodes is 5 resource units. We report the average results of these simulations.

We set $\theta _{t}$ = 1 s and $\varDelta _{t}$ = 20 s. Every 20 s, if the response time of the operator graphs exceeds 1 s, the manage edge node redeploys operators to achieve lower response time.

Edge Networks. Considering the goal of this paper and the core of our proposed algorithms, i.e., deploying operators on the nearby edge nodes to keep the response time low, relatively small sized edge networks are sufficient for our evaluation. Specially, we set up three different kinds of 10-node edge networks. The first kind is a ring; the second kind is generated randomly with 15 links; and the third kind is generated randomly with 20 links. We repeat 10 times simulations on each network. In each simulation, we randomly choose a node in the edge network as the manage edge node. The transmission rate is generated randomly between 10 Mbps and 20 Mbps. The manage edge node initially monitors nearby edge nodes within 2 hops.

CEP Operator Graphs. To simulate different structures of operator graphs, 100 operator graphs are generated randomly, 10 of which contains 3 operators, 30 of which contains 4 operators, and 60 of which contains 5 operators. In each simulation, only one kind of operator graphs is sent to the manage edge node and the number of operator graphs is 3. For each operator, 25$\%$ of events conform to user-defined complex events sent to output streams. The resources capacity required for an operator execution is one-resource units. We gradually increase the input rate of the operator graphs to simulate a system from idle to busy.

5.3 Simulation Results

As Fig. 3(a), (b), and (c) shows, in the first set of simulation, our algorithm performs the best among the three algorithms. On average, our algorithm can reduce the total response time by 76$\%$ compared to the greedy algorithm and by 82$\%$ compared to the load balance algorithm. Because of the extra monitored information about the edge network, our algorithm adapts well to different networks.

Fig. 3.

Place the same operator graphs on the different edge networks.

Fig. 4.

Place different operator graphs on the same network.

When the capacity of edge nodes is limited, load balance algorithm performs the worst (Fig. 3(a), (b)). In this case, congestion is inevitable. Load balances algorithm redirects operators to other edge nodes, which makes data have to be delivered to the operators distributed in the congested edge nodes. The extra network traffic aggravates the congestion. In contrast, our algorithm predicts the delay to the edge nodes, and deploys operators on the edge node with the lowest delay to keep the low response time. When the capacity of the edge nodes becomes sufficient, greedy algorithm performs the worst. Because the average load of edge nodes can be reduced by more resources, the load balance performs much better in this situation. Greedy algorithm makes operators gathered around the data source to reduce transmission delay. However, when the input rate increases, the congestion occurs due to large amounts of data are sent to the same edge node. Our algorithm avoids this by predicting the delay to different edge nodes and deploying operators on the edge node with low delay.

As Fig. 4(a), (b), and (c) shows, in the second set of simulation, our algorithm performs the best among the three algorithms. On average, our algorithm can reduce the response time by 33$\%$ compared to greedy algorithm and by 45$\%$ compared to load balance algorithm. We find that congestion is more likely to happen if the operator graph has more paths, because more events from different input streams are sent to an operator.

When the number of operators increases, the response time becomes higher because there are more transmission between operators. The performance of load balance algorithm becomes the worst in Fig. 4(c), because the algorithm distributes more operators than before to balance the load of edge nodes, which increases the transmission delay.

In Fig. 4(c), when the event input rate is low, our algorithm performs better than the other two algorithms. When the input rate increases, our algorithm performs worse than greedy algorithm, because the input rate increases faster than the prediction of our algorithm. However, In Fig. 4(b) and (c), when response time exceeds thread $\theta _{t}$, the manage edge node updates the information about the edge network and the CEP services (including the input rate), and then redeploys the operator graphs resulting in the response time decreasing. These results show that our algorithm can adapt to the dynamic environment, improve the operator placement, and reduce the response time of CEP services.

Besides the response time, we also use bandwidth-delay to measure network usage as an additional criterion. The lower bandwidth-delay product indicates that the network load is lower [11]. Figure 5 shows the total network usage after running the three algorithms. With operator number increasing in an operator graph, due to the network transmission between different operators increases, the network usage increases. Our algorithm performs the best because the algorithm gives priority to the operator graphs with large input rate. Load balance algorithm performs the worst because the algorithm distributes the operators in the edge network resulting in more network transmission.

Fig. 5.

Network usage versus different operator number.

5.4 Threats to Validity

Construct Validity. In the simulations, we observe that our algorithm can reduce the response time of the operator graphs deployed on the edge networks. Because the problem is NP-hard, we cannot get the optimal solution in polynomial time. Our algorithm greedily deploys the selected operators on the edge node with the minimum delay, which is an approximate solution. We can reduce threats to construct validity by searching more edge nodes instead of only the edge node with the minimum delay.

External Validity. The threats to external validity come from our simulation environment. Although we gradually increase the input rate of operator graphs, dynamic network environment cannot be fully simulated.

6 Conclusions

We study response time aware operator placement for CEP in edge computing to reduce the average response time of operator graphs. Since the optimal operator placement problem is NP-hard, we present an approximation-based algorithm to ensure the response time of operator graphs low. The evaluation results show that our algorithm outperforms other approaches in the average response time of operator graphs. We plan to improve our algorithm by searching more placements and use real-world data in the experiments on actual systems in the future.