Performance prediction for supporting mobile

J Supercomput https://doi.org/10.1007/s11227-018-2414-6

Performance prediction for supporting mobile applications’ offloading Thiago Felipe da Silva Pinheiro1 · Francisco Airton Silva1 · Iure Fé1 · Sokol Kosta2 · Paulo Maciel1

© Springer Science+Business Media, LLC, part of Springer Nature 2018

Abstract Mobile cloud computing (MCC) is a technique for increasing the performance of mobile apps and reducing their energy consumption through code and data offloading. Developers may build MCC applications on a public cloud. The public cloud may offer economies of scale, but there are some considerations to take into account. Cloud providers charge their customers by data traffic, and wrong offloading decisions may lead to financial losses. This paper proposes an approach for estimating applications’ performance, data traffic generated by tasks offloading and its related costs on a public cloud. This work proposes both a stochastic Petri net (SPN)-based formal framework to represent MCC applications in a method-call level and a cost model to predict data traffic volume. Our approach enables designers to plan and tune MCC architectures based on three performance metrics: mean time to execute, cumulative distribution function, and throughput. Our SPN-based framework represents the use and sharing of the bandwidth available for offloading operations as well as the effect of bandwidth variation on the evaluated metrics. It allows a more accurate evaluation by developers about the performance of their applications taking into account specific network requirements, users, and offloading strategies. Two case studies were performed. Our approach has proven to be feasible, and it highlights the most appropriate strategies, supporting developers at design time by providing statistical information about applications’ behavior and costs estimations.

B

Thiago Felipe da Silva Pinheiro [email protected]; [email protected]

1

Informatics Center, Federal University of Pernambuco, Road Jorn. Aníbal Fernandes - Cidade Universitária, Recife 50740-560, PE, Brazil

2

Center for Communication, Media and Information Technologies, Aalborg University, Copenhagen, Denmark

123

T. F. da Silva Pinheiro et al.

Keywords Mobile cloud · Performance evaluation · Data traffic evaluation · Stochastic Petri nets · CTMC

1 Introduction Mobile cloud computing (MCC) is a paradigm that increases the performance of mobile applications and reduces their energy consumption through offloading technique [29,32]. The offloading process sends tasks to be processed on remote servers in the cloud. The first step in performing task offloading is to split an application into different parts. Next, there is a decision of which ones are most convenient for remote processing. Tasks may be partially or completely offloaded, depending on the application requirements. Offloading to public clouds does not come for free. Cloud service providers charge their clients for resource usage. A wrong offloading decision may lead a company to financial losses. The higher the resource usage, the higher the amount to be paid to the provider. Method-call offloading is a partitioning strategy that enables to split a code into multiple parts. Deciding which method to partition is not an easy task. It is necessary to analyze many possible scenarios. This paper proposes an approach for estimating the performance of MCC applications, the data traffic volume generated by tasks offloading to public clouds and its resulting costs.1 For that aim, we defined twofold steps. We propose a stochastic Petri net (SPN)-based modeling strategy to represent the structure of the application’s source code in a method-call level. We propose a mobile cloud cost model to predict data traffic volume and its costs applying SPNs. Next, the proposed models are used to estimate three performance metrics of the whole application: the mean time to execute (MTTE), cumulative distribution function (CDF), and throughput. The MTTE corresponds to the execution time of the application as a whole. The CDF indicates the maximum probability that the application’s processing will finish in a specific time interval. The throughput corresponds to the number of requests per time unit made by each user. Our SPN-based framework represents the use and sharing of the network bandwidth (BW) available for offloading operations as well as the effect of bandwidth variation on the three performance metrics. Our work is the first one, to the best of our knowledge, that provides an automatic model generation for performance and costs evaluations, which may assist software engineers to evaluate their applications at design time. The remainder of the paper is organized as follows. Section 2 highlights the main concepts about Method-Call Offloading and SPNs; Sect. 3 shows related work; Sect. 4 presents the proposed strategy; Sect. 5 details case studies to support the proposal; and finally, Sect. 6 traces conclusions, stressing future directions.

1 The term “costs” corresponds to financial costs when used in an isolated way.

123

Performance prediction for supporting mobile applications’… Fig. 1 Partial method-call offloading

Mobile Side m1() m2()

Table 1 Possible offloading scenarios

Cloud Side m1() m2()

Possibility

m1()

m2()

Scenario #1

Mobile

Mobile

Scenario #2

Mobile

Cloud

Scenario #3

Cloud

Mobile

Scenario #4

Cloud

Cloud

2 Background This section presents some concepts about method-call offloading and stochastic Petri nets to support the understanding of the proposed approach. 2.1 Method-call offloading An application may offload method-calls without restrictions to the cloud. The abovementioned scenario is called full method-call offloading [6,32,34]. An alternative to the full method-call offloading is the partial method-call offloading. In a method-call partitioning strategy, the source code is partitioned at method level [6,15,28,30,32, 34,50,55,56,61]. Instead of all methods, only a subset of them is offloaded. Data dependencies must be observed to perform a correct partition. If some parts of an application can be executed in parallel, then these tasks may be offloaded to more than one server concurrently. For example, considering the methods m1() and m2(), two decisions should be made (as illustrated in Fig. 1): Where to execute m1() and m2()? Combining these possibilities (mobile device or the cloud), four scenarios may be exploited (see Table 1). The number of possibilities increases proportionally to the application complexity. In a real-world scenario, the number of combinations of method-calls to offloading may be very large. Such variety makes harder the software engineer’s work when deciding the most appropriate offloading distribution. The developer would expect that partitioning and distributing a set of method-calls on multiple servers would reduce its total execution time. However, one method-call may present a low level of processing, not justifying the offloading process. Besides, other aspects, such as the mobile device current CPU and energy consumption level, may influence the decision. 2.2 Stochastic Petri nets Carl Adams Petri formalized the initial conceptions of Petri nets (PNs) in his Ph.D. thesis presented at the Technical University of Darmstadt, Germany [51]. Petri nets

123


are a powerful modeling tool that can be used to represent concurrent, asynchronous, distributed, parallel, deterministic, and stochastic processes. PNs define a specification technique that allows a mathematical and graphical representation, and it has analytical mechanisms that enable verification on the properties and correctness of modeled systems. As a graphical tool, PNs may be utilized as a visual representation mechanism, aiding in process modeling and analysis. Since Carl Petri’s work, many representations and extensions have been proposed providing more concise descriptions and describing systems features not observed in previous models [40]. Stochastic Petri nets (SPNs) are an extension of Petri nets. SPNs associate a stochastic delay to each timed transition. Thus, PNs become probabilistic, being described by a stochastic process. SPNs may be isomorphic for continuous-time Markov chains (CTMCs), and consequently, they can provide performance measures [22]. In this case, each reachable marking in an SPN model is equivalent to one state in a CTMC. Therefore, SPNs may be converted to CTMCs, which means that SPNs may be resolved to reach the desired performance or reliability results [36,37,39,66]. If non-polyexponential distributions [7,16] are adopted, the SPN can only be evaluated through simulation.

3 Related work The first papers in MCC had the objective of optimizing the offloading process itself. They focused on improving the offloading techniques by monitoring the mobile device, the application, and the network conditions. Many offloading frameworks have tackled mobile device constraints by offloading as much as possible heavy tasks obeying context factors [5,9,11,13,15,28,30,31,53,64]. The number of works addressing context-aware offloading optimization is very large. Once the benefits of these frameworks became widely acknowledged by the research community, a new research trend appeared: MCC infrastructure planning [10,21,44,48,49]. The scope of this field is to obtain an intelligent use of limited cloud resources by applying sophisticated system evaluation techniques. Formal methods have been applied in diverse computer areas by evaluating system performance and assisting software engineers with architecture planning. Most of them have dedicated to evolve what it is called software performance engineering (SPE) [25]. SPE is a systematic, quantitative approach to constructing software systems that meet performance requirements, classified as real-time or responsive systems. SPE uses model predictions to evaluate trade-offs in software functions, hardware size, quality of results, and resource requirements. MCC has presented the need for applying SPE methods requiring to reach higher quality levels. For this reason, the current work focuses on MCC infrastructure planning applying SPE methods. As observed in [62], the main metrics used to evaluate the MCC using stochastic models are reliability, availability, energy, and execution time. Reliability is defined as the probability that a device will perform its intended functions satisfactorily for a specified period of time under specified operating conditions [4]. Since the performance of a system usually depends on the performance of its components, the reliability of the whole system is a function of the reliability of its components [33].

123

Performance prediction for supporting mobile applications’…

Availability is defined as the probability that the system is operating properly at any given time [44]. Availability is the vital metric for nowadays systems; near 100% availability is becoming mandatory for both users and service providers. High availability is an important feature for MCC applications given that the cloud dependency can introduce unexpected failures [44]. Execution time and energy are the most utilized metrics when evaluating the MCC systems. Computing speeds of mobile devices do not increase at the same rate as servers’ performance [42]. It is due to several constraints, including: Form Factoras users want devices that are smaller and thinner and yet with more computational capability; Power consumption-insofar the current battery technology constrains the clock speed of processors. As the clock speed is increased, the power consumption is increased too. As a result, it is difficult to offer long battery lifetimes with high clock speeds [42]. Therefore, energy and execution time will continue to be a MCC concern in long term. Although reliability, availability, and energy are very important metrics, our work focuses on execution time. For some computational tasks, it is possible to save battery when we reduce the processing time. Gabner et al. [21] investigates service component migration between the mobile client and the infrastructure-based cloud to avoid service failures and improve service performance. Shumao et al. [47] evaluate failure and execution recovery time of mobile applications using a semi-Markov chain model. The analysis results indicate, for example, that in the higher surrogate coverage areas, offloading systems can speed up the application execution time. Silva et al. [63] propose an SPN-based modeling strategy to represent method-call executions of mobile cloud systems. The approach enables a designer to plan and optimize MCC environments in which SPNs represent the system behavior and estimate the execution time of parallelizable applications. However, neither the network aspects nor data traffic generated by MCC application were considered. Monetary cost evaluation based on stochastic models may support companies in planning their applications on the public cloud. A very few papers have proposed strategies based on stochastic models in order to support the cost evaluation of resource consumption on public clouds. More specifically, these works addressed the monetary cost of using virtual machines that are called instances. Ribas et al. [54] proposed a colored Petri net-based model that represents the use of spot instances in order to save costs. Authors identified that spot instances could help reduce cost when compared to on-demand and reserved instances in an auto-scaling process. Andrzejak et al. [2] propose a probabilistic model for the cost/QoS optimization in the context of spot instances in the Amazon Elastic Compute Cloud (EC2). Authors present an approach that allows users to identify the most appropriate time to optimally bid on spot instances and acquire them. Different from our work, these studies do not offer models considering data traffic generated by offloading tasks in public clouds and its related costs; nor does it adopt MCC application partitioning strategies. Although many studies focus on the optimization of the offloading process, in the recent literature, few studies have addressed stochastic performance modeling in the context of MCC infrastructure planning. In addition, the trade-off between performance and data traffic—and its related costs—for offloading on public clouds

123


has been ignored by these studies. Unlike these works, we offer a strategy in order to support the performance and data traffic cost evaluations at design time. However, it may be adapted and used in conjunction with a context-aware offloading optimization approach to providing on-the-fly performance evaluations. This work proposes an SPN-based modeling framework in which the source code is represented and evaluated in a method-call level. Representing the source code enables the software engineer to access a more accurate result. Our framework considers the use and sharing of the available bandwidth for offloading operations and the impact of its variation on the evaluated metrics.

4 Estimating performance, data traffic and costs in MCC offloading Companies in some situations need to balance system performance, resource consumptions, and financial costs to find the most appropriate strategy that meets the requirements of their projects. As the user base of an offloadable application grows, the higher may be the consumption of some remote resources. The amount of money that a company must pay to an IaaS cloud provider may grow significantly. Awareness of the related cost is a major element in the choice of appropriate strategies. Application’s performance and data traffic are key elements in defining an offloading strategy. Most public cloud providers (Amazon,2 Google,3 Microsoft4 ) charge their customers for data traffic. More specifically, the outbound data traffic to the Internet. The proposed approach for estimating data traffic evaluates from mobile users’ perspective. This work does not evaluate the response capacity of remote infrastructures, and it takes into account that the MCC infrastructure may support all requests generated by the users. More precisely, this paper seeks to answer the following questions: 1. How to calculate the MTTE, CDF, and throughput of a set of method-calls—that may represent a system functionality—using SPNs? 2. How to estimate the impact of the available bandwidth and its variation on the throughput, MTTE, and CDF? 3. How to estimate the data volume that will be transferred during the offloading process of a set of method-calls for a given period of time over a public cloud? 4. How to estimate the monetary cost of transferring a data volume over a public cloud? 4.1 Networking aspects Network performance is a key factor that has a direct impact on the performance of the entire MCC application. However, it is a difficult task to estimate precisely at design time the network conditions in which applications will be used. As we have 2 AWS: https://aws.amazon.com. 3 Google Cloud Platform: https://cloud.google.com. 4 Azure: https://azure.microsoft.com.

123


already mentioned, our strategy is not a context-aware offloading approach. It aims to support developers at design time. Thus, aspects related to context-aware approaches as network congestion are not addressed in our framework. Our work considers the actual TCP throughput between the device and cloud for tasks offloading. Our framework considers the effect of network bandwidth on the applications’ performance. An application may have many users, and the users’ network has different conditions from each other. Therefore, developers may establish network requirements for their applications in which the expected and minimum bandwidths are defined. In addition, when planning their MCC applications, developers should consider that the expected bandwidth allocated for their applications may vary within a specified limit. For example, if the application detects that the available bandwidth is less than the lower-limit set value, then the processing is performed locally. Considering the actual TCP throughput and the number of bytes to be transferred, it is possible to estimate the time for data transfer using Eq. 1. Varying the available bandwidth within the defined limits, it is possible to take a myriad of evaluations for supporting both the offloading decision process and MCC infrastructure planning. CT =

datasi ze BW

(1)

Our solution may be adapted considering strategies proposed by other authors. When adapting our strategy to work in a real-time context, developers may implement an approach to estimate the actual bandwidth available during the application execution. For example, based on the actual available bandwidth estimated and the performance prediction performed using the strategy proposed in this work, mobile apps may decide how the processing will be executed. In this context, there are many works with the aim of evaluating MCC offloading traffic considering the networking aspect and resulting network-induced constraints [5,9,11,13]. Cordeschi et al. [11,13] use an optimization scheme to solve the well-known resource management problem. Authors proposed a reliable adaptive resource management controller for vehicular access networks in order to provide reliability guarantees to traffic considering the inherent mobility and fading induced changes. The author’s strategy scales energy and bandwidth consumptions with the dynamic demands where performance are enhanced through data traffic offloading to the local or remote cloud. Chang et al. [9] proposed a schema based on the queuing theory to support the offloading process considering energy consumption and execution delay in a fog system. The scheme aims to optimize both the probability of offloading as well as the transmission power in order to minimize energy consumption. 4.2 Execution time (MTTE and CDF) MTTE corresponds to the average time to finalize the processing of a set of methodcalls. Figures 2 and 3 present an example of SPNs for computing MTTE. MTTE is the expected time to reach an absorbing state. A state of an SPN is absorbing whether it is impossible to leave it (i.e., P(#FINISH = 1)). It means a deadlock marking has been reached. MTTE is based on the probability that the processing of a system functionality

123


has been completed. MTTE is the average time for a number of tokens to reach the place FINISH given they were in place START at time instant zero. SPN models can be evaluated either by numerical methods or by simulation [41]. Figures 2 and 3 demonstrate a simple representation using SPN of one functionality with only one method-call. Let us first look at the SPN representation that corresponds to the local method-call (see Fig. 2). The SPN model comprises three places and two transitions. The first transition (trigger_time) is immediate. It means that the transition has zero as its delay value. The second transition (processing_time) is a General Time High-level Transition. It represents the time to processing the respective method-call. The SPN pattern that represents an offloadable method-call has two new places and two new transitions (see Fig. 3). Transition offloading_time represents the time spent to execute offloading. Transition receiving_time represents the time spent to receive the result sent by the cloud. These transitions are depicted by a gray rectangle, and the model is later refined by assigning probabilistic distribution parameter values to respective transitions. If, on the one hand, such transition is refined by poly-exponential distributions [16,17,58], the SPN can be evaluated either by numerical analysis or by simulation. On the other hand, simulation should be carried out. The models were evolved by transformation of high-level transitions into exponentially distributed timed transitions. It allows assigning average delays to respective timed transitions. Such transformation of transitions and delays assignments allow the SPN models to be solved. From here, for simplicity, all timed transitions will have exponential enabling times. However, they may adopt other probabilistic distributions as well as deterministic values. Moment matching [17] could also be applied to obtain poly-exponential distributions [3,14,58]. By adopting moment matching, the planner may estimate what exponential based probability distribution best fits the mean. Additionally, moment matching generates more accurate models, which can still be numerically evaluated. If none poly-exponential distributions are adopted, simulations should also be adopted. Such SPN patterns may originate other models to evidence data dependency between method-calls of any source code arrangement. The SPN modeling pattern has evolved to calculate MTTE of distinct scenarios. Algorithms 1, 2, and 3 demonstrate three types of method-call combinations. Figure 4b, d, f demonstrates how the original SPN model evolved to calculate MTTE of the three types of method-call combinations. The pattern embraces general features common in concurrent systems. The place SYSTEM_INACTIVE when having one token means that the system is idle. The timed transition T0 receives the delay to start the processing of method-calls when there is a token in the place SYSTEM_INACTIVE. When there is no delay, T0 becomes an immediate transition. In a real-world context, multiple combinations can be derived taking into account the application’s method-calls and the modeling patterns presented in Figures 2 and 3. The mean processing time and communication time of each evaluated method are the base for MTTE calculation. In the models presented, the processing_time_m1 and processing_time_m2 transitions receive the mean processing times of the methods m_call_1 and m_call_2, respectively. If the application’s method under analysis is an offloadable method, it is necessary to obtain the number of bytes transferred to send tasks and to receive the remote results.

123


Algorithm 1 Three Sequential Method-Calls 1: function r oot Method(input1) 2: r esult1 ← per f or mT ask1(input1) 3: r esult2 ← per f or mT ask2(r esult1) 4: r esult3 ← per f or mT ask3(r esult2) 5: return r esult3

m_call_1 m_call_2 m_call_3

Algorithm 2 Two Sequential Method-Calls and One in Parallel. 1: function r oot Method(input1, input2) 2: r esult1 ← per f or mT ask1(input1) 3: r esult2 ← per f or mT ask2(r esult1) 4: r esult3 ← per f or mT ask3(input2) 5: return r esult2, r esult3


Algorithm 3 Three Parallel Method-Calls 1: function r oot Method(input1, input2, input3) 2: r esult1 ← per f or mT ask1(input1) 3: r esult2 ← per f or mT ask2(input2) 4: r esult3 ← per f or mT ask3(input3) 5: return r esult1, r esult2, r esult3


one local method-call trigger_time

START

processing_time

EXECUTING

FINISH

Fig. 2 Basic SPN representation of one application with only one local method-call using absorbing state

one remote method-call trigger_time

START

offloading_time

OFFLOADING

processing_time

EXECUTING

receiving_time

RECEIVING

FINISH

Fig. 3 Basic SPN representation of one application with only one offloadable method-call using absorbing state

In this work, we consider that there is a specific bandwidth allocated to offloading operations, as well as to receive the remote results. More specifically, the developer should consider bandwidth variation for a more accurate estimate (see Sect. 4.1). Equations 2 and 3 consider the probability of there being tokens in the offloading place (variable Om j ) as well as in the receiving place (variable Rm j ) for other method-calls other than mi, respectively. BWo f f loading represents the actual bandwidth allocated for tasks offloading—in bits/s. BWr eceiving represents the actual bandwidth allocated to receive the remote results—in bits/s. Thus, if other methods are using the allocated

123


bandwidth, the bandwidth allocated for the operation (i.e., offloading or receiving) is divided among the methods that are using the network for the same operation. Equations 4 and 5 calculate the communication time to transfer an amount of data taking into account the actual bandwidth allocated to the evaluated method mi. datasi ze_omi represents the amount of data transferred to offload the method mi—in bits. datasi ze_rmi represents the amount of data received as a result of the remote processing of the method-call mi—in bits. Equations 4 and 5 are assigned as the mean delay value of transitions offloading_time_mi and receiving_time_mi of the methodcall mi, respectively. In the evaluation process, developers must convert Eqs. 4 and 5 to the syntax of the stochastic evaluation program used. After that, a transient analysis on the model obtains the MTTE. A tool such as the Mercury, TimeNet, GreatSPN, or SHARPE may execute this analysis [23,24,60,67]. These tools generate the state space of the SPN model and create the corresponding CTMC. Then, the calculations described in the next section are performed to obtain the required metrics. We have adopted SPN as modeling formalism due to its greater descriptive power in relation to Markov chains [37]. Using SPN, it is possible to make a high-level graphical representation of method-calls and their possible synchronizations. However, developers may model their systems using CTMC, but this approach may lead to a model with a large number of states. Thus, depending on the size of the system, it may become impracticable to directly model all method-calls, their synchronizations, and transitions rates using CTMC. BWOmi = BWRmi =

1+ 1+

n

1 P Rm j

j=i

j=i

datasize_omi BWOmi datasize_rmi = BWRmi

offloading_timemi = receiving_timemi

BWo f f loading 1000 BWr eceiving × 1000 >0

n

1 P Om j > 0

×

(2) (3) (4) (5)

4.2.1 Mean time to absorption (MTTA) Time-dependent metrics are obtained through transient evaluation. The measure of interest is the mean time to absorption (MTTA). To calculate the MTTA, the model must have at least one absorbing state. In this work, the absorbing state is reached when the model is in the FINISH state. Figure 5 presents the CTMC that represents the elapsed time to finish the processing for an offloadable method-call. The behavior of the CTMC can be described by the Kolmogorov equation given the initial probability vector π(0) (see Eq. 6). Equation 7 gives the expected total time the CTMC spends in state i during the interval [0, t). The time spent before absorption can be calculated restricted to the states of the set of non-absorbing states

123

Performance prediction for supporting mobile applications’… m_call_1

offloading_time_m1

OFFLOADING_m1 m_call_2

EXECUTING_m1

offloading_time_m2

OFFLOADING_m2

processing_time_m1

RECEIVING_m1

processing_time_m2

EXECUTING_m2

m_call_1

receiving_time_m1

offloading_time_m1


receiving_time_m2

RECEIVING_m2

EXECUTING_m1

offloading_time_m2

OFFLOADING_m2

m_call_3

processing_time_m1

RECEIVING_m1

processing_time_m2

EXECUTING_m2

receiving_time_m1

receiving_time_m2

RECEIVING_m2

m_call_3 offloading_time_m3

OFFLOADING_m3

processing_time_m3

EXECUTING_m3

receiving_time_m3

RECEIVING_m3

offloading_time_m3

FINISH_m3

OFFLOADING_m3

processing_time_m3

EXECUTING_m3

receiving_time_m3

RECEIVING_m3

FINISH_m3

T1

T1 FINISH_ALL

(a) m_call_1

offloading_time_m1


OFFLOADING_m2

processing_time_m1

EXECUTING_m1

offloading_time_m2

(b)

RECEIVING_m1

processing_time_m2

EXECUTING_m2

m_call_1

receiving_time_m1


receiving_time_m2

RECEIVING_m2

offloading_time_m1

FINISH_m2

EXECUTING_m1

offloading_time_m2

OFFLOADING_m2

m_call_3

processing_time_m1

RECEIVING_m1

processing_time_m2

EXECUTING_m2

receiving_time_m1

receiving_time_m2

RECEIVING_m2

FINISH_m2


OFFLOADING_m3

processing_time_m3

EXECUTING_m3

receiving_time_m3

RECEIVING_m3

offloading_time_m3

FINISH_m3

OFFLOADING_m3

processing_time_m3

EXECUTING_m3

receiving_time_m3

RECEIVING_m3

FINISH_m3

T1

T1 FINISH_ALL

(c) m_call_1

offloading_time_m1


OFFLOADING_m2

processing_time_m1

EXECUTING_m1

offloading_time_m2

(d)

RECEIVING_m1

processing_time_m2

EXECUTING_m2

m_call_1

receiving_time_m1

FINISH_m1


receiving_time_m2

RECEIVING_m2

offloading_time_m1

FINISH_m2

EXECUTING_m1

offloading_time_m2

OFFLOADING_m2

m_call_3

processing_time_m1

RECEIVING_m1

processing_time_m2

EXECUTING_m2

receiving_time_m1

FINISH_m1

receiving_time_m2

RECEIVING_m2

FINISH_m2


OFFLOADING_m3

processing_time_m3

EXECUTING_m3

receiving_time_m3

RECEIVING_m3

offloading_time_m3

FINISH_m3

OFFLOADING_m3

processing_time_m3

EXECUTING_m3

receiving_time_m3

RECEIVING_m3

FINISH_m3

T1

(e)

T1

(f)

FINISH_ALL

Fig. 4 SPNs representing offloadable method-calls. a SPN without absorbing state used to calculate throughput of the Application_A (three sequential method-calls). b SPN with absorbing state used to calculate MTTE and CDF of the Application_A (three sequential method-calls). c SPN without absorbing state used to calculate throughput of the Application_B (two sequential method-calls and one in parallel). d SPN with absorbing state used to calculate MTTE and CDF of the Application_B (two sequential method-calls and one in parallel). e SPN without absorbing state used to calculate throughput of the Application_C (three parallel method-calls). f SPN with absorbing state used to calculate MTTE and CDF of the Application_C (three parallel method-calls)

123

T. F. da Silva Pinheiro et al. 1/trigger_time

START

1/offloading_time

OFFLOADING

1/processing_time

EXECUTING

1/receiving_time

RECEIVING

FINISH

Fig. 5 CTMC of one application with only one offloadable method-call with absorbing state

(N ) by limt→∞ L N (t). Thus, L(t) satisfies the Eq. 8 where π N (0) is the vector π(0) restricted to the states in the set N . Q N is the infinitesimal generator matrix restricted to the non-absorbing states. Finally, MTTA may be described as Eq. 9 [7]. dπ(t) = π(t)Q dt t L i (t) = πi (x)dx

(6) (7)

0

L N (∞)Q N = − π N (0)

L i (∞) MTTA =

(8) (9)

i∈N

4.2.2 Cumulative distribution functions (CDFs) Application developers and service providers willing to plan and design an MCC environment should be aware at when their applications are more likely to finish execution. Cumulative distribution functions (CDFs) may indicate such a moment through the maximum probability of absorption. CDFs are associated with a specific probability distribution. In this work, the probability distribution is related to the probability of finishing the application execution within a specified time. It is obtained through transient evaluation generating probabilities with time tending to one value t. In other words, developers compute the probability to absorption in [0, t), through transient evaluation, where F(t) approaches 1. CDFs may also indicate the maximum probability of an application’s processing to be completed within a given time interval. Regarding CDFs, nonnegative random variables may have the probability distributions defined in terms of its probability density function (see Eq. 10).

t

F(t) =

f (x)dx

(10)

0

CDFs allow a broader cost-effective architectural simulation of mobile cloud applications. Analyzing the hypothetical example of CDF line plot in Fig. 6, two types of interpretation may be traced: – Probability of finishing execution before time t: Considering one specific execution time point t, the graph returns the probability P(T < t) of finishing the execution before such time for each application. The probability of finishing the execution

123

Performance prediction for supporting mobile applications’… 0

50

100

150

200

250

300

350

P(T < t)

1

1

0.8

0.8

0.6

0.6

0.4

0.4

Application A Application B Application C

0.2

0.2

0

0 0

50

100

150

200

250

300

350

Execution Time (ms) Fig. 6 Example of CDF based on SPN

before 150 ms is equal to 66% for Application A, 95% for Application B, and 98% for Application C. – Probability interval: The developer may obtain the probability of finishing the execution between a time interval (t1 , t2 ), which is calculated as P(t1 < T < t2 ) = P(T < t2 ) − P(T ≤ t1 ). Thus, we can calculate the probability of finishing the execution between 20 and 80 ms resulting in 9.2% for Application A, 47% for Application B and 65% for Application C. As expected, Application C has higher probability of satisfying the constraint. If we relax the timing constraints and increase the time interval between 100 and 200 ms, the probability of finishing the execution with Application A becomes higher. Specifically, for each application we obtain the following values: 68% for Application A, 29% for Application B, and 16% for Application C.

4.3 Throughput The throughput (T p) represents the number of executions per unit of time of a set of method-calls. T p is obtained by computing the expected value of tokens at a place, multiplied by the inverse of the transition delay [35]. For that aim, the SPN model presented in Figs. 2 and 3 evolved. Now, as illustrated in Fig. 7a, b, the models need two transitions to allow them to return to the initial state when workload execution is complete. Such SPN pattern may be extended to evidence the method-calls data dependency of any application (see Fig. 4a, c, e). The throughput may be calculated considering two possibilities: single semantics server (SSS) and infinite server semantics (ISS). In the SSS, the flow of tokens will

123

T. F. da Silva Pinheiro et al. trigger_time_2

T0

INACTIVE one local method-call processing_time trigger_time_1

START

EXECUTING

FINISH

(a) trigger_time_2

T0

INACTIVE trigger_time_1

START

one remote method-call processing_time offloading_time

OFFLOADING

EXECUTING

receiving_time

RECEIVING

FINISH

(b) Fig. 7 SPN representation of an application with only one method-call without absorbing state. a SPN without absorbing state used to calculate throughput of an application with one local method-call. b SPN without absorbing state used to calculate throughput of an application with one offloadable method-call

occur in series, regardless of the degree of the transition activation. In the ISS, every set of tokens of the enabled transition is processed simultaneously. Equation 11 calculates the throughput according to the SSS strategy and Eq. 12 for ISS. The variable i represents the weight of the arc that connects the place INACTIVE and the subsequent transition T0. The variable i may vary until N , where N is the highest enabling degree of the subsequent transition at the place marking m(I N AC T I V E) = i. The throughput is defined by the delay between each request (transition T0) as well as the delays assigned for others transitions in the SPN model. The available bandwidth and the number of bytes to be transferred represent the transfer time. Thus, if there is a change in the actual bandwidth, there may be a change in the throughput. If the delay between requests is small (T0), the impact on the throughput may be high. On the other hand, if the delay between requests is high, the impact on the throughput may be small. 1 T p = P(m(I N AC T I V E) >= i) × Time N

Tp = P(m(I N AC T I V E) = i) × i × i=1

123

(11) 1 Time

(12)

Performance prediction for supporting mobile applications’… Table 2 Amazon EC2 prices per transferred bytes [1]

Data transfer OUT to internet

Table 3 Oracle cloud prices per transferred bytes [46]

Price/GB

First 10 TB/month

$0.09

Next 40 TB/month

$0.085

Next 100 TB/month

$0.07

Next 350 TB/month

$0.05

Data transfer OUT to internet

Price/GB

First GB/month

Free

Next 9.999 TB/month

$0.12

Next 40 TB/month

$0.09

Next 100 TB/month

$0.07

Next 350 TB/month

$0.05

Table 4 Microsoft Azure prices per transferred bytes [38] Data transfer OUT to internet

Zone 1 Price/GB

Zone 2 Price/GB

Zone 3 Price/GB

DE (trustee) Price/GB

First 5 GB/month

Free

Free

Free

Free

5 GB–10 TB/month

$0.087

$0.138

$0.181

$0.100

Next 40 TB/month

$0.083

$0.135

$0.175

$0.095

Next 100 TB/month

$0.070

$0.130

$0.170

$0.080

Next 350 TB/month

$0.050

$0.120

$0.160

$0.057

4.4 Costs for data transfer Public clouds charge their customers for data transfers by considering “utilization ranges” as illustrated in Tables 2, 3 and 4—corresponding to Amazon, Azure, and Oracle price tables,5 respectively. The price charged per gigabyte transferred decreases as the volume increases over a period. More specifically, the providers mentioned above charge their customers for outgoing data traffic to the Internet. Therefore, developers should only consider the bytes transferred from the remote MCC infrastructure to mobile devices. Using Eq. 13, it is possible to obtain the total transferred bytes (TTB) for each evaluated offloading scenario. To obtain, the TTB is necessary multiplying: (i) the throughput(Tp); (ii) the evaluation period in milliseconds (Time); (iii) the volume of data transferred in each request (Bytes); and finally (iv) the number of users (Users). TTB = T p × Time × Bytes × Users

(13)

5 The practiced values by the IaaS cloud providers may change over time.

123


Now, using Eq. 14 it is possible to obtain the financial cost. First, it is necessary to split the number of total bytes according to the utilization range of the price table used. After that, it is necessary multiplying the number of bytes consumed in each “utilization range” by its respective price. Companies may adjust the cost calculation according to the data traffic charges policy of their IaaS cloud provider. Cost =

n

TransferredGBsur × PricePerGBur

(14)

ur =1

4.5 MCC-Adviser: an evaluation assistant A previous work [61] presented a tool called MCC-Adviser. MCC-Adviser assists companies in their offloading decisions and mobile cloud infrastructures planning. It is a tool implemented using the concepts exploited in this work, and it supports mobile application performance evaluation and resource consumption estimation. Evaluations and estimates are based on stochastic models. MCC-Adviser core is a web-based application. In addition to main module, MCC-Adviser is composed by other modules. Each module has a important function in the entire evaluation process offers by the tool. MCC-Adviser used a full method-call offloading approach [61]. However, developers may need to use an approach that allows distributing only some parts of their applications for remote processing. Thus, MCC-Adviser has evolved to support partial method-call offloading evaluations. The previous version of MCC-Adviser has enabled the use of only one execution time log with only one offloading configuration. Now, developers may inform a set of offloading configurations and obtain the desired metrics for each scenario (see Fig. 8). The performance metrics of interest supported by the tool are as follows: the MTTE, CDF, and throughput. MCC-Adviser may estimate the data traffic volume generated by each offloading configuration. In this way, it may calculate how much a company will pay for adopting an offloading strategy on a public cloud. It provides support for developers to balance expected performance and financial costs in their decisions. MCC-Advisers also consider the applications’ network requirements. More specifFig. 8 MTTE for supporting offloading planning

log-exec-time-01.txt

MCC-Adviser



123

MTTE


#1 #2 #3 #4 Scenarios


ically, it considers the bandwidth expected by the mobile application as well as its expected variation over time. Network conditions may vary over time. Thus, MCCAdviser indicates the impacts of the actual bandwidth variation on the metrics of interests. Furthermore, MCC-Advisers generate statistical graphs based on the evaluations performed. Developers may evaluate the behavior of distinct offloading strategies only by looking at the graphs. The tool supports decisions about the best strategy to be applied in the versions of the software that are released to the target audience. MCCAdviser automated the steps described in this paper. For this purpose, MCC-Adviser requires: – – – – –

the application’s source code, the execution time of the evaluated methods, the delay between each user request, the number of app’s users, the analysis period (whether it is necessary to estimate the resource consumptions and costs), – the number of transferred bytes in the offloading process, and, finally, – the expected bandwidth and its variations within certain limits. Figure 9 illustrates an overview about how MCC-Adviser works. Algorithm 4 demonstrates a pseudocode about the overall behavior of the tool. Algorithm 4 Performance Evaluation on MCC-Adviser—How it works 1: MCC-Adviser captures the annotated source code uploaded 2: by the developer. 3: MCC-Adviser adds method-calls to capture execution time and 4: data based on annotations. 5: MCC-Adviser sends the modified source code to the developer. 6: 7: Developer builds his application with the modified source code. 8: Developer installs the application on mobile devices and on 9: the server for performance evaluation. 10: Developer performs some experiments. 11: Developer captures the log files that contain the collected 12: metrics (i.e., execution time and bytes). 13: 14: MCC-Adviser captures the input parameters, source code, and 15: logs provided by developer. 16: MCC-Adviser creates SPN models that represent the evaluated 17: application. 18: MCC-Adviser assigns parameters to the SPN models. 19: MCC-Adviser performs performance and costs evaluations. 20: MCC-Adviser plots graphs based on evaluation result.

phase 1 phase 1 phase 1 phase 2 phase 2 phase 2 phase 2 phase 3 phase 3 phase 3 phase 3 phase 3

4.5.1 Collecting input parameters Aiming to refine and evaluated SPN models, input parameters are necessary. Figure 10 presents an overview of the Collecting Input Parameters phase. The parameters of

123


COLLECT INPUT PARAMETERS Source Code

Execution Time

Transferred Bytes

public void rootMethod(){ m1(); m2(); m3(); }

m1(): 843 ms m2(): 310 ms m3(): 124 ms

m1(): 129 Bytes m2(): 426 Bytes m3(): 243 Bytes

Rate for Each User

Number of Users

Analysis Period

1 / 30,000 ms exponential

30,000

1 day = 86400000 ms

Expected Bandwidth 3.0 Megabits

GENERATE, REFINE AND SOLVING SPNs

PLOTTING RESULTS

Probability

MTTE #1

#2

#3

Fig. 9 MCC-Adviser overview

123

Throughput Throughput

CDF

Time

Costs Costs for Offloading

MTTE

#1

#2

#3

#1

#2

#3


interest are two: execution time and the amount of data transferred per method-call. As far as the MCC-Adviser plays the role of an adviser, it is expected that the developer executes as minimal as possible tasks to get the estimated statistics. Two additional modules were developed to assist him with such tasks: MCC-Instrumenter and MCCLogger. Figure 10 illustrates that , in step 1, the MCC-Instrumenter receives the source code (rootMethod()) as input. Then, the tool instruments the code to enable data capture necessary for performance evaluation. In practice, the developer uploads an entire Java class indicating which method must be instrumented. A specific annotation is used for MCC-Instrumenter to identify the parts of the code to be instrumented. After that, MCC-Instrumenter updates the code by adding directives before and after each annotated method-call. MCC-Instrumenter is supported by the library BCEL.6 The process of collecting the desired metrics must be performed at both sides (i.e., mobile device and the cloud). MCC-Logger is a Java package that offers methods to collect and register the desired metrics. MCC-Logger decides at runtime whether the method-call may be offloaded or not. This process is based on annotations inserted in the source code. MCC-Logger generates logs addressing the following metrics: the amount of bytes transferred per method-call, execution and communication time per method-call and total execution time. The “total execution time” refers to the elapsed time to send one task for remote processing and receive its result. MCC-Instrumenter instruments the uploaded code putting calls for methods of the class TimeLogger (see Algorithm 5). More specifically, MCC-Instrumenter inserts calls to the registerStart() and registerEnd() methods at specific points. After that, MCC-Instrumenter generates a zip file containing the instrumented code and auxiliary classes. Developer must build his MCC application with the updated code. Still, observing Fig. 10, in step 2, the developer must perform experiments with his instrumented app. During experiments, the required parameters are collected for further analysis. The logs generated are stored at a remote server to be used by the MCC-Adviser afterward. It is important to highlight that the instrumented code and auxiliary classes will not be part of the final version of the MCC application. They are only used to facilitate data collection and measurement during the MCC planning phase.

Algorithm 5 TimeLogger Class 1: init T ime ← 0 2: 3: procedure r egister Star t () 4: init T ime ← System.curr ent T ime() 5: 6: procedure r egister End(method N ame) 7: timeSpent ← System.curr ent T ime() − init T ime 8: writeLog(method N ame, timeSpent)

6 BCEL: https://commons.apache.org/proper/commons-bcel/.

123


STEP 1: MCC-Instrumenter Instruments the Source Code Original Code

Instrumented Code

@Evaluate public void rootMethod(){ m1(); m2(); m3(); }

@Evaluate public void rootMethod(){ registerStart(); m1(); registerEnd(); registerStart(); m2(); registerEnd(); registerStart(); m3(); registerEnd();

MCC- Instrumenter }

STEP 2: Run Experiments Mobile Device

Server

Offloading

Instrumented Code

Instrumented Code

Return Results MCC-Logger

MCC-Logger

log-bytes.csv

log-time.csv

m1(): 129 Bytes m2(): 426 Bytes m3(): 243 Bytes

m1(): 713 ms m2(): 423 ms m3(): 974 ms

Fig. 10 Collecting input parameters

4.5.2 Solving SPN models and plotting results After collecting the metrics, it is necessary to set input parameters for MCC-Adviser. Next, the tool generates an SPN model based on the source code structure. The act of configuring transitions with input parameters is called refinement process. Only when setting transitions and places with initial values, the stochastic model may generate some result. The final step is to solve the SPN model and plotting the results over the charts.

123


Fig. 11 Main classes of Mercury API

The MoDCS7,8 research group maintains a tool called Mercury. Mercury is a powerful modeling tool that allows the evaluation of performance and dependability models. The engine core of the Mercury [8,57] is the base of the MCC-Adviser. Users may use the Mercury both as a dashboard through a graphical user interface and as an API. The formalisms available in the Mercury are as follows: CTMC, DTMC, RBD, SPN, and EFM. As an API, Mercury provides a class called SPNModel for the analysis of SPN models (see Fig. 11). Thus, the first step the MCC-Adviser does is to instantiate the class SPNModel to create a model that represents the evaluated code. Then, for each evaluated method, the tool instantiates Places, Transitions, and corresponding Arcs and incorporates them into the model. Tokens are assigned to specific places. After that, MCC-Adviser assigns the input parameters passed by the developer to the model. Now, MCC-Adviser is able to compute metrics and plotting the results.

5 Case studies This section presents two case studies to show the applicability of the proposed approach. Section 5.1 shows a tool inspired by the Pokémon Go game [52]. The case study evaluates an application that solves a routing problem using the Dijkstra algorithm [18]. Section 5.2 presents a case study observing the execution time metric using an application for reducing images color.

7 MoDCS: http://www.modcs.org/. 8 More information about the Mercury tool is available on the MoDCS Web site.

123


5.1 Case study one: mobile game Pokémon Go (stylized as Pokémon GO) is a location-based augmented reality game developed by Niantic for iOS and Android devices. Niantic released the game in selected countries in July 2016. In the game, players use the GPS capability of their mobile devices to locate, capture, battle, and train virtual creatures, called Pokémon [52]. Dijkstra’s algorithm is an algorithm for finding the shortest paths between nodes in a graph, which may represent, for example, road networks [18]. It was conceived by computer scientist Edsger W. Dijkstra in 1956 and published 3 years later. The algorithm exists in some variants. Dijkstra’s original variant found the shortest path between two nodes, but a more common variant fixes a single node as the “source” node and finds shortest paths from the source to all other nodes in the graph, producing a shortest-path tree [19,26]. Inspired by the Pokémon Go and using the Dijkstra’s algorithm, we have implemented a simplified version of the original game. First, our game detects the user’s location using GPS. After that, it creates and distributes Pokémons nearby the user’s location. Pokémons are distributed within a certain radius of the origin (i.e., the user). The exact location of each Pokémon is decided at random. The player spends a lot of energy to catch distant Pokémons. The objective of the game is to capture the virtual creatures that are closest to him. The game calculates optimal routes between the player and the Pokémons locally or offloading to the cloud. Besides, based on the routes, the game creates a graph and executes the Dijkstra algorithm on it. It is important to highlight that, depending on the number of Pokémons, the device may consume a lot of time and energy to find optimal route between all points. In this case, offloading is preferable. The player and the Pokémons represent nodes in a graph. Consider the graph presented in Fig. 12 and the computed result of Listing 1. The player informs the number of Pokémons that he would like to capture. The game could opt to take the player (node 0) to the closest Pokémon (node 2) or walk toward the further one (node 6). Considering the example, the user has chosen three Pokémons and the game captured the closest ones to him and printed the optimized route. 1 2 3 4

Number of nodes = 8 Number of edges = 14 You are at the position 0 Desired number of pokemons: 3

5 6 7 8 9 10 11 12

The The The The The The The

shortest shortest shortest shortest shortest shortest shortest

distance distance distance distance distance distance distance

from from from from from from from

you you you you you you you

and and and and and and and

pokemon pokemon pokemon pokemon pokemon pokemon pokemon

1 2 3 4 5 6 7

is is is is is is is

3 1 4 2 4 8 4

13 14

You now have the following Pokemons: 2, 4, 1

Listing 1 Pokémon Go Simulator Result

Algorithm 6 presents the analyzed code. The evaluation process considered the root method capturePokemons() as a benchmark aiming to evaluate the offloading

123


0

3

4

1

2

3 2

1 4

2 1

3

1 4

5

2

2

7

7

4 5

6

Fig. 12 Example graph of Pokémon go simulator

possibilities. PokemonGoSimulator resides on the mobile device, and its methodcalls to captureClosestPokemons() are dependency free (lines 3–5). It means that the method-calls may be executed in parallel. The game may offload or not each of these three method-calls. Our case study analyzed and compared all method-calls combinations. Algorithm 6 PokemonGoSimulator 1: function captur e Pokemons(cs1, cs2, cs3) 2: ... 3: a ← captur eClosest Pokemons(cs1, 4) 4: b ← captur eClosest Pokemons(cs2, 9) 5: c ← captur eClosest Pokemons(cs3, 5) 6: return a, b, c 7: 8: function captur eClosest Pokemons(coor d Sets, number ) 9: r outes ← calculate Routes(coor d Sets) 10: graph ← cr eateGraph(r outes) 11: distances ← calculateDi jkstra(graph) 12: x ← pickClosest Pokemons(distances, number ) 13: return x


5.1.1 The evaluation The case study evaluated distinct offloading scenarios by using the Pokémon Simulator application. The experiments have followed principles of method-call offloading [15, 30]. The analysis has focused on the root method capturePokemons() of the class PokemonGoSimulator (see Algorithm 6). As aforementioned, the three method-calls

123

T. F. da Silva Pinheiro et al. Table 5 Scenarios to method-calls executions

Table 6 Bandwidth variation (in megabits/s)

Scenario

m1()

m2()

m3()

#1

Cloud

Cloud

Cloud

#2

Cloud

Cloud

Device

#3

Cloud

Device

Cloud

#4

Cloud

Device

Device

#5

Device

Cloud

Cloud

#6

Device

Cloud

Device

#7

Device

Device

Cloud

#8

Device

Device

Device

Operation

BW variation Minimum BW

Expected BW

Offloading data

0.5

2.0

Receiving data

1.0

3.0

are independent by making it possible for them to run in parallel on mobile devices or in the cloud. Considering three method-calls and two possibilities as target (device or cloud), eight configurations were exploited, as presented in Table 5. For simplicity, from here down the three method-calls are referenced as m1(), m2(), and m3(). The analysis evaluated application’s performance and the volume of data traffic generated over a period of 1 month9 to 30,000 active users and the resulting cost. Each user makes requests at a rate of 1/(300,000 ms) which is exponentially distributed. We have used the Amazon’s data transfer pricing table. The evaluated SLA establishes a maximum MTTE around 60 s. We have considered that the available bandwidth for offloading (upload) as well as receiving data (download) may vary within a specified limit impacting the desired metrics in each variation (see Table 6). MCC-Adviser has calculated the metrics by varying the available bandwidth. Depending on the volume of data sent and received in each user request, a high degree of bandwidth variation may result in a significant impact on evaluated metrics. As infrastructure, the private cloud Eucalyptus 3.4.0.1 [43] was used with two physical machines (one node and one controller). The physical machines have the following configuration: Intel Core i7-3770 3.4 GHz CPU, 4 GB of RAM DDR3, and 500 GB SATA HD. An Ethernet network is adopted to connect the physical servers through a single switch and one VM of type m1.medium (1 CPU, 512 MB of RAM, and 10 GB Disk). At the mobile device side, a Samsung Galaxy Note 4 was used running the Android 5.1.1 Lollipop. Only the essential system processes were running on it during the experiments. The testbed executed all method-calls locally and remotely (using one VM as offloading target). Through a controlled experiment, the collected input parameters for each method-call were (see Tables 7, 8): (i) the processing time and (ii) the num9 30 days.

123

Performance prediction for supporting mobile applications’… Table 7 Registered processing times per method-call

Table 8 Transferred bytes per method-call

m_call_1

Cloud (ms)

30,586

17,678

m2()

72,196

32,991

m3()

31,205

20,164

Method-call

Sent bytes (KB)

Received bytes (KB)

m1()

13

102

m2()

27

196

m3()

15

100

processing_time_m1

EXECUTING_m1

offloading_time_m2

OFFLOADING_m2

Device (ms)

m1()

offloading_time_m1


Method-call

RECEIVING_m1

processing_time_m2

EXECUTING_m2

receiving_time_m1

FINISH_m1

receiving_time_m2

RECEIVING_m2

FINISH_m2


OFFLOADING_m3

processing_time_m3

EXECUTING_m3

receiving_time_m3

RECEIVING_m3

FINISH_m3 T1 FINISH_ALL

Fig. 13 SPN model representing the method capturePokemons()

ber of bytes sent and received. As we can see, processing times are lower when the code is running in the cloud. The experiment executed and monitored 50 times each scenario. At the end of the process, the testbed collected the mean values of them. MCC-Adviser generated and refined the SPN models to calculate the desired metrics. MCC-Adviser evaluated the eight scenarios by combining the six processing time values as well as varying bandwidths for each operation (offloading and receiving data). The tool uses a strategy of varying the number of parallel resources. However, for this experiment, MCC-Adviser considered the maximum number of parallel resources— that is, three target virtual machines. First, it is necessary to analyze the MTTE of each scenario. Figure 13 shows the SPN model that represents the evaluated application. Transitions processing_time_m1,

123

T. F. da Silva Pinheiro et al. Table 9 MTTE of the experiment

Scenario

Result (MTTE) Minimum BW (ms)

Expected BW (ms)

#1

46,525

45,256

#2

52,594

51,797

#3

79,339

79,095

#4

83,683

83,603

#5

53,248

52,435

#6

58,673

58,171

#7

84,091

83,994

#8

87,996

87,996

100

MTTE (s)

80 60 Minimum BW

40

Expected BW

20 0 #1

#2

#3

#4

#5

#6

#7

#8

Scenarios

(a) 100

MTTE (s)

80 60 Minimum BW

40

Expected BW

20 0 #1

#2

#5

#6

#3

#4

#7

#8

Scenarios

(b) Fig. 14 MTTE results. a MTTE ordered by scenarios index. b MTTE ordered by MTTE values

processing_time_m2, and processing_time_m3 are exponential. They store the mean processing times of the method-calls m1(), m2(), and m3(), respectively. Equations 4 and 5 were used as the mean delay value of the transitions that represent the offloading (upload) and receiving (download) processes, respectively. Table 9 and Fig. 14 present the respective MTTEs. Figure 15 shows the impact of bandwidth variation on the MTTE. As the number of bytes transferred is small in each request, the bandwidth variation had little impact on the metrics evaluated in this case study (see Sect. 5.2).

123


MTTE (s)

60 55 50 45 40 Receiving: Offloading:

1.0

1.2

1.4

1.6

1.8

2.0

2.2

2.4

2.6

2.8

3.0

0.5

0.65

0.8

0.95

1.1

1.25

1.4

1.55

1.7

1.85

2.0

Available Bandwidth (Mb/s) #1

#2

#5

#6

Fig. 15 Available bandwidth and MTTEs

We can extract some conclusions by analyzing the results. Considering that the SLA accepts a maximum MTTE around 60 s, the company may adopt the configuration #1, #2, #5 or #6 as its offloading strategy. In this context, perhaps it has no advantage performing total offloading as in scenario #1. The data volume transferred may be high as the cloud executes all method-calls. Then, the company may decide to execute its mobile application adopting scenarios #2, #5 or #6. In another context, the company may choose to run the method m3() on the device, when comparing the MTTE from scenarios #7 and #8 since these scenarios have similar performances. Therefore, considering a remote infrastructure that attends multiple users, the performance gain is minimal comparing these scenarios (#7 and #8). Moreover, the company will pay more for offloading only one method-call. Service providers should be aware at when their applications are more likely to finish execution. Using CDFs, companies are able to calculate the probability of finishing the application execution within a specified time. For that aim, we have computed CDFs for all evaluated scenarios. First, the probabilities were computed by the MCCAdviser from t = 0 s to t = 150 s for all scenarios (see Fig. 16a). After, as shown in Fig. 16b, the probabilities were computed from t = 0 s to t = 60 s for only the scenarios that attend the SLA. According to Fig. 16a, the distances between the probabilities regarding the scenarios #1, #2, #5, and #6 are larger than the probabilities regarding the scenarios #3, #4, #7, and #8. The probability of finishing the execution for the scenarios that attend the SLA becomes 100% only after 150 s, whereas for those scenarios that do not attend the SLA, this happens around 250 s. Given so many scenarios, in some points, the probabilities for absorption are very close to each other. Scenarios #2 and #5 have similar probabilities of absorption. The difference between their MTTEs is around 1 s, and both scenarios offload two method-calls. The same analysis applies to the scenarios #4 and #7—46.53% to the scenario #4 and 46% to the scenario #7 (see Table 10). The difference between their MTTEs is around 400 ms, and both scenarios only offload one method-call. Such similarity is due to the number of method-calls that are executed on the mobile device and the cloud in each of the two scenarios.

123

T. F. da Silva Pinheiro et al. Table 10 Absorbing probabilities at 60 s

Scenario

Absorbing probabilities Minimum BW

Expected BW

#1

75.30

76.38

#2

68.07

68.81

#3

51.47

51.67

#4

46.46

46.53

#5

67.21

67.99

#6

60.72

61.24

#7

45.88

45.98

#8

41.40

41.40

Best performance could be observed when adopting the scenario #1 (see Fig. 16a, b). Scenario #1 has the highest probabilities for finishing execution faster. However, in that scenario more code is offloaded and, consequently, the data traffic may be higher. Thus, it may result in a higher financial cost to the service provider. In the scenario #1, the probability to finishes the code execution at 60 s is equal to 76.3%. The second-best scenario—scenario #2—offers 68.8% of probability to finalize the code execution at 60 s. The difference between their MTTEs is around 7 s, and the probability of absorption is 7.6% higher for scenario #1. The best and the worst scenario for absorbing at 60 s— scenarios #1 and #8—reflects a difference between them of 35%. Now, let us execute an analysis from another point of view. Evaluating the absorbing probability of the faster and the lower scenario that meets the SLA—scenarios #1 and #6—we can notice a difference of 15% between them to absorbing at 60 s. The difference between their MTTEs is around 13 s. Given that scenario #6 is the most constrained, the service provider should specify the observation of mainly scenario #6 in its service-level agreement. If the final user needing the application finishes execution by 60 s, the probability for scenario #6 is always around 61%. Therefore, the service provider could agree to deliver the service by charging low prices due to the offloading configuration limitations. Willing to obtain the probability of absorption, the service provider may consider any time within the range. Probability intervals can also be exploited using CDFs. Aiming to better analyze the applications, Fig. 17 depicts the respective probabilities obeying three intervals. These intervals do not elucidate the cumulative probability starting from zero but rather the difference between two moments. Consequently, the probability is reduced as far as the interval values increase over time. Stated differently, the angle of the CDF’s line decreases over time. Hence, the more declined the line, the lower the probability. The probability of absorption is greater in the T1 range compared to the other intervals. The mean absorption probability is around 37, 24, and 12% for the T1, T2, and T3 intervals, respectively. With regard to the interval 20 s to 50 s, Table 11 demonstrates the absorbing probabilities. As we can see, the probability of absorption is higher for the scenario #1 in that interval. The scenario #6 has the fourth highest absorption probability in the T1 interval. With regard to the interval T2, the probability

123


Fig. 16 Probability analysis of the scenarios based on SPNs. a CDFs of the evaluated scenarios. b CDFs of the scenarios that attends the SLA

50,000

100,000

150,000 1

P (T < t)

1 0.8

0.8

0.6

0.6 #1 #2 #3 #4 #5 #6 #7 #8

0.4 0.2 0 0

50,000

0.4 0.2

0 150,000

100,000

Execution Time (ms)

(a) 0

20,000

40,000

60,000 1

P (T < t)

1 0.8

0.8

0.6

0.6

0.4

0.4 #1 #2 #5 #6

0.2 0 0

20,000

0.2 0 60,000

40,000

Execution Time (ms)

(b) 0.6

P(t1 < T < t2)

0.5 0.4 0.3 0.2 0.1 0 1

Scenario: Time Int.:

2

3

4

5

6

7

8

1

2

3

T1

4

5

6

7

8

1

2

3

T2

4

5

6

7

8

T3

Scenarios for Method-Call Offloading Time Intervals : T1: 20 s < T < 50 s

T2 : 50 s < T < 80 s

T3: 80 s < T < 110 s

Fig. 17 Probability intervals

123

T. F. da Silva Pinheiro et al. Table 11 Absorbing probabilities with T1 interval

Table 12 Throughput for each user in each chosen scenario

Scenario

Probability

#1

48.20

#2

44.14

#3

32.84

#4

29.81

#5

43.88

#6

39.80

#7

29.56

#8

26.62

Scenario

Executions/ms Minimum bandwidth

Expected bandwidth

#1

2.8858 × 10−6

2.8964 × 10−6

#2

2.8361 × 10−6

2.8425 × 10−6

#5

2.8309 × 10−6

2.8374 × 10−6

#6

2.7880 × 10−6

2.7919 × 10−6

of absorption is higher for the scenario #6—28 %. Now, the scenario #1 has the worst absorption probability—21.5 %. Due to such a myriad of interpretations, the application developer or service provider should also pay attention to probability intervals. The next step is to identify the expected throughput for each user in each scenario. For that aim, the SPN model presented in Fig. 13 evolved. Now, an arc connects the last transition (T1) to the first place (INACTIVE) as illustrated in Fig. 18. When the system is not processing any method-calls, it corresponds to having a token in place INACTIVE. The transition T0 receives the request rate which is equal to 1/(300,000 ms). A stationary analysis obtains the throughput using Eq. 15. The equation considers both the probability of having tokens at place INACTIVE and the delay between each user request (request_time). Table 12 presents the values obtained. T p = P(#I N AC T I V E >= 1) ×

1 r equest_time

(15)

Now, let us estimate the data transfer generated by each scenario. Table 13 presents the number of bytes transferred for processing one user request in each scenario. Using Eq. 13, it is possible to find out the TTB. Total transferred byte (TTB) corresponds to the data volume transferred during a period. Table 14 demonstrates the TTB considering the application’s throughput obtained with the expected bandwidth. Table 15 shows the number of requests made by users during the evaluated period. Data traffic sent from the cloud to device for the method-calls m1(), m2() and m3() are, respectively, 102, 196 and 100 KB (see Table 8). The combination of these

123


m_call_1

offloading_time_m1


EXECUTING_m1

offloading_time_m2

OFFLOADING_m2

processing_time_m1

receiving_time_m1

RECEIVING_m1

processing_time_m2

EXECUTING_m2

FINISH_m1

receiving_time_m2

RECEIVING_m2

FINISH_m2


OFFLOADING_m3

processing_time_m3

EXECUTING_m3

receiving_time_m3

RECEIVING_m3

FINISH_m3 T1

Fig. 18 SPN model representing the method capturePokemons() adapted to calculate cost Table 13 Transferred bytes for each scenario Scenario

Sent bytes (KB)

Received bytes (KB)

Total bytes (KB)

#1

55

398

453

#2

40

298

338

#5

42

296

338

#6

27

196

223

Table 14 Total transferred bytes for each scenario Scenario

Total transferred bytes Sent bytes (TB)

Received bytes (TB)

Total (TB)

#1

11.54

83.48

95.02

#2

8.23

61.35

69.58

#5

8.63

60.82

69.45

#6

5.46

39.63

45.09

measurements let to obtain the total costs for data traffic considering distinct offloading scenarios. Amazon provides a prices table that defines the cost per transferred gigabyte (see Table 2). The cost calculation includes only the outbound data traffic generated by the offloadable methods (see Eq. 14). Table 16 summarizes the financial cost, and it evidences that the scenario with the lowest cost which attends the SLA was scenario #6 (highlighted in red). Therefore, MCC-Adviser advises #6 being the most profitable

123

T. F. da Silva Pinheiro et al. Table 15 Executions per month in each chosen scenario

Scenario

Executions/month Minimum bandwidth

Expected bandwidth

#1

7480

7507

#2

7351

7367

#5

7337

7354

#6

7226

7236

Table 16 Bytes sent from the cloud to devices and their costs on AWS for each scenario Minimum bandwidth Scenarios

#1 #2 #5 #6

Expected bandwidth

Diff

Bytes (TB)

83.18

83.48

0.30

Cost ($)

6781

6803

22

Bytes (TB)

61.21

61.35

0.14

Cost ($)

5206

5216

10

Bytes (TB)

60.68

60.82

0.14

Cost ($)

5169

5179

10

Bytes (TB)

39.57

39.63

0.06

Cost ($)

3495

3500

5

scenario, but other decisions may be traced when comparing with the MTTE. The last column represents the difference between the values obtained with the minimum bandwidth and expected bandwidth. We can see that the bandwidth variation had little impact on the amount to be paid for each scenario. The costs are inversely proportional to the MTTE, and depending on the application perhaps a lower MTTE is more important than saving money. Figure 19 compares MTTEs and costs for those scenarios that have attended the SLA. As far as the scenario index increases, less code is offloaded. In scenario #1, all method-calls are offloaded, whereas only one method-call is offloaded in scenario #6. In scenario #1, the cost is high, and the MTTE is low. In scenario #6, the interpretation is the inverse —the MTTE is high, and the cost is low. Scenarios #2 and #5 have similar results because two method-calls are offloaded and the methods m1() and m3() have similar processing times and volume of transferred data. The difference between their MTTEs and costs are 1 s and $ 37 (in 1 month), respectively. On the one hand, a response time of 1 s more may do not negatively impact on users’ QoE, and thirty-seven dollars may not mean a lot of money for a small IT company—$ 444 dollars in 1 year, approximately. On the other hand, this difference may become significant when the developer takes into account other resources consumed. Let us execute another evaluation from another perspective. Evaluating the most economical and the most expensive scenario that meets the SLA—#1 and #6—, the approach highlighted a difference around $ 3300 dollars in 1 month. The company will pay more for the adoption of the scenario #1. On the other hand, this offloading configuration will offer a higher probability for the application to complete its process-

123


6,803

3,500

5,216

60

7,000

5,179

6,000

50

MTTE (s)

8,000

5,000

40

4,000 30

3,000

20

Cost (US$)

70

2,000

10

1,000 0,000

0 #1

#2

#5

#6

Scenarios MTTE (ms)

Cost (US$)

Fig. 19 Comparing MTTEs and costs

ing within 60 s as defined in the SLA. In that case, the higher absorption probability reflects in higher financial cost. It means that the mobile application offloads more code to the cloud and the service provider will pay more for the resource consumption. Consequently, users may pay more for using the service. Projecting this amount over a period of 1 year, we obtain a difference around $ 39600 dollars. The proposed models offer evaluations that can result in decisions that provide money savings and that meet the SLA. 5.2 Case study two: color reduction application We implement and analyze an image processing mobile application following the principles of method-call computation offloading [30]. The implementation uses a simple client–server architecture with remote method invocation (RMI). Algorithm 7 demonstrates relevant parts of the source code. Application_A resides on the mobile device, and its method-calls are dependency free (lines 2–4). That is, the methods may be executed in parallel. If the method-call is offloaded to the cloud, it means that the mobile applications make image processing calls to the server by passing one input (original images). In this case, the mobile app connects to one virtual machine and then calls the method reduceColor in the server side. Thereafter, the processed image returns to the mobile device. Table 1 reveals the method-calls distribution scheme of the application. Both client and server side adopt the Open Source Computer Vision Library [45] and JavaCV [27]. We have implemented the computing vision example of Picture’s Colour Reduction [12]. This example transforms images by decreasing the number of colors depending on the picture’s size. 5.2.1 The evaluation Table 17 demonstrates the evaluated scenarios. Tables 18 and 19 show the collected input parameters for each method-call. The analysis considered a period of 30 days,

123


Algorithm 7 Application_A 1: function pr ocess I mages(img1, img2) 2: a ← r educeColor (img1) 3: b ← r educeColor (img2) 4: return a, b

Table 17 Scenarios to method-calls executions

Table 18 Registered processing times per method-call

m_call_1 m_call_2

Possibility

m1()

m2()

Scenario #1

Mobile

Mobile

Scenario #2

Mobile

Cloud

Scenario #3

Cloud

Mobile

Scenario #4

Cloud

Cloud

Method-call

Device (ms)

Cloud (ms)

m1()

81,399

17,256

m2()

131,406

25,476

Table 19 Transferred bytes per method-call Method-call

Sent bytes (MB)

Received bytes (MB)

m_call_1 (Image 1)

2.60

1.07

m_call_2 (Image 2)

4.27

1.68

1000 active users, a request rate of 1/(25,000,000 ms), and bandwidth variation (see Table 6). Figure 20 represents the SPN model for the calculation of MTTE, and Table 20 presents the respective MTTEs. Table 21 presents the number of bytes transferred for processing one user request in each scenario. Figure 21 represents the SPN model for the calculation of throughput. Tables 22 and 23 show the throughput and the number of requests made by users, respectively. Table 24 demonstrates the total bytes transferred in the period.

Table 20 MTTE of the experiment Scenario

Result (MTTE) Minimum bandwidth (ms)

Expected bandwidth (ms)

#1

162,544

#2

136,160

95,608

#3

150,273

135,863

#4

148,577

60,392

123

162,544


m_call_1

offloading_time_m1

OFFLOADING_m1

processing_time_m1

EXECUTING_m1

receiving_time_m1

RECEIVING_m1

FINISH_m1


OFFLOADING_m2

processing_time_m2

EXECUTING_m2

receiving_time_m2

RECEIVING_m2

FINISH_m2 T1 FINISH_ALL

Fig. 20 SPN with absorbing state used to calculate MTTE of an application with two parallel method-calls Table 21 Transferred bytes for each scenario Scenario

Sent bytes (MB)

Received bytes (MB)

Total bytes (MB)

#1

–

–

–

#2

4.27

1.68

5.95

#3

2.60

1.07

3.67

#4

6.87

2.75

9.62

m_call_1

offloading_time_m1

OFFLOADING_m1

processing_time_m1

EXECUTING_m1

receiving_time_m1

RECEIVING_m1

FINISH_m1


OFFLOADING_m2

processing_time_m2

EXECUTING_m2

receiving_time_m2

RECEIVING_m2

FINISH_m2 T1

Fig. 21 SPN used to calculate throughput of an application with two parallel method-calls

123

T. F. da Silva Pinheiro et al. Table 22 Throughput for each user in each scenario

Table 23 Executions per month in each scenario

Scenario

Executions/ms Minimum bandwidth

Expected bandwidth

#1

3.9741 × 10−8

3.9741 × 10−8

#2

3.9783 × 10−8

3.9847 × 10−8

#3

3.9761 × 10−8

3.9783 × 10−8

#4

3.9763 × 10−8

3.9903 × 10−8

Scenario

Executions/month Minimum BW

Table 24 Total transferred bytes for each scenario

Expected BW

Diff

#1

103,010

103,010

0

#2

103,118

103,285

166

#5

103,060

103,119

59

#6

103,067

103,430

362

Scenarios

Total transferred bytes (GB)/month Minimum BW

Expected BW

Diff

#1

–

–

–

#2

599.10

600.06

0.96

#3

369.95

370.16

0.21

#4

968.77

972.18

3.41

We can extract some conclusions by analyzing the results. The performance of scenarios #3 and #4, when executed on the minimum bandwidth requirements, was close to the performance achieved when processing the entire application locally (see Fig. 22). In scenarios #2 and #4, the actual bandwidth available for offloading and receiving data had a significant impact on the MTTE of the whole application. In theses scenarios, the higher the available bandwidth, the lower the MTTE. The method m2() is the heaviest, so it must be processed in the cloud. If m2() is processed locally, maybe it is not advantageous to only perform the offloading of method m1()—scenario #3. The performance gain is small. Scenario #4 is most suitable but the volume of data transferred in the period is high (see Fig. 23), thus justifying the adoption of scenario #2 as offloading strategy. Figure 24 shows the impact of the bandwidth variation on the MTTE. Scenario #1 was not impacted, and all processing was performed locally. The variation had little effect on the MTTE of the scenario #3. A large portion of the whole execution time was spent on local processing. On the other hand, scenario #4 was the most sensitive in relation to variation. Scenario #4 transferred more data than the other ones. In these scenarios, the impact of the bandwidth variation on the performance metrics is high when the amount of data being transferred is large.

123

MTTE (s)

Performance prediction for supporting mobile applications’… 180 160 140 120 100 80 60 40 20 0

Minimum BW Expected BW

#1

#2

#3

#4

Scenarios

MTTE (s)

(a) 180 160 140 120 100 80 60 40 20 0

Minimum BW Expected BW

#1

#3

#2

#4

Scenarios

(b) Fig. 22 MTTE results. a MTTE ordered by scenarios index. b MTTE ordered by MTTE values (expected BW)

972.18

160

370.16

140

MTTE (ms)

1,000 600.06

120

800

100

600

80

400

60 40

1,200

0.00 200

20 0

Transferred Bytes (GB)

180

0 #1

#3

#2

#4

Scenarios MTTE (ms)

Bytes (GB)

Fig. 23 Comparing MTTEs and volume of transferred data

123

T. F. da Silva Pinheiro et al. 170

MTTE (s)

150 130 110 90 70 50 Receiving: Offloading:

1.0

1.2

1.4

1.6

1.8

2.0

2.2

2.4

2.6

2.8

3.0

0.5

0.65

0.8

0.95

1.1

1.25

1.4

1.55

1.7

1.85

2.0

Available Bandwidth (Mb/s) Scenario #1

Scenario #2

Scenario #3

Scenario #4

Fig. 24 Available bandwidth and MTTEs

MCC-Adviser has computed CDFs from t = 0 s to t = 250 s for all scenarios (see Fig. 25). When comparing the CDFs of scenarios #2 and #4 (see Fig. 25a, b), we can see that there was a great variation in the probability of absorption considering the available bandwidth. According to Fig. 25a, the distance between the probabilities of the scenarios #4 and #1 is large in comparison with the distance presented in Fig. 25b. Scenario #4 transfers more data compared to the other ones; thus, the bandwidth variation in this scenario has a greater impact on the probability of absorption. When considering the CDFs of Fig. 25b, the probabilities of absorption are close to each other. Figure 26 depicts probabilities of absorption obeying two intervals and two contexts. Considering the context with the expected bandwidth (see Fig. 26a), the mean absorption probability is around 61 and 23% for the T1 and T2 intervals, respectively. The probability of absorption is high in the T1 range compared to the other one. Scenario #4 has the highest probability of absorption in the T1 interval and the lowest in the T2 interval. Considering the interval T2, maybe it is not suitable to perform the offloading since the scenario #1 has the highest probability when compared to the other ones. Considering the context with the minimum bandwidth (see Fig. 26b), the mean absorption probability is around 38.1 and 38.9% for the T1 and T2 intervals, respectively. Now, the probability of absorption is slightly higher in the interval T2. In this context, considering the T1 range, scenario #3 has a slightly higher probability of absorption compared to the other ones. Performing the full-offloading (scenario #4) has the lower probability of absorption in the interval T1. Scenario #2 has similar probabilities in both intervals. Scenarios #1 and #3 have similar probabilities considering only the interval T2. Developers should carefully evaluate the effect of the available bandwidth variation on the performance metrics. 5.2.2 Model validation Many aspects may interfere in the similarity between the model results and the reality, such as connection with bad quality. To reduce the influence of errors (e.g., noise) in

123

Performance prediction for supporting mobile applications’… Fig. 25 Probability analysis of the scenarios based on SPNs. a CDFs of the evaluated scenarios (expected BW). b CDFs of the evaluated scenarios (minimum BW)

P (T < t)

1

0

50,000 100,000 150,000 200,000 250,000 1

0.8

0.8

0.6

0.6

0.4 0.2 0

0.4

#1 #2 #3 #4

0.2

0 50,000 100,000 150,000 200,000 250,000

0

Execution Time (ms)

(a) 0

P (T < t)

1

50,000 100,000 150,000 200,000 250,000 1

0.8

0.8

0.6

0.6

0.4

0.4

#1 #2 #3 #4

0.2 0

0.2

0 50,000 100,000 150,000 200,000 250,000

0

Execution Time (ms)

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0


P(t1 < T < t2)

P(t1 < T < t2)

(b)

1

2

3

4

1

T1

2

3 T2


(a)

T2 : 100 s < T < 200 s

4

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0


1

2

3

4

1

T1

2

3

4

T2


T2 : 100 s < T < 200 s

(b)

Fig. 26 Probability intervals. a Probability interval (expected BW). b Probability interval (minimum BW)

123


the measuring process, a statistical technique called bootstrap was utilized to validate the proposed models [20,59]. Bootstrap is a resampling method: it obtains samples within a previously measured sample. Since only a limited number of samples are performed on the real hardware, the bootstrap method generates rapid results. Details are presented as follows: 1. Initially, a random sample x = (x1 , x2 , . . . , xn ) with n measurements is obtained. 2. Next, B bootstrap samples (x ∗1 , x ∗2 , . . . , x ∗B ) are generated. A bootstrap sample x ∗ = (x1∗ , x2∗ , . . . , xn∗ ) is obtained by randomly sampling n times, with replacement, the original data contained in x. The star notation indicates that x ∗ is a resampled version of x. As an example, assuming n = 5, a typical bootstrap sample might be x ∗ = (x4 , x2 , x2 , x3 , x5 ), in which x1∗ = x4 , x2∗ = x3∗ = x2 , x4∗ = x3 and x5∗ = x5 . It is important to note that each element in x has the same probability to be selected: 1/n. 3. For each bootstrap data set x ∗b , b = 1, 2, . . . , B, there is a bootstrap replication θˆ ∗ (b) = s(x ∗b ), in which s is the statistic of interest, more specifically, the mean of the bootstrap data set: ∗b

s(x ) = x

∗b

=

(

n

∗b i=1 x i )

n

(16)

∗ is the smallest replication 4. Afterward, the replications are ordered, such that θˆ(1) and θˆ ∗ is the largest one. Considering a confidence degree of 1 − α, in which α is (B)

∗ ∗ ,θˆ(B[1−α/2]) ]. the significance level, the confidence interval is denoted by [θˆ(Bα/2) For a better understanding, assuming B = 1000 and a confidence degree of 95% ∗ ,θˆ ∗ or 0.95 (α = 0.05), the confidence interval is represented by [θˆ(25) (975) ]; 5. Finally, the midrange value is calculated, which represents the final estimated value: ∗ ∗ + θˆ(B[1−α/2]) θˆ(Bα/2) mr = (17) 2 The values for n and B are, respectively, 50 and 1000 in this work. Since these values are considerably large and the adopted bootstrap method takes into account sample means, the central limit theorem [65] is used to estimate the population mean. In this study, the bootstrap technique is applied to validate the SPN models. The following steps were performed to validate each MTTE model presented in this work. First, 50 executions were conducted, capturing its total execution time (T tn ) to obtain the random sample T t = (T t1 , T t2 , . . . , T tn ). The total execution time random sample T t = (T t1 , T t2 , . . . , T tn ) is used to generate the bootstrap sample T t ∗ = (T t1∗ , T t2∗ , . . . , T t B∗ ) where B is 1000. After that, the B replications are ordered, extracting confidence intervals corresponding to each SPN model. In order to validate an SPN model, the metric extracted from it should be inside the bootstrapped confidence interval. Table 25 presents the results comparison (from both: calculated by MCC-Adviser and experiment). The results show that the MTTE extracted from the models (Model column) remains inside the respective confidence interval. Therefore, the performed experiments provided evidence that the proposed SPN modeling is reliable.

123

Performance prediction for supporting mobile applications’… Table 25 SPN model validation using bootstrap technique Scenario

MTTE (model)

MTTE (experiment)

Bootstrap CI (Bα/2)

Bootstrap CI (B[1 − α/2])

A1

22,731

22,947

22,680

23,208

B2

287,914

287,055

281,803

291,352

C3

26,147

25,761

25,223

26,300

D4

26,999

27,003

26,932

27,085

E5

110,853

111,021

110,275

111,424

F6

59,856

59,711

55,696

63,634

1 2 3 4 5

Model with three sequential method-calls with remote processing (see Algorithm 1/Fig. 4b). Model with three sequential method-calls with local processing (see Algorithm 1). Model with three parallel method-calls with remote processing (see Algorithm 3/Fig. 4f). Model with three parallel method-calls with local processing (see Algorithm 3). Model with two sequential method-calls and one in parallel with remote processing (see Algorithm 2/Fig. 4d). 6 Model with two sequential method-calls and one in parallel with local processing (see Algorithm 2)

6 Conclusion In this paper, we proposed a SPN-based formal framework to represent the partitioning of MCC applications in a method-call level. Through our modeling strategy, it is possible to evaluate performance and requests making by mobile users at application design time. More specifically, three performance metrics of the whole application are supported: the mean time to execute (MTTE), cumulative distribution function (CDF), and throughput. In addition, our framework considers the available bandwidth to send and receive tasks to the cloud, representing the communication time to transfer data. Our framework demonstrates the impact of the available bandwidth variation on the metrics. Thus, considering that the mobile application may be used by a large number of users with specific network conditions, it allows a more accurate evaluation by developers about the performance of their applications taking into account specific network requirements and offloading strategies. Besides, we have proposed an approach that supports the evaluation of data traffic and costs using SPNs. Two case studies were performed to demonstrate the feasibility of our framework. The framework has proven to be feasible, and it highlights the most appropriate strategies for offloading. We evolved the MCC-Adviser tool aiming to support the usage of the approach by companies. Such a tool is designed to allow companies to plan their mobile cloud infrastructures with minimal effort. To the best of our knowledge, this is the first work to develop an approach to support data traffic cost evaluation over public clouds using SPNs. Our strategy is not a context-aware offloading approach. Thus, network congestion is not addressed in our framework and it is a limitation of our work. However, our solution may be adapted considering strategies proposed by other authors. Going forward, we intend to evaluate more metrics as the energy consumption. We plan to transform the ideas presented herein in a context-aware offloading approach making possible the on-the-fly performance predictions and the choice of the best offloading strategy for the moment.

123


References 1. Amazon ec2 (2017). https://aws.amazon.com/ec2/pricing/. Accessed 22 May 2017 2. Andrzejak A, Kondo D, Yi S (2010) Decision model for cloud computing under SLA constraints. In: 2010 IEEE International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems, pp 257–266 3. Arajo C, Maciel P, Zimmermann A, Andrade E, Sousa E, Callou G, Cunha P (2011) Performability modeling of electronic funds transfer systems. Computing 91(4):315–334 4. Araujo J, Silva B, Oliveira D, Maciel P (2014) Dependability evaluation of a mhealth system using a mobile cloud infrastructure. In: 2014 IEEE International Conference on Systems, Man and Cybernetics (SMC). IEEE, pp 1348–1353 5. Baccarelli E, Cordeschi N, Mei A, Panella M, Shojafar M, Stefa J (2016) Energy-efficient dynamic traffic offloading and reconfiguration of networked data centers for big data stream mobile computing: review, challenges, and a case study. IEEE Network 30(2):54–61. https://doi.org/10.1109/MNET.2016. 7437025 6. Balan RK (2006) Simplifying cyber foraging. School of Computer Science, Carnegie Mellon University 7. Bolch G, Greiner S, de Meer H, Trivedi KS (2006) Queueing networks and markov chains: modeling and performance evaluation with computer science applications. Wiley-Interscience, New York 8. Callou G, Ferreira J, Maciel P, Tutsch D, Souza R (2014) An integrated modeling approach to evaluate and optimize data center sustainability, dependability and cost. Energies 7(1):238–277 9. Chang Z, Zhou Z, Ristaniemi T, Niu Z (2017) Energy efficient optimization for computation offloading in fog computing system. In: GLOBECOM 2017—2017 IEEE Global Communications Conference, pp 1–6 10. Chen S, Wang Y, Pedram M (2014) Optimal offloading control for a mobile device based on a realistic battery model and semi-Markov decision process. In: 2014 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), pp 369–375 11. Cordeschi N, Amendola D, Baccarelli E (2015) Reliable adaptive resource management for cognitive cloud vehicular networks. IEEE Trans Veh Technol 64(6):2528–2537 12. Colour reduction (2015). http://tinyurl.com/pwq8j44. Accessed 28 July 2015 13. Cordeschi N, Amendola D, Shojafar M, Baccarelli E (2015) Distributed and adaptive resource management in cloud-assisted cognitive radio vehicular networks with hard reliability guarantees. Veh Commun 2(1):1–12 14. Costa I, Araujo J, Dantas J, Campos E, Silva FA, Maciel P (2015) Availability evaluation and sensitivity analysis of a mobile backend-as-a-service platform. Qual Reliab Eng Int 32:2191–2205 15. Cuervo E et al (2010) MAUI: making smartphones last longer with code offload. In: Proceedings of the 8th International Conference on Mobile Systems, Applications, and Services, MobiSys ’10, New York, 2010. ACM, pp 49–62 16. De Sousa ETG, Lins FAA, Tavares EAG, Maciel PRM (2014) Performance and cost modeling strategy for cloud infrastructure planning. In: 2014 IEEE 7th International Conference on Cloud Computing. IEEE, pp 546–553 17. Desrochers A, Al-Jaar R, Society I C S (1995) Applications of petri nets in manufacturing systems: modeling, control, and performance analysis. IEEE Press, New York 18. Dijkstra E (1959) A note on two problems in connexion with graphs. Numer. Math. 1:269–271 19. Dijkstra for android (2016). https://github.com/stewbob/dijkstra/. Accessed 20 Aug 2016 20. Efron B, Tibshirani R (1993) An introduction to the bootstrap. Chapman and Hall, London 21. Gabner R, Schwefel H-P, Hummel K, Haring G (2011) Optimal model-based policies for component migration of mobile cloud services. In: 2011 10th IEEE International Symposium on Network Computing and Applications (NCA), pp 195–202 22. German R (2000) Performance analysis of communication systems with non-Markovian stochastic petri nets. Wiley, New York 23. German R, Kelling C, Zimmermann A, Hommel G (1995) Timenet—a toolkit for evaluating nonMarkovian stochastic petri nets. In: Proceedings 6th International Workshop on Petri Nets and Performance Models, pp 210–211 24. Greatspn (2017). http://www.di.unito.it/~greatspn/index.html. Accessed 28 July 2017 25. Herzog U (2001) Formal methods for performance evaluation. Springer, Berlin, pp 1–37

123

Performance prediction for supporting mobile applications’… 26. Jasika N, Alispahic N, Elma A, Ilvana K, Elma L, Nosovic N (2012) Dijkstra’s shortest path algorithm serial and parallel execution performance analysis. In: MIPRO, 2012 Proceedings of the 35th International Convention, pp 1811–1815 27. Javacv (2015). https://github.com/bytedeco/javacv. Accessed 28 July 2015 28. Kemp R, Palmer N, Kielmann T, Bal H (2012) Cuckoo: a computation offloading framework for smartphones. In: Gris M, Yang G (eds) Mobile computing, applications, and services, vol 76. Lecture notes of the institute for computer sciences, social informatics and telecommunications engineering. Springer, Berlin, pp 59–79 29. Kocjan P, Saeed K (2012) Face recognition in unconstrained environment. In: Saeed K, Nagashima T (eds) Biometrics and Kansei engineering. Springer, New York, pp 21–42 30. Kosta S, Aucinas A (2012) Thinkair: dynamic resource allocation and parallel execution in the cloud for mobile code offloading. In: INFOCOM, 2012 Proceedings IEEE, pp 945–953 31. Kristensen MD (2010) Scavenger: transparent development of efficient cyber foraging applications. In: 2010 IEEE International Conference on Pervasive Computing and Communications (PerCom), pp 217–226 32. Kumar K, Lu Y-H (2010) Cloud computing for mobile users: can offloading computation save energy? Computer 43(4):51–56 33. Kuo W, Zuo MJ (2003) Optimal reliability modeling: principles and applications. Wiley, New York 34. Li Z, Wang C, Xu R (2001) Computation offloading to save energy on handheld devices: a partition scheme. In: Proceedings of the 2001 International Conference on Compilers, Architecture, and Synthesis for Embedded Systems, CASES ’01, New York, NY, 2001. ACM, pp 238–246 35. Maciel P, Trivedi KS, Matias R, Kim DS (2011) Performance and dependability in service computing: concepts, techniques and research directions. In: Dependability modeling. Premier Reference Source, IgI Global. https://doi.org/10.4018/978-1-60960-794-4.ch003 36. Marsan MA (1990) Stochastic petri nets: an elementary introduction. In: Rozenberg G (ed) Advances in petri nets. Springer, New York, pp 1–29 37. Marsan MA, Balbo G, Conte G, Donatelli S, Franceschinis G (1994) Modelling with generalized stochastic petri nets, 1st edn. Wiley, New York 38. Microsoft azure (2017). https://azure.microsoft.com/en-us/pricing/details/bandwidth/. Accessed 22 May 2017 39. Molloy MK (1982) Performance analysis using stochastic petri nets. IEEE Trans Comput 31:913–917 40. Murata T (1989) Petri nets: properties, analysis and applications. Proc IEEE 77(4):541–580 41. Nelson R (2013) Probability, stochastic processes, and queueing theory: the mathematics of computer performance modeling. Springer Science & Business Media, Berlin 42. Nimmagadda Y, Kumar K, Lu Y-H, Lee C (2010) Real-time moving object recognition and tracking using computation offloading. In: 2010 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pp 2449–2455 43. Nurmi D, Wolski R, Grzegorczyk C, Obertelli G, Soman S, Youseff L, Zagorodnov D (2009) The eucalyptus open-source cloud-computing system. In: CCGRID ’09, pp 124–131 44. Oliveira D, Araujo J, Matos R, Maciel P (2013) Availability and energy consumption analysis of mobile cloud environments. In: 2013 IEEE International Conference on Systems, Man, and Cybernetics (SMC). IEEE, pp 4086–4091 45. Opencv (2015). http://opencv.org/. Accessed 28 July 2015 46. Oracle cloud (2017). https://cloud.oracle.com/en_US/storage/pricing. Accessed 22 May 2017 47. Ou S, Yang K, Liotta A, Hu L (2007) Performance analysis of offloading systems in mobile wireless environments. In: ICC’07. IEEE International Conference on Communications 2007. IEEE, pp 1821– 1826 48. Pandey S, Nepal S (2012) Modeling availability in clouds for mobile computing. In: 2012 IEEE First International Conference on Mobile Services, pp 80–87 49. Park J, Yu H, Chung K, Lee E (2011) Markov chain based monitoring service for fault tolerance in mobile cloud computing. In: 2011 IEEE Workshops of International Conference on Advanced Information Networking and Applications, pp 520–525 50. Pathak A, Hu Y, Zhang M, Bahl P, Wang Y (2011) Enabling automatic offloading of resource-intensive smartphone applications. docs.lib.purdue.edu 51. Petri C (1962) Kommunikation mit Automaten. Schriften des Rheinisch-Westfälischen Institutes für Instrumentelle Mathematik an der Universität Bonn. Rhein.-Westfäl. Inst. f. Instrumentelle Mathematik an der Univ. Bonn

123

T. F. da Silva Pinheiro et al. 52. Pokemon go (2016). http://www.pokemongo.com/. Accessed 20 Aug 2016 53. Rahimi MR, Venkatasubramanian N, Mehrotra S, Vasilakos AV (2012) Mapcloud: Mobile applications on an elastic and scalable 2-tier cloud architecture. In: Proceedings of the 2012 IEEE/ACM Fifth International Conference on Utility and Cloud Computing, UCC ’12, Washington, DC, USA, 2012. IEEE Computer Society, pp 83–90 54. Ribas M, Furtado C, Barroso G (2015) Modeling the use of spot instances for cost reduction in cloud computing adoption using a petri net framework. In: (IM), 2015 IFIP/IEEE, 2015. Query date: 18 June 2017 55. Rim H, Kim S, Kim Y, Han H (Jan 2006) Transparent method offloading for slim execution. In: 2006 1st International Symposium on Wireless Pervasive Computing, pp 1–6 56. Saarinen A, Siekkinen M, Xiao Y, Nurminen JK, Kemppainen M, Hui P (2012) Can offloading save energy for popular apps? In: Proceedings of the Seventh ACM International Workshop on Mobility in the Evolving Internet Architecture, MobiArch ’12, New York, NY, 2012. ACM, pp 3–10 57. Silva B, Callou G, Tavares E, Maciel P, Figueiredo J, Sousa E, Araujo C, Magnani F, Neves F (2013) Astro: an integrated environment for dependability and sustainability evaluation. Sustain Comput Inform Syst 3(1):1–17 58. Silva B, Maciel PRM, Zimmermann A, Brilhante J (2014) Survivability evaluation of disaster tolerant cloud computing systems. In: Proceedings of Probabilistic Safety Assessment and Management (PSAM12), Hawaii, USA, p 453. http://psam12.org/proceedings/paper/paper_453_1.pdf 59. Silva B, Tavares E, Maciel P, Nogueira B, Oliveira J, Damaso A, Rosa N (Oct 2014) Amalghma—an environment for measuring execution time and energy consumption in embedded systems. In: 2014 IEEE International Conference on Systems, Man and Cybernetics (SMC), pp 3364–3369 60. Silva B, Matos R, Callou G, Figueiredo J, Oliveira D, Ferreir J, Dantas J, Lobo Junior A, Alves V, Maciel P (2015) Mercury: an integrated environment for performance and dependability evaluation of general systems. In: Proceedings of Industrial Track at 45th Dependable Systems and Networks Conference, DSN 2015. IEEE, Rio de Janeiro 61. Silva FA, Rodrigues M, Maciel P, Kosta S, Mei A (2015) Planning mobile cloud infrastructures using stochastic petri nets and graphic processing units. In: 2015 IEEE 7th International Conference on Cloud Computing Technology and Science (CloudCom). IEEE, pp 471–474 62. Silva FA, Zaicaner G, Quesado E, Dornelas M, Silva B, Maciel P (2016) Benchmark applications used in mobile cloud computing research: a systematic mapping study. J Supercomput 72:1431–1452 63. Silva FA, Kosta S, Rodrigues M, Oliveira D, Maciel T, Mei A, Maciel P (2018) Mobile cloud performance evaluation using stochastic models. IEEE Trans Mob Comput 17(5):1134–1147 64. Soyata T, Muraleedharan R, Funai C, Kwon M, Heinzelman W (2012) Cloud-vision: real-time face recognition using a mobile-cloudlet-cloud acceleration architecture. In: 2012 IEEE Symposium on Computers and Communications (ISCC), pp 000059–000066 65. Triola M (2004) Elementary statistics, 9th edn. Addison Wesley, Reading 66. Trivedi KS (2001) Probability and statistics with reliability, queuing, and computer science applications. Wiley, New York 67. Trivedi KS, Sahner R (2009) Sharpe at the age of twenty two. SIGMETRICS Perform. Eval. Rev. 36(4):52–57

123

Performance prediction for supporting mobile

Performance prediction for supporting mobile

Suggest Documents

Performance prediction for supporting mobile ...

Performance Property Prediction Supporting ...

Designing for mobile performance

Performance Prediction for Software Architectures

Exploiting Nonstationarity for Performance Prediction

An approach for supporting P2P mobile ...

Performance Measurement for Mobile Forensic

channel prediction for mobile mimo wireless ...

Performance standards for teachers supporting nursing ... - CiteSeerX

supporting workplace learning for high performance working

Supporting distributed visualization services for high performance ...

Supporting Information High performance method for ...

Supporting Mobile Robot's Tasks through

Sailing boat performance prediction

Performance Prediction Methods - CiteSeerX

A Performance Prediction Framework for Scientific ... - CiteSeerX

Performance Prediction for Concurrent Database Workloads

efficient performance prediction for modern ... - CiteSeerX

Integrated Simulation for HVAC Performance Prediction - CiteSeerX

Interpretive Performance Prediction for High ... - Semantic Scholar

Iterative Compilation and Performance Prediction for ... - CiteSeerX

Analytical Performance Prediction for Robust Constrained Model

Performance and Reliability Prediction for Evolving ... - CiteSeerX

A Methodology for Drop Performance Prediction and