# An Analytical Framework of a Deployment Strategy for Cloud Computing Services: A Case Study of Academic Websites

Authors: Chi-Hua Chen; Hui-Fei Lin; Hsu-Chia Chang; Ping-Hsien Ho; Chi-Chun Lo
Journal: Mathematical Problems in Engineering
 (2013)

---

## Abstract

Cloud computing has become a popular topic for exploration in both academic and industrial research in recent years. In this paper, network behavior is analyzed to assess and compare the costs and risks associated with traditional local servers versus those associated with cloud computing to determine the appropriate deployment strategy. An analytic framework of a deployment strategy that involves two mathematical models and the analytical hierarchy process is proposed to analyze the costs and service level agreements of services involving using traditional local servers and platform as service platforms in the cloud. Two websites are used as test sites to analyze the costs and risks of deploying services inGoogle App Engine (GAE) (1) the website of Information and Finance of Management (IFM) at the National Chiao Tung University (NCTU) and (2) the NCTU website. If the examined websites were deployed in GAE, NCTU would save over 83.34% of the costs associated with using a traditional local server with low risk. Therefore, both the IFM and NCTU websites can be served appropriately in the cloud. Based on this strategy, a suggestion is proposed for managers and professionals.


---

## Body

## 1. Introduction

Cloud computing can provide high scalability and powerful computing capabilities, enable rapid deployment, and reduce costs for businesses [1, 2]; therefore, cloud computing is increasingly relevant. The current cloud computing service (CCS) vendors (e.g., Google, Microsoft, Salesforce.com, and Amazon.com) provide CCS requesters with three different architectures for their service deployment: infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) [3]. IaaS enables substituting a hardware infrastructure with a platform virtualization environment (e.g., a virtual private server) to offer businesses fully outsourced service [4]. PaaS provides a higher level of abstraction and can support the integration of design, development, deployment, testing, and hosting for CCS requesters [5]. SaaS provides business application software through the Internet.In recent years, numerous businesses have transferred their services PaaS platforms (e.g.,Google App Engine (GAE), Amazon Web Service (AWS), and Microsoft Azure), especially onto GAE, which can provide automatic and optimal resource allocation with scaling and load-balancing techniques. GAE also provides supports dynamic web service with full support for common web technologies and reliable storage with queries, sorting, and transactions. In addition, applications run in a secure environment with limited access to the underlying operating system in the sandbox [6]. Several factors affect CCS deployment strategies in the PaaS platform. Cloud computing providers and other parties such as service consumers and companies sign service level agreements (SLAs) to order their desired level of cloud computing service from a provider. Armbrust et al. [7] showed that the cost and the service blocking rate (SBR) are crucial factors in determining the deployment strategy. Although cloud computing can support utility computing and pay-per-use for on-demand scalability, the CCS requester is charged a high unit cost by CCS vendors. Furthermore, the available rate of CCS in accordance with SBR is considered for SLAs.Based on the relationship between demand and capacity, an analytic framework of a deployment strategy that combines theanalytical hierarchy process (AHP) to analyze the cost and an SLA based on the SBR of the CCS is proposed. Two websites are used as examples (1)the Information and Finance of Management (IFM) page on the National Chiao Tung University (NCTU) website and (2) the NCTU website. In this paper, network behaviors and the deployment factors of PaaS, which include the cost and SLA for CCS deployment strategy making, are analyzed.The remainder of the paper is organized as follows. Background knowledge and relevant technologies are presented in Section2. In Section 3, an analytic framework of a deployment strategy is proposed to analyze the cost of services and SLA, and those services are compared between the PaaS platform and a traditional local server. In Section 4, the parameters of the model affecting the cost and SLA are examined. An analysis of network behavior is also included to assess the platforms that are suitable for CCS deployment. Actual data are gathered from the IFM and the log files of NCTU websites. Finally, conclusions and recommendations for future work are offered in Section 5.


## 2. Literature Review

Necessary research background and relevant technologies include(1) CCS, (2) network behaviors, and (3) deployment strategy.


### 2.1. Cloud Computing Service

The current CCS venders (e.g., Google, Microsoft, and Amazon) provide different architectures to CCS requesters for their service deployment.Table1 shows the characteristics of major computing vendors including the types of services providing and billing models that they offer [8]. First, most CCS vendors provide a PaaS platform for users to deploy their services and use various programming languages. Second, all vendors support a pay-per-use billing model. Because the website is suitable to be deployed on PaaS platform and the deployment cost of GAE is cheaper than that of Microsoft Windows Azure, a deployment strategy using GAE is discussed and analyzed in this study.Table 1
The competitive matrix diagrams of CCS vendors [8].
Provider
Google App Engine
Microsoft Windows Azure
Amazon Web Services
IaaS
No
No
Yes
PaaS
Yes (Python, Java)
Yes (.Note, Java, Ruby, Python, PHP)
No
Compute billing model
Pay-per-use
Pay-per-use
Pay-per-use
Storage billing model
Pay-per-use
Pay-per-use
Pay-per-use
Relational database service
Yes (MySQL based)
Yes (SQL Server)
NoThe costs of the GAE PaaS platform include requests, outgoing bandwidth, incoming bandwidth, and CPU time, as shown in Table2. The default quota is divided into free quota and billing-enabled quota. For example, when the outgoing bandwidth is less than 1 GB, GAE does not charge a fee. However, when the bandwidth is higher than this amount, GAE charges customers, and the fees are based on the amount exceeding the free default quota.Table 2
Request free and billing-enabled quota [6].
Resource
Free default quota
Billing-enabled default quota
Daily limit
Maximum rate
Daily limit
Maximum rate
Requests (includes HTTPS)
43,200,000 requests
45,200 requests/minute
43,200,000 requests
45,200 requests/minute
Outgoing bandwidth (billable, includes HTTPS)
1 GB
56 MB/minute
1 GB free; 14,400 GB maximum
10 GB/minute
Incoming bandwidth (billable, includes HTTPS)
1 GB
56 MB/minute
1 GB free; 14,400 GB maximum
10 GB/minute
CPU time (billable)
6.5 CPU hours
15 CPU minutes/minute
6.5 CPU hours free; 1,729 CPU hours maximum
72 CPU minutes/minuteCloud computing involves scalability and availability. The SBR of the PaaS platform may occur because of the limits of the billing-enabled default quota. These daily limits or the maximal rate per minute affects the risk of building services on a cloud. This study explores the costs of CCSs and the billing-enabled default quota to derive SBR models for SLAs.Table3 shows the cost for computing resources. In Section 4, these costs are adopted to determine the deployment cost for a CCS.Table 3
Billable quota unit cost [6].
Resource
Unit
Unit cost
Outgoing bandwidth
Gigabytes
$0.12
Incoming bandwidth
Gigabytes
$0.10
CPU time
CPU hours
$0.10
Stored data
Gigabytes per month
$0.15
High replication storage
Gigabytes per month
$0.45
Recipients emailed
Recipients
$0.0001
Always on
N/A (daily)
$0.30


### 2.2. Network Behaviors

Certain network behaviors have been defined, these include network path, interarrival patterns, andtransmission control protocol (TCP) behavior patterns. Mogul used interarrival patterns which include packet arrivals, request arrivals, and per-client request arrivals to analyze HTTP server logs. Then the interarrival distribution was obtained for several categories of events [9]. Inter-arrival patterns are suitable to be used in generating a probability density function for the analyzing of a web server. Therefore, interarrival patterns are used to collect the server logs and obtain the interarrival distribution for analyzing the cost and SLA of a CCS.


### 2.3. Deployment Strategy

Few studies have addressed the deployment strategy for a CCS. Therefore, this section first presents previous studies concerning the deployment strategy for a CCS. Then AHP which is a popular multiple-attribute decision-making method is described and discussed for use in the deployment strategy.


#### 2.3.1. Deployment Strategy for a Cloud Computing Service

Kang and Sim proposed a multicriteria cloud service search engine in which cloud ontology and the similarity reasoning method are considered to support matching algorithms by using three types of requirements. These requirements are(1) the functional requirement, (2) the technical requirement, and (3) the cost requirement [10]. Although their simulation results indicate that this engine can be used to search the adapter private cloud framework, the weight of each requirement is subjectively defined in the engine which is unsuitable for a public cloud.Some researchers have used the Amazon cloud fee structure and a real-life astronomy application. They considered the tradeoffs of different execution and resource provisioning plans in the simulation. When used for long term application data archival, they also studied the tradeoffs in the context of the storage and communication fees of Amazon S3. Their results show that cost can be markedly reduced without a substantial impact on application performance by providing the suitable amount of storage and computing resources [11]. However, they only focused on the resource deployment of Amazon, and the differences in deployment between local servers and the cloud platform were not compared.


#### 2.3.2. Analytical Hierarchy Process

The AHP, which was proposed by Saaty, is typically used to model multiple-attribute decision making in a hierarchical system [12]. Therefore, the AHP is used to analyze and calculate the weight of each factor for decision making. The main steps of the AHP are described as follows [13].The evaluative criteria are defined and the hierarchical system is established in Step 1.The comparative weight between the attributes of the decision elements is calculated to generate the reciprocal matrix in Step 2. For example, a set ofn compared attributes are denoted by a1,a2,…,an and the weights are defined asw1,w2,…,wn. They are shown in (1), and wi is defined as∑y=1n(aiy/∑x=1naxy)/n. For consistency measurement, the consistency index (CI), which is defined in (2), was proposed by Saaty, who suggested that the value of the CI should not exceed 0.1 for a confident result [13, 14].Consider(1)A=[a11⋯a1j⋯a1n⋮⋮⋮ai1⋯aij⋯ain⋮⋮⋮an1⋯anj⋯ann]≅[w1w1⋯w1wj⋯w1wn⋮⋮⋮wiw1⋯wiwj⋯wiwn⋮⋮⋮wnw1⋯wnwj⋯wnwn]=W,
whereaij>0, aij=1/aji, and wi=∑y=1n(aiy/∑x=1naxy)/n.Consider(2)CI=λ-nn-1,
whereλ=∑i=1n((∑j=1nwjaij)/wi)/n.The hierarchy weight at each level is calculated to determine the optimal strategy in Step 3.


## 2.1. Cloud Computing Service

The current CCS venders (e.g., Google, Microsoft, and Amazon) provide different architectures to CCS requesters for their service deployment.Table1 shows the characteristics of major computing vendors including the types of services providing and billing models that they offer [8]. First, most CCS vendors provide a PaaS platform for users to deploy their services and use various programming languages. Second, all vendors support a pay-per-use billing model. Because the website is suitable to be deployed on PaaS platform and the deployment cost of GAE is cheaper than that of Microsoft Windows Azure, a deployment strategy using GAE is discussed and analyzed in this study.Table 1
The competitive matrix diagrams of CCS vendors [8].
Provider
Google App Engine
Microsoft Windows Azure
Amazon Web Services
IaaS
No
No
Yes
PaaS
Yes (Python, Java)
Yes (.Note, Java, Ruby, Python, PHP)
No
Compute billing model
Pay-per-use
Pay-per-use
Pay-per-use
Storage billing model
Pay-per-use
Pay-per-use
Pay-per-use
Relational database service
Yes (MySQL based)
Yes (SQL Server)
NoThe costs of the GAE PaaS platform include requests, outgoing bandwidth, incoming bandwidth, and CPU time, as shown in Table2. The default quota is divided into free quota and billing-enabled quota. For example, when the outgoing bandwidth is less than 1 GB, GAE does not charge a fee. However, when the bandwidth is higher than this amount, GAE charges customers, and the fees are based on the amount exceeding the free default quota.Table 2
Request free and billing-enabled quota [6].
Resource
Free default quota
Billing-enabled default quota
Daily limit
Maximum rate
Daily limit
Maximum rate
Requests (includes HTTPS)
43,200,000 requests
45,200 requests/minute
43,200,000 requests
45,200 requests/minute
Outgoing bandwidth (billable, includes HTTPS)
1 GB
56 MB/minute
1 GB free; 14,400 GB maximum
10 GB/minute
Incoming bandwidth (billable, includes HTTPS)
1 GB
56 MB/minute
1 GB free; 14,400 GB maximum
10 GB/minute
CPU time (billable)
6.5 CPU hours
15 CPU minutes/minute
6.5 CPU hours free; 1,729 CPU hours maximum
72 CPU minutes/minuteCloud computing involves scalability and availability. The SBR of the PaaS platform may occur because of the limits of the billing-enabled default quota. These daily limits or the maximal rate per minute affects the risk of building services on a cloud. This study explores the costs of CCSs and the billing-enabled default quota to derive SBR models for SLAs.Table3 shows the cost for computing resources. In Section 4, these costs are adopted to determine the deployment cost for a CCS.Table 3
Billable quota unit cost [6].
Resource
Unit
Unit cost
Outgoing bandwidth
Gigabytes
$0.12
Incoming bandwidth
Gigabytes
$0.10
CPU time
CPU hours
$0.10
Stored data
Gigabytes per month
$0.15
High replication storage
Gigabytes per month
$0.45
Recipients emailed
Recipients
$0.0001
Always on
N/A (daily)
$0.30


## 2.2. Network Behaviors

Certain network behaviors have been defined, these include network path, interarrival patterns, andtransmission control protocol (TCP) behavior patterns. Mogul used interarrival patterns which include packet arrivals, request arrivals, and per-client request arrivals to analyze HTTP server logs. Then the interarrival distribution was obtained for several categories of events [9]. Inter-arrival patterns are suitable to be used in generating a probability density function for the analyzing of a web server. Therefore, interarrival patterns are used to collect the server logs and obtain the interarrival distribution for analyzing the cost and SLA of a CCS.


## 2.3. Deployment Strategy

Few studies have addressed the deployment strategy for a CCS. Therefore, this section first presents previous studies concerning the deployment strategy for a CCS. Then AHP which is a popular multiple-attribute decision-making method is described and discussed for use in the deployment strategy.


### 2.3.1. Deployment Strategy for a Cloud Computing Service

Kang and Sim proposed a multicriteria cloud service search engine in which cloud ontology and the similarity reasoning method are considered to support matching algorithms by using three types of requirements. These requirements are(1) the functional requirement, (2) the technical requirement, and (3) the cost requirement [10]. Although their simulation results indicate that this engine can be used to search the adapter private cloud framework, the weight of each requirement is subjectively defined in the engine which is unsuitable for a public cloud.Some researchers have used the Amazon cloud fee structure and a real-life astronomy application. They considered the tradeoffs of different execution and resource provisioning plans in the simulation. When used for long term application data archival, they also studied the tradeoffs in the context of the storage and communication fees of Amazon S3. Their results show that cost can be markedly reduced without a substantial impact on application performance by providing the suitable amount of storage and computing resources [11]. However, they only focused on the resource deployment of Amazon, and the differences in deployment between local servers and the cloud platform were not compared.


### 2.3.2. Analytical Hierarchy Process

The AHP, which was proposed by Saaty, is typically used to model multiple-attribute decision making in a hierarchical system [12]. Therefore, the AHP is used to analyze and calculate the weight of each factor for decision making. The main steps of the AHP are described as follows [13].The evaluative criteria are defined and the hierarchical system is established in Step 1.The comparative weight between the attributes of the decision elements is calculated to generate the reciprocal matrix in Step 2. For example, a set ofn compared attributes are denoted by a1,a2,…,an and the weights are defined asw1,w2,…,wn. They are shown in (1), and wi is defined as∑y=1n(aiy/∑x=1naxy)/n. For consistency measurement, the consistency index (CI), which is defined in (2), was proposed by Saaty, who suggested that the value of the CI should not exceed 0.1 for a confident result [13, 14].Consider(1)A=[a11⋯a1j⋯a1n⋮⋮⋮ai1⋯aij⋯ain⋮⋮⋮an1⋯anj⋯ann]≅[w1w1⋯w1wj⋯w1wn⋮⋮⋮wiw1⋯wiwj⋯wiwn⋮⋮⋮wnw1⋯wnwj⋯wnwn]=W,
whereaij>0, aij=1/aji, and wi=∑y=1n(aiy/∑x=1naxy)/n.Consider(2)CI=λ-nn-1,
whereλ=∑i=1n((∑j=1nwjaij)/wi)/n.The hierarchy weight at each level is calculated to determine the optimal strategy in Step 3.


## 2.3.1. Deployment Strategy for a Cloud Computing Service

Kang and Sim proposed a multicriteria cloud service search engine in which cloud ontology and the similarity reasoning method are considered to support matching algorithms by using three types of requirements. These requirements are(1) the functional requirement, (2) the technical requirement, and (3) the cost requirement [10]. Although their simulation results indicate that this engine can be used to search the adapter private cloud framework, the weight of each requirement is subjectively defined in the engine which is unsuitable for a public cloud.Some researchers have used the Amazon cloud fee structure and a real-life astronomy application. They considered the tradeoffs of different execution and resource provisioning plans in the simulation. When used for long term application data archival, they also studied the tradeoffs in the context of the storage and communication fees of Amazon S3. Their results show that cost can be markedly reduced without a substantial impact on application performance by providing the suitable amount of storage and computing resources [11]. However, they only focused on the resource deployment of Amazon, and the differences in deployment between local servers and the cloud platform were not compared.


## 2.3.2. Analytical Hierarchy Process

The AHP, which was proposed by Saaty, is typically used to model multiple-attribute decision making in a hierarchical system [12]. Therefore, the AHP is used to analyze and calculate the weight of each factor for decision making. The main steps of the AHP are described as follows [13].The evaluative criteria are defined and the hierarchical system is established in Step 1.The comparative weight between the attributes of the decision elements is calculated to generate the reciprocal matrix in Step 2. For example, a set ofn compared attributes are denoted by a1,a2,…,an and the weights are defined asw1,w2,…,wn. They are shown in (1), and wi is defined as∑y=1n(aiy/∑x=1naxy)/n. For consistency measurement, the consistency index (CI), which is defined in (2), was proposed by Saaty, who suggested that the value of the CI should not exceed 0.1 for a confident result [13, 14].Consider(1)A=[a11⋯a1j⋯a1n⋮⋮⋮ai1⋯aij⋯ain⋮⋮⋮an1⋯anj⋯ann]≅[w1w1⋯w1wj⋯w1wn⋮⋮⋮wiw1⋯wiwj⋯wiwn⋮⋮⋮wnw1⋯wnwj⋯wnwn]=W,
whereaij>0, aij=1/aji, and wi=∑y=1n(aiy/∑x=1naxy)/n.Consider(2)CI=λ-nn-1,
whereλ=∑i=1n((∑j=1nwjaij)/wi)/n.The hierarchy weight at each level is calculated to determine the optimal strategy in Step 3.


## 3. An Analytic Framework of the Deployment Strategy for a Cloud Computing Service

This section proposes an analytic framework based on network behavior for the deployment strategy of a CCS (shown in Figure1). First, this study uses the curve-fitting method [15] which was used to determine the probability distribution for interarrival patterns (Figure 1(a)). The queueing theory is then used to measure the considered criteria which include costs and the SLA in accordance with network behaviors (Figure 1(b)). Finally, this study uses these criteria, and the AHP to set up the hierarchy system for decision making (Figure 1(c)).Figure 1
The proposed analytic framework of deployment strategy for CCS.


### 3.1. Network Behaviors for a Cloud Computing Service

Two network behaviors are considered in this study: they are the probability distribution of the request arrival process and service time. First, the request logs are collected from the web server to generate the probability distribution. Then the curve-fitting method is used based on the chi-square test to assume and verify whether the probability distribution fits the assumed probability density function (e.g., Poisson distribution and exponential distribution).


### 3.2. Criteria for a Cloud Computing Service

The proposed analytic framework of the deployment strategy includes two criteria. For the first criterion, the costs associated with the PaaS platform versus those associated with a traditional local server are calculated. For the second criterion, the SLA is measured based on the SBRs of the PaaS platform and a traditional local server.


#### 3.2.1. Criterion 1: Analysis of Costs

The analysis of service costs for the PaaS platform versus those of a local server is divided into two parts, the first for the PaaS platform and the second for the local server.(
1
)  Local Side. The costs associated with a traditional local server include network costs (CN), electricity (CE), server depreciation expenses (CSDE), and personnel costs (CP). Equation (3) is assumed to be the total cost (CL) of the traditional local server. Table 4 lists the parameters of (3).Table 4
Cost parameters for a traditional local server.
Parameter
Description
C
L
Total cost of a traditional local server
C
N
Network costs
C
E
Electricity costs
C
SDE
Server depreciation expenses
C
P
Personnel costsConsider(3)CL=CN+CE+CSDE+CP.(
2
)   Cloud: PaaS Platform. A probability density function Pr(k) is assumed in which the number of requests is equal to k for a one-day period. The average amount of data per request is defined as ξ, and the cost per gigabyte is defined as CG. In the case of GAE, for example, there is a free daily throughput of 1 GB. The CCS cost (CC) can be calculated using (4). Table 5 lists the parameters of (4).Table 5
Cost parameters for CCS.
Parameter
Description
k (request)
Number of requests per day
Pr(k)
Probability density function when the number of requests is equal tok
ξ
Average amount of data per request
r
Maximum number of requests per day
C
G
Cost per gigabyte
C
C
Total bandwidth cost per dayConsider(4)CC=(⌈ξ×∑k=0rk×Pr(k)⌉-1)×CG.


#### 3.2.2. Criterion 2: Analysis of the Service Level Agreement

Because local servers have limited computing power compared to high-capacity cloud computing services, this section proposes a SLA model based on the SBR for comparing the traditional local server with the PaaS platform.(
1
)  Local Side.There is a ceiling on the number of users a local server can service simultaneously; thus, the SBR is assumed using (5) to represent the probability Prl(c) that the number of requests for service exceeds the maximal online capacity. The SLA is defined in (6). Table 6 lists the parameters of (5) and (6).Table 6
SLA parameters for a traditional local server.
Parameter
Description
B
L, Prl(c)
Probability function when the maximum service limitc is reached
S
L
SLA of a traditional local serverConsider(5)BL=Prl(c),(6)SL=1-BL.(
2
)  Cloud: PaaS Platform. PaaS vendors typically limit the number of acceptable requests (n) per minute or per day. Therefore, a probability density function Pr(k) is assumed in which the number of requests is equal to k for a 1 minute or 1 day period; the SBR (BC) in the PaaS platform is defined in (7), and the SLA is defined in (8). Table 7 lists the parameters of (7) and (8).Table 7
SLA parameters for CCS.
Parameter
Description
B
C
Probability of the SBR on a PaaS platform
k
Number of requests per minute or day
Pr(k)
Probability density function when the number of requests is equal tok
n
The maximum allowable number of accumulated requests per minute or day
S
C
SLA on a PaaS platformConsider(7)BC=∑k=n+1∞Pr(k),(8)SC=1-BC=1-∑k=n+1∞Pr(k).


### 3.3. The Deployment Strategy for a Cloud Computing Service

In this study, the AHP is used to analyze the comparative weight between the attributes of the decision elements in a hierarchical system (Figure1(d)). The criteria include costs and the SLA, and the strategies include local side and the CCS. Therefore, six matrices can be calculated by using (1) as follows:(1)
matricesAR and WR (shown in (9)) for the weight of the criteria divided by the given cost weight wc and SLA weight ws,(2)
matricesAC and WC (shown in (10)) for the weight of strategy based on costs in accordance with (3) and (4),(3)
matricesAS and WS (shown in (11)) for the weight of the strategy based on the SLA in accordance with (6) and (8).One has(9)AR=CostSLACostSLA[1wSwCwCwS1]=WR,
where wC>0, wS>0.One has(10)AC=LocalCloudLocalCloud[1aC,CL=CLCCaC,LC=CCCL1]≅LocalCloudLocalCloud[1wC,CwC,LwC,LwC,C1]=WC,
where wC,L=CC/(CL+CC) and wC,C=CL/(CL+CC).One has(11)AS=LocalCloudLocalCloud[1aS,CL=SCSLaS,LC=SLSC1]≅LocalCloudLocalCloud[1wS,CwS,LwS,LwS,C1]=WS,
where  wS,L=SL/(SL+SC) and wS,C=SC/(SL+SC).For consistency measurement, (2) is used to test (9), (10), and (11). Because all CIs (shown in (12)) are equal to 0, the results are valid.Consider(12)CIforAR:λ-22-1=2-21=0,whereλ=(wC+wS×(wC/wS))/wC2+(wC×(wS/wC)+wS)/wS2=(wC+wC)/wC+(wS+wS)/wS2=2,CIforAC:λ-22-1=2-21=0,whereλ=(wC,L+wC,C×(CC/CL))/wC,L2+(wC,L×(CL/CC)+wC,C)/wC,C2=(CC+CC)/CC+(CL+CL)/CL2=2,CIforAS:λ-22-1=2-21=0,whereλ=(wS,L+wS,C×(SL/SC))/wS,L2+(wS,L×(SC/SL)+wS,C)/wS,C2=(SL+SL)/SL+(SC+SC)/SC2=2.For decision making, the final CCS weight (wC×wC,C+wS×wS,C) and local side weight (wC×wC,L+wS×wS,L) are compared. Furthermore, Armbrust et al. [7] indicated that the SLA should be higher than 99%; therefore, the strategy is considered when its SLA is higher than 0.99. For example, when the value of wC/wS is larger than the threshold value, δ and SC are higher than 0.99 (shown in (13)); the website is suitable to be deployed using CCS.Consider(13)wC×wC,C+wS×wS,C>wC×wC,L+wS×wS,L⟹wC×(wC,C-wC,L)>wS×(wS,L-wS,C)⟹wCwS>wS,L-wS,CwC,C-wC,L=SL/(SL+SC)-SC/(SL+SC)CL/(CL+CC)-CC/(CL+CC)=(CL+CC)(SL-SC)(CL-CC)(SL+SC)=δ,
whereSC>0.99.


## 3.1. Network Behaviors for a Cloud Computing Service

Two network behaviors are considered in this study: they are the probability distribution of the request arrival process and service time. First, the request logs are collected from the web server to generate the probability distribution. Then the curve-fitting method is used based on the chi-square test to assume and verify whether the probability distribution fits the assumed probability density function (e.g., Poisson distribution and exponential distribution).


## 3.2. Criteria for a Cloud Computing Service

The proposed analytic framework of the deployment strategy includes two criteria. For the first criterion, the costs associated with the PaaS platform versus those associated with a traditional local server are calculated. For the second criterion, the SLA is measured based on the SBRs of the PaaS platform and a traditional local server.


### 3.2.1. Criterion 1: Analysis of Costs

The analysis of service costs for the PaaS platform versus those of a local server is divided into two parts, the first for the PaaS platform and the second for the local server.(
1
)  Local Side. The costs associated with a traditional local server include network costs (CN), electricity (CE), server depreciation expenses (CSDE), and personnel costs (CP). Equation (3) is assumed to be the total cost (CL) of the traditional local server. Table 4 lists the parameters of (3).Table 4
Cost parameters for a traditional local server.
Parameter
Description
C
L
Total cost of a traditional local server
C
N
Network costs
C
E
Electricity costs
C
SDE
Server depreciation expenses
C
P
Personnel costsConsider(3)CL=CN+CE+CSDE+CP.(
2
)   Cloud: PaaS Platform. A probability density function Pr(k) is assumed in which the number of requests is equal to k for a one-day period. The average amount of data per request is defined as ξ, and the cost per gigabyte is defined as CG. In the case of GAE, for example, there is a free daily throughput of 1 GB. The CCS cost (CC) can be calculated using (4). Table 5 lists the parameters of (4).Table 5
Cost parameters for CCS.
Parameter
Description
k (request)
Number of requests per day
Pr(k)
Probability density function when the number of requests is equal tok
ξ
Average amount of data per request
r
Maximum number of requests per day
C
G
Cost per gigabyte
C
C
Total bandwidth cost per dayConsider(4)CC=(⌈ξ×∑k=0rk×Pr(k)⌉-1)×CG.


### 3.2.2. Criterion 2: Analysis of the Service Level Agreement

Because local servers have limited computing power compared to high-capacity cloud computing services, this section proposes a SLA model based on the SBR for comparing the traditional local server with the PaaS platform.(
1
)  Local Side.There is a ceiling on the number of users a local server can service simultaneously; thus, the SBR is assumed using (5) to represent the probability Prl(c) that the number of requests for service exceeds the maximal online capacity. The SLA is defined in (6). Table 6 lists the parameters of (5) and (6).Table 6
SLA parameters for a traditional local server.
Parameter
Description
B
L, Prl(c)
Probability function when the maximum service limitc is reached
S
L
SLA of a traditional local serverConsider(5)BL=Prl(c),(6)SL=1-BL.(
2
)  Cloud: PaaS Platform. PaaS vendors typically limit the number of acceptable requests (n) per minute or per day. Therefore, a probability density function Pr(k) is assumed in which the number of requests is equal to k for a 1 minute or 1 day period; the SBR (BC) in the PaaS platform is defined in (7), and the SLA is defined in (8). Table 7 lists the parameters of (7) and (8).Table 7
SLA parameters for CCS.
Parameter
Description
B
C
Probability of the SBR on a PaaS platform
k
Number of requests per minute or day
Pr(k)
Probability density function when the number of requests is equal tok
n
The maximum allowable number of accumulated requests per minute or day
S
C
SLA on a PaaS platformConsider(7)BC=∑k=n+1∞Pr(k),(8)SC=1-BC=1-∑k=n+1∞Pr(k).


## 3.2.1. Criterion 1: Analysis of Costs

The analysis of service costs for the PaaS platform versus those of a local server is divided into two parts, the first for the PaaS platform and the second for the local server.(
1
)  Local Side. The costs associated with a traditional local server include network costs (CN), electricity (CE), server depreciation expenses (CSDE), and personnel costs (CP). Equation (3) is assumed to be the total cost (CL) of the traditional local server. Table 4 lists the parameters of (3).Table 4
Cost parameters for a traditional local server.
Parameter
Description
C
L
Total cost of a traditional local server
C
N
Network costs
C
E
Electricity costs
C
SDE
Server depreciation expenses
C
P
Personnel costsConsider(3)CL=CN+CE+CSDE+CP.(
2
)   Cloud: PaaS Platform. A probability density function Pr(k) is assumed in which the number of requests is equal to k for a one-day period. The average amount of data per request is defined as ξ, and the cost per gigabyte is defined as CG. In the case of GAE, for example, there is a free daily throughput of 1 GB. The CCS cost (CC) can be calculated using (4). Table 5 lists the parameters of (4).Table 5
Cost parameters for CCS.
Parameter
Description
k (request)
Number of requests per day
Pr(k)
Probability density function when the number of requests is equal tok
ξ
Average amount of data per request
r
Maximum number of requests per day
C
G
Cost per gigabyte
C
C
Total bandwidth cost per dayConsider(4)CC=(⌈ξ×∑k=0rk×Pr(k)⌉-1)×CG.


## 3.2.2. Criterion 2: Analysis of the Service Level Agreement

Because local servers have limited computing power compared to high-capacity cloud computing services, this section proposes a SLA model based on the SBR for comparing the traditional local server with the PaaS platform.(
1
)  Local Side.There is a ceiling on the number of users a local server can service simultaneously; thus, the SBR is assumed using (5) to represent the probability Prl(c) that the number of requests for service exceeds the maximal online capacity. The SLA is defined in (6). Table 6 lists the parameters of (5) and (6).Table 6
SLA parameters for a traditional local server.
Parameter
Description
B
L, Prl(c)
Probability function when the maximum service limitc is reached
S
L
SLA of a traditional local serverConsider(5)BL=Prl(c),(6)SL=1-BL.(
2
)  Cloud: PaaS Platform. PaaS vendors typically limit the number of acceptable requests (n) per minute or per day. Therefore, a probability density function Pr(k) is assumed in which the number of requests is equal to k for a 1 minute or 1 day period; the SBR (BC) in the PaaS platform is defined in (7), and the SLA is defined in (8). Table 7 lists the parameters of (7) and (8).Table 7
SLA parameters for CCS.
Parameter
Description
B
C
Probability of the SBR on a PaaS platform
k
Number of requests per minute or day
Pr(k)
Probability density function when the number of requests is equal tok
n
The maximum allowable number of accumulated requests per minute or day
S
C
SLA on a PaaS platformConsider(7)BC=∑k=n+1∞Pr(k),(8)SC=1-BC=1-∑k=n+1∞Pr(k).


## 3.3. The Deployment Strategy for a Cloud Computing Service

In this study, the AHP is used to analyze the comparative weight between the attributes of the decision elements in a hierarchical system (Figure1(d)). The criteria include costs and the SLA, and the strategies include local side and the CCS. Therefore, six matrices can be calculated by using (1) as follows:(1)
matricesAR and WR (shown in (9)) for the weight of the criteria divided by the given cost weight wc and SLA weight ws,(2)
matricesAC and WC (shown in (10)) for the weight of strategy based on costs in accordance with (3) and (4),(3)
matricesAS and WS (shown in (11)) for the weight of the strategy based on the SLA in accordance with (6) and (8).One has(9)AR=CostSLACostSLA[1wSwCwCwS1]=WR,
where wC>0, wS>0.One has(10)AC=LocalCloudLocalCloud[1aC,CL=CLCCaC,LC=CCCL1]≅LocalCloudLocalCloud[1wC,CwC,LwC,LwC,C1]=WC,
where wC,L=CC/(CL+CC) and wC,C=CL/(CL+CC).One has(11)AS=LocalCloudLocalCloud[1aS,CL=SCSLaS,LC=SLSC1]≅LocalCloudLocalCloud[1wS,CwS,LwS,LwS,C1]=WS,
where  wS,L=SL/(SL+SC) and wS,C=SC/(SL+SC).For consistency measurement, (2) is used to test (9), (10), and (11). Because all CIs (shown in (12)) are equal to 0, the results are valid.Consider(12)CIforAR:λ-22-1=2-21=0,whereλ=(wC+wS×(wC/wS))/wC2+(wC×(wS/wC)+wS)/wS2=(wC+wC)/wC+(wS+wS)/wS2=2,CIforAC:λ-22-1=2-21=0,whereλ=(wC,L+wC,C×(CC/CL))/wC,L2+(wC,L×(CL/CC)+wC,C)/wC,C2=(CC+CC)/CC+(CL+CL)/CL2=2,CIforAS:λ-22-1=2-21=0,whereλ=(wS,L+wS,C×(SL/SC))/wS,L2+(wS,L×(SC/SL)+wS,C)/wS,C2=(SL+SL)/SL+(SC+SC)/SC2=2.For decision making, the final CCS weight (wC×wC,C+wS×wS,C) and local side weight (wC×wC,L+wS×wS,L) are compared. Furthermore, Armbrust et al. [7] indicated that the SLA should be higher than 99%; therefore, the strategy is considered when its SLA is higher than 0.99. For example, when the value of wC/wS is larger than the threshold value, δ and SC are higher than 0.99 (shown in (13)); the website is suitable to be deployed using CCS.Consider(13)wC×wC,C+wS×wS,C>wC×wC,L+wS×wS,L⟹wC×(wC,C-wC,L)>wS×(wS,L-wS,C)⟹wCwS>wS,L-wS,CwC,C-wC,L=SL/(SL+SC)-SC/(SL+SC)CL/(CL+CC)-CC/(CL+CC)=(CL+CC)(SL-SC)(CL-CC)(SL+SC)=δ,
whereSC>0.99.


## 4. Experimental Results and Discussion

Actual data from the IFM and NCTU website log files were used to analyze network behavior to assess the viability of cloud computing service deployment; this was followed by a numerical analysis of various parameters of cost and SLA for a deployment strategy.


### 4.1. Experimental Environment

The testing and analysis programs were written primarily in the Java programming language, and numerical analysis was performed using Mathematica software. Data were gathered with the assistance of the IFM and NCTU website administrators, who provided log files and server price lists for analyses of network behavior, criteria, and deployment strategy. Table8 shows the equipment and support materials used for the experiments.Table 8
Equipment and support.
Demand content
Description
Equipment
Hardware
Notebook with Intel Core 2 Duo CPU P7450 and 4 G RAM
Software
Microsoft Windows 7, Microsoft Office 2007, Microsoft Visual Studio 2008, Mathematica, and Eclipse
Support
Information and Finance of Management National Chiao Tung University website
Web server log files and server price lists
National Chiao Tung University website
Web server log files and server price lists


#### 4.1.1. Case 1: Information and Finance of Management at the National Chiao Tung University Website

The first case involved the Information and Finance of Management website. IFM is a department of NCTU; therefore, its website has fewer users than the NCTU website. Its web portal is shown in Figure2. The main services provided by the IFM website include department news, institute and member introductions, course outlines, admission information, event listings, discussion forums, and information for enrolled students.Figure 2
IFM web portal.


#### 4.1.2. Case 2: The National Chiao Tung University Website

The second case involved the NCTU website; its web portal is shown in Figure3. The university currently enrolls approximately 140,000 students. The main services provided by the NCTU website include an introduction to the institution, links to departmental overviews and websites, administrative functions, alumni services, e-learning, and campus information.Figure 3
NCTU web portal.


### 4.2. Experimental Results

The network behavior was analyzed and tested using the curve-fitting method. Based on the network behaviors, the cost and SLA were calculated using the proposed models in Section3 to generate the criterion weights. Finally, this study used AHP to analyze the weight of each strategy for decision making.


#### 4.2.1. Collection and Analysis of Network Behavior

This study analyzed the network behaviors to obtain the probability distribution of request arrival process and service time. The queueing model was used with these probability distributions for criterion analyses.(
1
)  Request Arrival Process. For the IFM case, this study used the user access records from the IFM web server for the period from March 2009 to November 2010. Subsequently, the probability density function (PDF) and the cumulative density function (CDF) of the request interarrival time (RIAT) distribution were collected and analyzed. The average RIAT (1/λ) was 60.6 sec/request for the recorded request events. This study assumed that the probability distribution of the real data (RD) is the exponential distribution (ED) function with an average RIAT of 60.6 sec/request, as shown in Table 9 and Figures 4 and 5. The PDFs of ED and RD were defined as E and O. The chi-square test was used to test this assumption. The test results showed that χ2=0.0005<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 9
The probability distributions of RIAT obtained from IFM records.
RIAT (sec/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
[0, 60]
62.846%
63.715%
62.846%
63.715%
0.0001
(60, 120]
23.350%
23.119%
86.196%
86.834%
0.0000
(120, 180]
8.675%
8.389%
94.871%
95.223%
0.0001
(180, 240]
3.223%
3.044%
98.094%
98.267%
0.0001
(240, 300]
1.198%
1.104%
99.292%
99.371%
0.0001
(300, 360]
0.445%
0.401%
99.737%
99.772%
0.0000
(360, 420]
0.165%
0.145%
99.902%
99.917%
0.0000
(420, 480]
0.061%
0.053%
99.964%
99.970%
0.0000
(480, 540]
0.023%
0.019%
99.987%
99.989%
0.0000
(540, 600]
0.008%
0.007%
99.995%
99.996%
0.0000
(600, 660]
0.003%
0.003%
99.998%
99.999%
0.0000
(660, 720]
0.001%
0.001%
99.999%
100.000%
0.0000
(720, infinite)
0.001%
0.000%
100.000%
100.000%
0.0000
Summary
0.0005Figure 4
The PDF of RIAT obtained from IFM records.Figure 5
Comparison of the measured IFM request events and their corresponding cumulative probability density using the exponential distribution function (average RIAT1/λ=60.6 sec/request).For the NCTU case, the user access records during February 2011 were collected from the NCTU web server for network behavior analyses. The average RIAT was 0.1204 sec/request for the recorded requests events, and the probability distributions were obtained, as shown in Table10 and Figures 6 and 7. The test results showed that χ2=0.7105<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 10
The probability distributions of RIAT obtained from NCTU records.
RIAT (sec/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
[0, 1]
67.386%
95.665%
67.386%
95.665%
0.1187
(1, 2]
21.977%
3.474%
89.363%
99.139%
0.1558
(2, 3]
7.168%
0.412%
96.531%
99.550%
0.0637
(3, 4]
2.338%
0.173%
98.869%
99.724%
0.0200
(4, 5]
0.762%
0.074%
99.631%
99.797%
0.0062
(5, 6]
0.249%
0.045%
99.880%
99.842%
0.0017
(6, 7]
0.081%
0.035%
99.961%
99.877%
0.0003
(7, 8]
0.026%
0.019%
99.987%
99.896%
0.0000
(8, 9]
0.009%
0.015%
99.996%
99.911%
0.0000
(9, 10]
0.003%
0.012%
99.999%
99.923%
0.0003
(10, 11]
0.001%
0.009%
100.000%
99.933%
0.0008
(11, 12]
0.000%
0.010%
100.000%
99.942%
0.0030
(12, infinite)
0.000%
0.058%
100.000%
100.000%
0.3400
Summary
0.7105Figure 6
The PDF of RIAT obtained from IFM records.Figure 7
Comparison of the measured NCTU request events and the corresponding cumulative probability density using the exponential distribution function (average RIAT1/λ=0.1204 sec/request).Therefore, this study assumed that the request arrival process corresponds to a Poisson process with requests arriving at rateλ for network behavior analysis [17]. The probability density function can be defined as (14) which shows k requests per day. The parameters of (14) are shown in Table 11.Table 11
Parameters of the request arrival process.
Parameter
Description
Pr(k)
Probability for a number of requests arriving in a cyclet
λ (request/min)
Average request arrival rate
t (min)
Request cycle time
k (requests)
Number of arriving requests per current cycle timeConsider(14)Pr(k)=(λt)ke-λtk!.(
2
)  Request Service Time. This study used the records mentioned in Section 4.2.1(1) to analyze the probability distribution of request service time. For the IFM case, the average service time 1/μ was 12.62 ms/request. The ED function fit the cumulative probability density of the service time, the average service time was 12.62 ms/request, as shown Table 12 and Figures 8 and 9. The test results showed that χ2=0.0564<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 12
The probability distributions of request service time obtained from IFM records.
Service time (ms/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
0
0.00%
0.00%
0.00%
0.00%
[0, 13]
64.30%
74.60%
64.30%
74.60%
0.0165
(13, 26]
22.95%
18.95%
87.26%
93.55%
0.0070
(26, 39]
8.19%
4.81%
95.45%
98.36%
0.0140
(39, 52]
2.92%
1.22%
98.38%
99.58%
0.0099
(52, 65]
1.04%
0.31%
99.42%
99.89%
0.0052
(65, 78]
0.37%
0.08%
99.79%
99.97%
0.0023
(78, 91]
0.13%
0.02%
99.93%
99.99%
0.0010
(91, 104]
0.05%
0.01%
99.97%
100.00%
0.0003
(104, 117]
0.02%
0.00%
99.99%
100.00%
0.0002
(117, 130]
0.01%
0.00%
100.00%
100.00%
0.0001
(130, 143]
0.00%
0.00%
100.00%
100.00%
0.0000
(143, 156]
0.00%
0.00%
100.00%
100.00%
0.0000
(156, infinite)
0.00%
0.00%
100.00%
100.00%
0.0000
Summary
0.0564Figure 8
The PDF of request service time obtained from IFM records.Figure 9
Comparison of the measured IFM service time and its corresponding cumulative probability density using the exponential distribution function (average service time1/μ=12.62 ms).For the NCTU case, the average service time1/μ was 24.24 ms/request. This study assumed that the probability of request service time is distributed as an ED. The probability distributions of request service time obtained from the NCTU records are shown in Table 13 and Figures 10 and 11. The test results showed that χ2=0.6354<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 13
The probability distributions of request service time obtained from NCTU records.
Service time (ms/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
[0, 12]
39.046%
76.060%
39.046%
76.060%
0.3509
(12, 24]
23.800%
18.210%
62.846%
94.270%
0.0131
(24, 36]
14.507%
4.360%
77.353%
98.630%
0.0710
(36, 48]
8.843%
1.040%
86.196%
99.670%
0.0688
(48, 60]
5.390%
0.250%
91.586%
99.920%
0.0490
(60, 72]
3.285%
0.060%
94.871%
99.980%
0.0317
(72, 84]
2.003%
0.020%
96.874%
100.000%
0.0196
(84, 96]
1.221%
0.000%
98.094%
100.000%
0.0122
(96, 108]
0.744%
0.000%
98.838%
100.000%
0.0074
(108, 120]
0.454%
0.000%
99.292%
100.000%
0.0045
(120, 132]
0.276%
0.000%
99.568%
100.000%
0.0028
(132, 144]
0.169%
0.000%
99.737%
100.000%
0.0017
(144, infinite)
0.263%
0.000%
100.000%
100.000%
0.0026
Summary
0.6354Figure 10
The PDF of request service time obtained from NCTU records.Figure 11
Comparison of the measured NCTU service time and its corresponding cumulative probability density using the exponential distribution function (average service time1/μ=24.24 ms).(
3
)  Summary. This study showed that the request arrival process is a Poisson process and the service time is distributed as ED. Therefore, the service process can be modeled using a simple M/M/c/c queue with the parameters λ and 1/μ [18]. Figure 12 shows a state transition rate diagram of the service process, where state c denotes that there are c clients in the server, and Pi denotes the probability of state i. The SBR Prl(c) in (5) was derived in (15), where c denotes the maximum number of connections that are simultaneously processed by a traditional local server.Figure 12
State transition rate diagram for the service scheme.Consider(15)Let∑i=0cPi=1⟹Pk=1k!(λμ)kP0∀ρ=λμ⟹Pc=ρcc!P0=ρc/c!∑k=0c(ρk/k!)=Prl(c)=BL.


#### 4.2.2. Analysis of Criteria

The cost and SLA were regarded as the criteria, and the analyzed results are presented in this section.(
1
)   Criterion 1: Cost. The proposed equations were used to calculate the costs of a traditional local server versus a PaaS platform. The costs were calculated using GAE, for which people are charged according to the billing quota, as shown in Tables 2 and 3 in Section 2.(a) Local Server Costs. Based on (3), the costs include network costs, electricity, server depreciation expenses, and personnel costs. The price of a server was assumed to be NT 60,000 depreciated over 5 years; therefore, the depreciation was CSDE=NT 1,000 per month. Electricity costs are based on the Taiwan Power Company and electricity kilowatt-hour (KWH) formula, shown in (16):
(16)KWH=electric  power(watts)×hours1,000.Regarding power consumption, Barroso [19] indicated a typical power use of 200 Watts for low-end servers; therefore, the KWH value was calculated as 200(watts)×24×30/1,000=144. The electricity cost was based on the Electricity Tariffs Table [20] and calculated on a per-month basis using (17):
(17)CE=144×2.68=385.92(NT/month).The network costs were omitted because both websites are in the university network. A student was hired to maintain this web server at a salary of 3000 (NT/month). The total cost of a traditional local server is shown in (18):
(18)CL=CN+CE+CSDE+CP=0+386+1,000+3,000=4,386(NT).(b) PaaS Platform Costs. The probability density functions for the NCTU and IFM websites are shown in (14). Thus, (19) is derived to calculate the costs of both (CC) in accordance with (4) if they operate on a PaaS platform.Consider(19)CC=(⌈ξ×∑k=0rk×(λt)ke-λtk!⌉-1)×CG.This study used actual data from the NCTU and IFM websites to calculate the cost for the GAE PaaS platform. The incoming bandwidth cost effects were ignored because the incoming bandwidth requirements were low. The actual data shown in Table14 were substituted for the parameters.Table 14
Cost parameter data for CCS.
Parameter
Real data
ξ
11793
×
2
-
30 GB
r
43,200,000 (requests)
k
0~43,200,000 (requests)
λ
0.7635 (requests/sec) in IFM8.3 (requests/sec) in NCTU
t
86400 (sec)
C
G
$0.12The bandwidth cost per day of the NCTU website on the PaaS platform was calculated using (20):
(20)CC=(⌈ξ×∑k=0rk×(λt)ke-λtk!⌉-1)×CG=(⌈∑k=043,200,000k×(8.3×86,400)k×e-8.3×86,400k!11,793×2-30×∑k=043,200,000kffff×(8.3×86,400)k×e-8.3×86,400k!⌉-1)×$0.12=$0.84.Based on the spot exchange rate of the US dollar to approximately 29 Taiwan dollars, the monthly cost of the NCTU website is0.84×29×30=730.8 (NT). A comparison of CC and  CL indicates that if the NCTU website is deployed in the cloud, the NCTU can save 83.34% of its current costs.(c) Numerical Analysis. Sensitivity analyses of two parameters, CC and CL, and their rates of change with the change parameters were investigated as follows.Effect of
ξ
on
C
C
and
C
L
. Figure 13 shows the cost CC against ξ, which indicates that CC increases as the amount of data per request ξ increases. This phenomenon is explained as follows: when the amount of data per request increases, the cost CC is higher in the PaaS platform. Regardless of the amount of data per request changes, the cost CL for a traditional local server is not influenced. Figure 13 shows the importance of accounting for the amount of data per request when seeking cost reductions on a PaaS platform.Figure 13
Effect ofξ on CC and CL.Effect of
λ
on
C
C
and
C
L
. Figure 14 shows the cost CC against λ, which indicates that CC increases as the average request arrival rate λ increases. This phenomenon is explained as follows: as the average request arrival rate λ increases, the cost CC in the PaaS platform increases. Conversely, regardless of whether the average request arrival rate λ changes, the cost CL is not influenced in a traditional local server setup. Figure 14 shows the importance of the average request arrival rate λ in reducing costs on the PaaS platform.Figure 14
Effect ofλ on CC and CL.(
2
)   Criterion 2: Service Level Agreement. This study also examined the SLA in accordance with SBR. When a service provider cannot manage a large number of simultaneous users, service errors or an inability to complete the services occur, which may result in a loss of customers. Therefore, the SBR for traditional local servers and the PaaS platform was calculated based on the previously derived equations.(a) SLA for Local Servers. The majority of website developers use the Apache HTTP Server to build their websites. In the Apache HTTP Server, the directive sets the limit on the number of simultaneous requests that can be served, with a default value of 256. Therefore, it is assumed that c is equal to 256, which is the maximum number of connections that can be processed simultaneously.In accordance with the analytic models, the service process can be modeled using a simple M/M/c/c queue with the parametersλ and 1/μ, as shown in (15). The SLA can be calculated using (6) and (15). The parameters obtained from real data for the IFM and NCTU websites are shown in Table 15. Therefore, (21) and (22) are used to calculate the SLAs of the IFM and NCTU websites, respectively, for a local server.Table 15
SLA parameter data for a traditional local server.
Parameter
Real data
λ
0.0165 (requests/sec) for IFM8.3 (requests/sec) for NCTU
1
/
μ
12.62 (ms) for IFM24.24 (ms) for NCTU
ρ
0.00021 for IFM0.201 for NCTU
c
256 maximum clientsConsider(21)BL=Prl(c)=0.00021256/256!∑k=0256(0.00021k/k!)=3.586×10-1449⟹SL=1-BL=1-3.586×10-1449,(22)BL=Prl(c)=0.201256/256!∑k=0256(0.201k/k!)=3.958×10-686⟹SL=1-BL=1-3.958×10-686.(b) SLA for PaaS Platforms. For CCS, the probability that the maxima possible requests are exceeded in 1 minute was calculated; the SLA for the PaaS platform can be obtained by using (6) and (14). The actual data parameters are shown in Table 16. Equations (23) and (24) were subsequently used to calculate the SLAs of the IFM and NCTU websites in the PaaS platform, respectively.Table 16
SLA parameter data for CCS.
Parameter
Real data
λ
0.0165 (requests/sec) for IFM8.3 (requests/sec) for NCTU
t
60 (sec)
n
Maximum rate of 45,200 (requests)Consider(23)BC=∑k=n+1∞(λt)ke-λtk!=∑k=45200+1∞(0.0165×60)ke-0.0165×60k!=1.110×10-16⟹SC=1-BC=1-1.110×10-16,(24)BC=∑k=n+1∞(λt)ke-λtk!=∑k=45200+1∞(8.3×60)ke-8.3×60k!=10-10⟹SC=1-BC=1-10-10.(c) Numerical Analysis. A numerical analysis of the models was used to investigate the network behavior of the RAIT, amount of data, and service time. It was assumed that the arrival rate has an ED with a mean of λ and the service time has an ED with a mean of1/μ. The change in BC and BL was examined using the change parameters. The effects of the input parameters were examined as follows.Effect of
λ
on
S
C
and
S
L
. Figure 15 shows the SLA SC and SL against λ, and indicates that SC and SL increase as the average request arrival rate λ increases. This phenomenon is explained as follows: as the average request arrival rate λ increases, the SLA SC and SL for both the PaaS platform and the local server increases. The effect of λ on SC is more important than the effect of λ on SL. For an average arrival rate of λ=750 request/sec, the SLA decreases rapidly in the PaaS platform. By contrast, on a traditional local server, the SLA decreases slowly until an average arrival rate of λ=8000 request/sec is achieved. Although cloud computing has an infinite capacity, the PaaS platform is limited by its maximum rate quota. Figure 15, shows the importance of the average arrival rate λ in understanding the SLA on the PaaS platform versus a local server.Figure 15
Effect ofλ on SC and SL.Effect of
1
/
μ
on
S
C
and
S
L
. Figure 16 shows the SLA SC against 1/μ, which indicates that SL decreases as the average service time 1/μ increases. This phenomenon is explained as follows: as the average service time 1/μ increases, the SBR SL decreases in the traditional local server. Conversely, regardless of the manner in which the average service time 1/μ changes, the SLA SC has no effect in the PaaS platform. Figure 16 shows that the average service time 1/μ is a crucial factor in reducing the SLA on a local server. When the average service time is long, moving to a service that deploys on a PaaS platform may mitigate or avoid the SBR problem.Figure 16
Effect of1/μ on SC and SL.


#### 4.2.3. Analysis of Deployment Strategy

For deployment strategy decision making, AHP is used to calculate the score of each strategy in this section. In accordance with (19), (20), (22), and (24), this study used (13) and a number of parameters to calculate the value of δ as (25) for the NCTU website deployment. The parameters were as follows:CL=4386,CC=730.8, SL=1-3.958×10-686, and SC=1-10-10. The results show that the value of δ is equal to 6.99934×10-11 and SC is larger than 0.99. Therefore, the NCTU website would be suitable for deployment as a CCS in the PaaS platform if the website administrator assumes that the weight of cost wC is equal to the weight of SLA wS (26). Because SL is similar toSC, the SLA has a small effect on strategy decision making. It is possible to deploy in a traditional local server when wS must be larger than (wC×1011)/6.99934 (see (27)). For the IFM case, the value of δ was smaller than that in the NCTU case because the cost of IFM website was lower than that of the NCTU website and the SLA of the IFM website is higher than that of the NCTU website. Therefore, the IFM website was also suitable for deployment as a CCS in the PaaS platform.Consider(25)δ=(CL+CC)(SL-SC)(CL-CC)(SL+SC)=(4386+730.8)[(1-3.958×10-686)-(1-10-10)](4386-730.8)[(1-3.958×10-686)+(1-10-10)]=6.99934×10-11,(26)wCwS=1>δ=6.99934×10-11,(27)wCwS<δ=6.99934×10-11⟹wS>wC×10116.99934.


### 4.3. Discussion

This study used two websites to simulate and analyze the cost and SLA of deploying services using GAE. The mathematical models based on AHP presented in Section3 were used to analyze the cost and SLA for the PaaS platform and a traditional local server. The results show that if the NCTU website is deployed using GAE, the university would save over 83.34% of its current expenditures compared to deploying on a traditional local server; this also has a negligible low effect on the SLA. This shows that the NCTU web service is appropriate for cloud computing, and its subsidiary website is suitable for IFM.A simulation analysis from a cost perspective shows that when the amount of data per request and average request arrival rateλ increase, the cost CC in the PaaS platform is higher. Conversely, variations in the amount of data per request or λ have no influence on the cost CL in a traditional local server. The results also show that as user demand on the network increases, the importance of SLA decreases, and deployment in the cloud may help to reduce average service times.


## 4.1. Experimental Environment

The testing and analysis programs were written primarily in the Java programming language, and numerical analysis was performed using Mathematica software. Data were gathered with the assistance of the IFM and NCTU website administrators, who provided log files and server price lists for analyses of network behavior, criteria, and deployment strategy. Table8 shows the equipment and support materials used for the experiments.Table 8
Equipment and support.
Demand content
Description
Equipment
Hardware
Notebook with Intel Core 2 Duo CPU P7450 and 4 G RAM
Software
Microsoft Windows 7, Microsoft Office 2007, Microsoft Visual Studio 2008, Mathematica, and Eclipse
Support
Information and Finance of Management National Chiao Tung University website
Web server log files and server price lists
National Chiao Tung University website
Web server log files and server price lists


### 4.1.1. Case 1: Information and Finance of Management at the National Chiao Tung University Website

The first case involved the Information and Finance of Management website. IFM is a department of NCTU; therefore, its website has fewer users than the NCTU website. Its web portal is shown in Figure2. The main services provided by the IFM website include department news, institute and member introductions, course outlines, admission information, event listings, discussion forums, and information for enrolled students.Figure 2
IFM web portal.


### 4.1.2. Case 2: The National Chiao Tung University Website

The second case involved the NCTU website; its web portal is shown in Figure3. The university currently enrolls approximately 140,000 students. The main services provided by the NCTU website include an introduction to the institution, links to departmental overviews and websites, administrative functions, alumni services, e-learning, and campus information.Figure 3
NCTU web portal.


## 4.1.1. Case 1: Information and Finance of Management at the National Chiao Tung University Website

The first case involved the Information and Finance of Management website. IFM is a department of NCTU; therefore, its website has fewer users than the NCTU website. Its web portal is shown in Figure2. The main services provided by the IFM website include department news, institute and member introductions, course outlines, admission information, event listings, discussion forums, and information for enrolled students.Figure 2
IFM web portal.


## 4.1.2. Case 2: The National Chiao Tung University Website

The second case involved the NCTU website; its web portal is shown in Figure3. The university currently enrolls approximately 140,000 students. The main services provided by the NCTU website include an introduction to the institution, links to departmental overviews and websites, administrative functions, alumni services, e-learning, and campus information.Figure 3
NCTU web portal.


## 4.2. Experimental Results

The network behavior was analyzed and tested using the curve-fitting method. Based on the network behaviors, the cost and SLA were calculated using the proposed models in Section3 to generate the criterion weights. Finally, this study used AHP to analyze the weight of each strategy for decision making.


### 4.2.1. Collection and Analysis of Network Behavior

This study analyzed the network behaviors to obtain the probability distribution of request arrival process and service time. The queueing model was used with these probability distributions for criterion analyses.(
1
)  Request Arrival Process. For the IFM case, this study used the user access records from the IFM web server for the period from March 2009 to November 2010. Subsequently, the probability density function (PDF) and the cumulative density function (CDF) of the request interarrival time (RIAT) distribution were collected and analyzed. The average RIAT (1/λ) was 60.6 sec/request for the recorded request events. This study assumed that the probability distribution of the real data (RD) is the exponential distribution (ED) function with an average RIAT of 60.6 sec/request, as shown in Table 9 and Figures 4 and 5. The PDFs of ED and RD were defined as E and O. The chi-square test was used to test this assumption. The test results showed that χ2=0.0005<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 9
The probability distributions of RIAT obtained from IFM records.
RIAT (sec/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
[0, 60]
62.846%
63.715%
62.846%
63.715%
0.0001
(60, 120]
23.350%
23.119%
86.196%
86.834%
0.0000
(120, 180]
8.675%
8.389%
94.871%
95.223%
0.0001
(180, 240]
3.223%
3.044%
98.094%
98.267%
0.0001
(240, 300]
1.198%
1.104%
99.292%
99.371%
0.0001
(300, 360]
0.445%
0.401%
99.737%
99.772%
0.0000
(360, 420]
0.165%
0.145%
99.902%
99.917%
0.0000
(420, 480]
0.061%
0.053%
99.964%
99.970%
0.0000
(480, 540]
0.023%
0.019%
99.987%
99.989%
0.0000
(540, 600]
0.008%
0.007%
99.995%
99.996%
0.0000
(600, 660]
0.003%
0.003%
99.998%
99.999%
0.0000
(660, 720]
0.001%
0.001%
99.999%
100.000%
0.0000
(720, infinite)
0.001%
0.000%
100.000%
100.000%
0.0000
Summary
0.0005Figure 4
The PDF of RIAT obtained from IFM records.Figure 5
Comparison of the measured IFM request events and their corresponding cumulative probability density using the exponential distribution function (average RIAT1/λ=60.6 sec/request).For the NCTU case, the user access records during February 2011 were collected from the NCTU web server for network behavior analyses. The average RIAT was 0.1204 sec/request for the recorded requests events, and the probability distributions were obtained, as shown in Table10 and Figures 6 and 7. The test results showed that χ2=0.7105<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 10
The probability distributions of RIAT obtained from NCTU records.
RIAT (sec/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
[0, 1]
67.386%
95.665%
67.386%
95.665%
0.1187
(1, 2]
21.977%
3.474%
89.363%
99.139%
0.1558
(2, 3]
7.168%
0.412%
96.531%
99.550%
0.0637
(3, 4]
2.338%
0.173%
98.869%
99.724%
0.0200
(4, 5]
0.762%
0.074%
99.631%
99.797%
0.0062
(5, 6]
0.249%
0.045%
99.880%
99.842%
0.0017
(6, 7]
0.081%
0.035%
99.961%
99.877%
0.0003
(7, 8]
0.026%
0.019%
99.987%
99.896%
0.0000
(8, 9]
0.009%
0.015%
99.996%
99.911%
0.0000
(9, 10]
0.003%
0.012%
99.999%
99.923%
0.0003
(10, 11]
0.001%
0.009%
100.000%
99.933%
0.0008
(11, 12]
0.000%
0.010%
100.000%
99.942%
0.0030
(12, infinite)
0.000%
0.058%
100.000%
100.000%
0.3400
Summary
0.7105Figure 6
The PDF of RIAT obtained from IFM records.Figure 7
Comparison of the measured NCTU request events and the corresponding cumulative probability density using the exponential distribution function (average RIAT1/λ=0.1204 sec/request).Therefore, this study assumed that the request arrival process corresponds to a Poisson process with requests arriving at rateλ for network behavior analysis [17]. The probability density function can be defined as (14) which shows k requests per day. The parameters of (14) are shown in Table 11.Table 11
Parameters of the request arrival process.
Parameter
Description
Pr(k)
Probability for a number of requests arriving in a cyclet
λ (request/min)
Average request arrival rate
t (min)
Request cycle time
k (requests)
Number of arriving requests per current cycle timeConsider(14)Pr(k)=(λt)ke-λtk!.(
2
)  Request Service Time. This study used the records mentioned in Section 4.2.1(1) to analyze the probability distribution of request service time. For the IFM case, the average service time 1/μ was 12.62 ms/request. The ED function fit the cumulative probability density of the service time, the average service time was 12.62 ms/request, as shown Table 12 and Figures 8 and 9. The test results showed that χ2=0.0564<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 12
The probability distributions of request service time obtained from IFM records.
Service time (ms/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
0
0.00%
0.00%
0.00%
0.00%
[0, 13]
64.30%
74.60%
64.30%
74.60%
0.0165
(13, 26]
22.95%
18.95%
87.26%
93.55%
0.0070
(26, 39]
8.19%
4.81%
95.45%
98.36%
0.0140
(39, 52]
2.92%
1.22%
98.38%
99.58%
0.0099
(52, 65]
1.04%
0.31%
99.42%
99.89%
0.0052
(65, 78]
0.37%
0.08%
99.79%
99.97%
0.0023
(78, 91]
0.13%
0.02%
99.93%
99.99%
0.0010
(91, 104]
0.05%
0.01%
99.97%
100.00%
0.0003
(104, 117]
0.02%
0.00%
99.99%
100.00%
0.0002
(117, 130]
0.01%
0.00%
100.00%
100.00%
0.0001
(130, 143]
0.00%
0.00%
100.00%
100.00%
0.0000
(143, 156]
0.00%
0.00%
100.00%
100.00%
0.0000
(156, infinite)
0.00%
0.00%
100.00%
100.00%
0.0000
Summary
0.0564Figure 8
The PDF of request service time obtained from IFM records.Figure 9
Comparison of the measured IFM service time and its corresponding cumulative probability density using the exponential distribution function (average service time1/μ=12.62 ms).For the NCTU case, the average service time1/μ was 24.24 ms/request. This study assumed that the probability of request service time is distributed as an ED. The probability distributions of request service time obtained from the NCTU records are shown in Table 13 and Figures 10 and 11. The test results showed that χ2=0.6354<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 13
The probability distributions of request service time obtained from NCTU records.
Service time (ms/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
[0, 12]
39.046%
76.060%
39.046%
76.060%
0.3509
(12, 24]
23.800%
18.210%
62.846%
94.270%
0.0131
(24, 36]
14.507%
4.360%
77.353%
98.630%
0.0710
(36, 48]
8.843%
1.040%
86.196%
99.670%
0.0688
(48, 60]
5.390%
0.250%
91.586%
99.920%
0.0490
(60, 72]
3.285%
0.060%
94.871%
99.980%
0.0317
(72, 84]
2.003%
0.020%
96.874%
100.000%
0.0196
(84, 96]
1.221%
0.000%
98.094%
100.000%
0.0122
(96, 108]
0.744%
0.000%
98.838%
100.000%
0.0074
(108, 120]
0.454%
0.000%
99.292%
100.000%
0.0045
(120, 132]
0.276%
0.000%
99.568%
100.000%
0.0028
(132, 144]
0.169%
0.000%
99.737%
100.000%
0.0017
(144, infinite)
0.263%
0.000%
100.000%
100.000%
0.0026
Summary
0.6354Figure 10
The PDF of request service time obtained from NCTU records.Figure 11
Comparison of the measured NCTU service time and its corresponding cumulative probability density using the exponential distribution function (average service time1/μ=24.24 ms).(
3
)  Summary. This study showed that the request arrival process is a Poisson process and the service time is distributed as ED. Therefore, the service process can be modeled using a simple M/M/c/c queue with the parameters λ and 1/μ [18]. Figure 12 shows a state transition rate diagram of the service process, where state c denotes that there are c clients in the server, and Pi denotes the probability of state i. The SBR Prl(c) in (5) was derived in (15), where c denotes the maximum number of connections that are simultaneously processed by a traditional local server.Figure 12
State transition rate diagram for the service scheme.Consider(15)Let∑i=0cPi=1⟹Pk=1k!(λμ)kP0∀ρ=λμ⟹Pc=ρcc!P0=ρc/c!∑k=0c(ρk/k!)=Prl(c)=BL.


### 4.2.2. Analysis of Criteria

The cost and SLA were regarded as the criteria, and the analyzed results are presented in this section.(
1
)   Criterion 1: Cost. The proposed equations were used to calculate the costs of a traditional local server versus a PaaS platform. The costs were calculated using GAE, for which people are charged according to the billing quota, as shown in Tables 2 and 3 in Section 2.(a) Local Server Costs. Based on (3), the costs include network costs, electricity, server depreciation expenses, and personnel costs. The price of a server was assumed to be NT 60,000 depreciated over 5 years; therefore, the depreciation was CSDE=NT 1,000 per month. Electricity costs are based on the Taiwan Power Company and electricity kilowatt-hour (KWH) formula, shown in (16):
(16)KWH=electric  power(watts)×hours1,000.Regarding power consumption, Barroso [19] indicated a typical power use of 200 Watts for low-end servers; therefore, the KWH value was calculated as 200(watts)×24×30/1,000=144. The electricity cost was based on the Electricity Tariffs Table [20] and calculated on a per-month basis using (17):
(17)CE=144×2.68=385.92(NT/month).The network costs were omitted because both websites are in the university network. A student was hired to maintain this web server at a salary of 3000 (NT/month). The total cost of a traditional local server is shown in (18):
(18)CL=CN+CE+CSDE+CP=0+386+1,000+3,000=4,386(NT).(b) PaaS Platform Costs. The probability density functions for the NCTU and IFM websites are shown in (14). Thus, (19) is derived to calculate the costs of both (CC) in accordance with (4) if they operate on a PaaS platform.Consider(19)CC=(⌈ξ×∑k=0rk×(λt)ke-λtk!⌉-1)×CG.This study used actual data from the NCTU and IFM websites to calculate the cost for the GAE PaaS platform. The incoming bandwidth cost effects were ignored because the incoming bandwidth requirements were low. The actual data shown in Table14 were substituted for the parameters.Table 14
Cost parameter data for CCS.
Parameter
Real data
ξ
11793
×
2
-
30 GB
r
43,200,000 (requests)
k
0~43,200,000 (requests)
λ
0.7635 (requests/sec) in IFM8.3 (requests/sec) in NCTU
t
86400 (sec)
C
G
$0.12The bandwidth cost per day of the NCTU website on the PaaS platform was calculated using (20):
(20)CC=(⌈ξ×∑k=0rk×(λt)ke-λtk!⌉-1)×CG=(⌈∑k=043,200,000k×(8.3×86,400)k×e-8.3×86,400k!11,793×2-30×∑k=043,200,000kffff×(8.3×86,400)k×e-8.3×86,400k!⌉-1)×$0.12=$0.84.Based on the spot exchange rate of the US dollar to approximately 29 Taiwan dollars, the monthly cost of the NCTU website is0.84×29×30=730.8 (NT). A comparison of CC and  CL indicates that if the NCTU website is deployed in the cloud, the NCTU can save 83.34% of its current costs.(c) Numerical Analysis. Sensitivity analyses of two parameters, CC and CL, and their rates of change with the change parameters were investigated as follows.Effect of
ξ
on
C
C
and
C
L
. Figure 13 shows the cost CC against ξ, which indicates that CC increases as the amount of data per request ξ increases. This phenomenon is explained as follows: when the amount of data per request increases, the cost CC is higher in the PaaS platform. Regardless of the amount of data per request changes, the cost CL for a traditional local server is not influenced. Figure 13 shows the importance of accounting for the amount of data per request when seeking cost reductions on a PaaS platform.Figure 13
Effect ofξ on CC and CL.Effect of
λ
on
C
C
and
C
L
. Figure 14 shows the cost CC against λ, which indicates that CC increases as the average request arrival rate λ increases. This phenomenon is explained as follows: as the average request arrival rate λ increases, the cost CC in the PaaS platform increases. Conversely, regardless of whether the average request arrival rate λ changes, the cost CL is not influenced in a traditional local server setup. Figure 14 shows the importance of the average request arrival rate λ in reducing costs on the PaaS platform.Figure 14
Effect ofλ on CC and CL.(
2
)   Criterion 2: Service Level Agreement. This study also examined the SLA in accordance with SBR. When a service provider cannot manage a large number of simultaneous users, service errors or an inability to complete the services occur, which may result in a loss of customers. Therefore, the SBR for traditional local servers and the PaaS platform was calculated based on the previously derived equations.(a) SLA for Local Servers. The majority of website developers use the Apache HTTP Server to build their websites. In the Apache HTTP Server, the directive sets the limit on the number of simultaneous requests that can be served, with a default value of 256. Therefore, it is assumed that c is equal to 256, which is the maximum number of connections that can be processed simultaneously.In accordance with the analytic models, the service process can be modeled using a simple M/M/c/c queue with the parametersλ and 1/μ, as shown in (15). The SLA can be calculated using (6) and (15). The parameters obtained from real data for the IFM and NCTU websites are shown in Table 15. Therefore, (21) and (22) are used to calculate the SLAs of the IFM and NCTU websites, respectively, for a local server.Table 15
SLA parameter data for a traditional local server.
Parameter
Real data
λ
0.0165 (requests/sec) for IFM8.3 (requests/sec) for NCTU
1
/
μ
12.62 (ms) for IFM24.24 (ms) for NCTU
ρ
0.00021 for IFM0.201 for NCTU
c
256 maximum clientsConsider(21)BL=Prl(c)=0.00021256/256!∑k=0256(0.00021k/k!)=3.586×10-1449⟹SL=1-BL=1-3.586×10-1449,(22)BL=Prl(c)=0.201256/256!∑k=0256(0.201k/k!)=3.958×10-686⟹SL=1-BL=1-3.958×10-686.(b) SLA for PaaS Platforms. For CCS, the probability that the maxima possible requests are exceeded in 1 minute was calculated; the SLA for the PaaS platform can be obtained by using (6) and (14). The actual data parameters are shown in Table 16. Equations (23) and (24) were subsequently used to calculate the SLAs of the IFM and NCTU websites in the PaaS platform, respectively.Table 16
SLA parameter data for CCS.
Parameter
Real data
λ
0.0165 (requests/sec) for IFM8.3 (requests/sec) for NCTU
t
60 (sec)
n
Maximum rate of 45,200 (requests)Consider(23)BC=∑k=n+1∞(λt)ke-λtk!=∑k=45200+1∞(0.0165×60)ke-0.0165×60k!=1.110×10-16⟹SC=1-BC=1-1.110×10-16,(24)BC=∑k=n+1∞(λt)ke-λtk!=∑k=45200+1∞(8.3×60)ke-8.3×60k!=10-10⟹SC=1-BC=1-10-10.(c) Numerical Analysis. A numerical analysis of the models was used to investigate the network behavior of the RAIT, amount of data, and service time. It was assumed that the arrival rate has an ED with a mean of λ and the service time has an ED with a mean of1/μ. The change in BC and BL was examined using the change parameters. The effects of the input parameters were examined as follows.Effect of
λ
on
S
C
and
S
L
. Figure 15 shows the SLA SC and SL against λ, and indicates that SC and SL increase as the average request arrival rate λ increases. This phenomenon is explained as follows: as the average request arrival rate λ increases, the SLA SC and SL for both the PaaS platform and the local server increases. The effect of λ on SC is more important than the effect of λ on SL. For an average arrival rate of λ=750 request/sec, the SLA decreases rapidly in the PaaS platform. By contrast, on a traditional local server, the SLA decreases slowly until an average arrival rate of λ=8000 request/sec is achieved. Although cloud computing has an infinite capacity, the PaaS platform is limited by its maximum rate quota. Figure 15, shows the importance of the average arrival rate λ in understanding the SLA on the PaaS platform versus a local server.Figure 15
Effect ofλ on SC and SL.Effect of
1
/
μ
on
S
C
and
S
L
. Figure 16 shows the SLA SC against 1/μ, which indicates that SL decreases as the average service time 1/μ increases. This phenomenon is explained as follows: as the average service time 1/μ increases, the SBR SL decreases in the traditional local server. Conversely, regardless of the manner in which the average service time 1/μ changes, the SLA SC has no effect in the PaaS platform. Figure 16 shows that the average service time 1/μ is a crucial factor in reducing the SLA on a local server. When the average service time is long, moving to a service that deploys on a PaaS platform may mitigate or avoid the SBR problem.Figure 16
Effect of1/μ on SC and SL.


### 4.2.3. Analysis of Deployment Strategy

For deployment strategy decision making, AHP is used to calculate the score of each strategy in this section. In accordance with (19), (20), (22), and (24), this study used (13) and a number of parameters to calculate the value of δ as (25) for the NCTU website deployment. The parameters were as follows:CL=4386,CC=730.8, SL=1-3.958×10-686, and SC=1-10-10. The results show that the value of δ is equal to 6.99934×10-11 and SC is larger than 0.99. Therefore, the NCTU website would be suitable for deployment as a CCS in the PaaS platform if the website administrator assumes that the weight of cost wC is equal to the weight of SLA wS (26). Because SL is similar toSC, the SLA has a small effect on strategy decision making. It is possible to deploy in a traditional local server when wS must be larger than (wC×1011)/6.99934 (see (27)). For the IFM case, the value of δ was smaller than that in the NCTU case because the cost of IFM website was lower than that of the NCTU website and the SLA of the IFM website is higher than that of the NCTU website. Therefore, the IFM website was also suitable for deployment as a CCS in the PaaS platform.Consider(25)δ=(CL+CC)(SL-SC)(CL-CC)(SL+SC)=(4386+730.8)[(1-3.958×10-686)-(1-10-10)](4386-730.8)[(1-3.958×10-686)+(1-10-10)]=6.99934×10-11,(26)wCwS=1>δ=6.99934×10-11,(27)wCwS<δ=6.99934×10-11⟹wS>wC×10116.99934.


## 4.2.1. Collection and Analysis of Network Behavior

This study analyzed the network behaviors to obtain the probability distribution of request arrival process and service time. The queueing model was used with these probability distributions for criterion analyses.(
1
)  Request Arrival Process. For the IFM case, this study used the user access records from the IFM web server for the period from March 2009 to November 2010. Subsequently, the probability density function (PDF) and the cumulative density function (CDF) of the request interarrival time (RIAT) distribution were collected and analyzed. The average RIAT (1/λ) was 60.6 sec/request for the recorded request events. This study assumed that the probability distribution of the real data (RD) is the exponential distribution (ED) function with an average RIAT of 60.6 sec/request, as shown in Table 9 and Figures 4 and 5. The PDFs of ED and RD were defined as E and O. The chi-square test was used to test this assumption. The test results showed that χ2=0.0005<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 9
The probability distributions of RIAT obtained from IFM records.
RIAT (sec/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
[0, 60]
62.846%
63.715%
62.846%
63.715%
0.0001
(60, 120]
23.350%
23.119%
86.196%
86.834%
0.0000
(120, 180]
8.675%
8.389%
94.871%
95.223%
0.0001
(180, 240]
3.223%
3.044%
98.094%
98.267%
0.0001
(240, 300]
1.198%
1.104%
99.292%
99.371%
0.0001
(300, 360]
0.445%
0.401%
99.737%
99.772%
0.0000
(360, 420]
0.165%
0.145%
99.902%
99.917%
0.0000
(420, 480]
0.061%
0.053%
99.964%
99.970%
0.0000
(480, 540]
0.023%
0.019%
99.987%
99.989%
0.0000
(540, 600]
0.008%
0.007%
99.995%
99.996%
0.0000
(600, 660]
0.003%
0.003%
99.998%
99.999%
0.0000
(660, 720]
0.001%
0.001%
99.999%
100.000%
0.0000
(720, infinite)
0.001%
0.000%
100.000%
100.000%
0.0000
Summary
0.0005Figure 4
The PDF of RIAT obtained from IFM records.Figure 5
Comparison of the measured IFM request events and their corresponding cumulative probability density using the exponential distribution function (average RIAT1/λ=60.6 sec/request).For the NCTU case, the user access records during February 2011 were collected from the NCTU web server for network behavior analyses. The average RIAT was 0.1204 sec/request for the recorded requests events, and the probability distributions were obtained, as shown in Table10 and Figures 6 and 7. The test results showed that χ2=0.7105<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 10
The probability distributions of RIAT obtained from NCTU records.
RIAT (sec/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
[0, 1]
67.386%
95.665%
67.386%
95.665%
0.1187
(1, 2]
21.977%
3.474%
89.363%
99.139%
0.1558
(2, 3]
7.168%
0.412%
96.531%
99.550%
0.0637
(3, 4]
2.338%
0.173%
98.869%
99.724%
0.0200
(4, 5]
0.762%
0.074%
99.631%
99.797%
0.0062
(5, 6]
0.249%
0.045%
99.880%
99.842%
0.0017
(6, 7]
0.081%
0.035%
99.961%
99.877%
0.0003
(7, 8]
0.026%
0.019%
99.987%
99.896%
0.0000
(8, 9]
0.009%
0.015%
99.996%
99.911%
0.0000
(9, 10]
0.003%
0.012%
99.999%
99.923%
0.0003
(10, 11]
0.001%
0.009%
100.000%
99.933%
0.0008
(11, 12]
0.000%
0.010%
100.000%
99.942%
0.0030
(12, infinite)
0.000%
0.058%
100.000%
100.000%
0.3400
Summary
0.7105Figure 6
The PDF of RIAT obtained from IFM records.Figure 7
Comparison of the measured NCTU request events and the corresponding cumulative probability density using the exponential distribution function (average RIAT1/λ=0.1204 sec/request).Therefore, this study assumed that the request arrival process corresponds to a Poisson process with requests arriving at rateλ for network behavior analysis [17]. The probability density function can be defined as (14) which shows k requests per day. The parameters of (14) are shown in Table 11.Table 11
Parameters of the request arrival process.
Parameter
Description
Pr(k)
Probability for a number of requests arriving in a cyclet
λ (request/min)
Average request arrival rate
t (min)
Request cycle time
k (requests)
Number of arriving requests per current cycle timeConsider(14)Pr(k)=(λt)ke-λtk!.(
2
)  Request Service Time. This study used the records mentioned in Section 4.2.1(1) to analyze the probability distribution of request service time. For the IFM case, the average service time 1/μ was 12.62 ms/request. The ED function fit the cumulative probability density of the service time, the average service time was 12.62 ms/request, as shown Table 12 and Figures 8 and 9. The test results showed that χ2=0.0564<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 12
The probability distributions of request service time obtained from IFM records.
Service time (ms/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
0
0.00%
0.00%
0.00%
0.00%
[0, 13]
64.30%
74.60%
64.30%
74.60%
0.0165
(13, 26]
22.95%
18.95%
87.26%
93.55%
0.0070
(26, 39]
8.19%
4.81%
95.45%
98.36%
0.0140
(39, 52]
2.92%
1.22%
98.38%
99.58%
0.0099
(52, 65]
1.04%
0.31%
99.42%
99.89%
0.0052
(65, 78]
0.37%
0.08%
99.79%
99.97%
0.0023
(78, 91]
0.13%
0.02%
99.93%
99.99%
0.0010
(91, 104]
0.05%
0.01%
99.97%
100.00%
0.0003
(104, 117]
0.02%
0.00%
99.99%
100.00%
0.0002
(117, 130]
0.01%
0.00%
100.00%
100.00%
0.0001
(130, 143]
0.00%
0.00%
100.00%
100.00%
0.0000
(143, 156]
0.00%
0.00%
100.00%
100.00%
0.0000
(156, infinite)
0.00%
0.00%
100.00%
100.00%
0.0000
Summary
0.0564Figure 8
The PDF of request service time obtained from IFM records.Figure 9
Comparison of the measured IFM service time and its corresponding cumulative probability density using the exponential distribution function (average service time1/μ=12.62 ms).For the NCTU case, the average service time1/μ was 24.24 ms/request. This study assumed that the probability of request service time is distributed as an ED. The probability distributions of request service time obtained from the NCTU records are shown in Table 13 and Figures 10 and 11. The test results showed that χ2=0.6354<χ12,0.052=21.026 when α=0.05 [16], and no significant difference was observed.Table 13
The probability distributions of request service time obtained from NCTU records.
Service time (ms/request)
PDF of ED (E)
PDF of RD (O)
CDF of ED
CDF of RD
(
E
-
O
)
2
/
E
[0, 12]
39.046%
76.060%
39.046%
76.060%
0.3509
(12, 24]
23.800%
18.210%
62.846%
94.270%
0.0131
(24, 36]
14.507%
4.360%
77.353%
98.630%
0.0710
(36, 48]
8.843%
1.040%
86.196%
99.670%
0.0688
(48, 60]
5.390%
0.250%
91.586%
99.920%
0.0490
(60, 72]
3.285%
0.060%
94.871%
99.980%
0.0317
(72, 84]
2.003%
0.020%
96.874%
100.000%
0.0196
(84, 96]
1.221%
0.000%
98.094%
100.000%
0.0122
(96, 108]
0.744%
0.000%
98.838%
100.000%
0.0074
(108, 120]
0.454%
0.000%
99.292%
100.000%
0.0045
(120, 132]
0.276%
0.000%
99.568%
100.000%
0.0028
(132, 144]
0.169%
0.000%
99.737%
100.000%
0.0017
(144, infinite)
0.263%
0.000%
100.000%
100.000%
0.0026
Summary
0.6354Figure 10
The PDF of request service time obtained from NCTU records.Figure 11
Comparison of the measured NCTU service time and its corresponding cumulative probability density using the exponential distribution function (average service time1/μ=24.24 ms).(
3
)  Summary. This study showed that the request arrival process is a Poisson process and the service time is distributed as ED. Therefore, the service process can be modeled using a simple M/M/c/c queue with the parameters λ and 1/μ [18]. Figure 12 shows a state transition rate diagram of the service process, where state c denotes that there are c clients in the server, and Pi denotes the probability of state i. The SBR Prl(c) in (5) was derived in (15), where c denotes the maximum number of connections that are simultaneously processed by a traditional local server.Figure 12
State transition rate diagram for the service scheme.Consider(15)Let∑i=0cPi=1⟹Pk=1k!(λμ)kP0∀ρ=λμ⟹Pc=ρcc!P0=ρc/c!∑k=0c(ρk/k!)=Prl(c)=BL.


## 4.2.2. Analysis of Criteria

The cost and SLA were regarded as the criteria, and the analyzed results are presented in this section.(
1
)   Criterion 1: Cost. The proposed equations were used to calculate the costs of a traditional local server versus a PaaS platform. The costs were calculated using GAE, for which people are charged according to the billing quota, as shown in Tables 2 and 3 in Section 2.(a) Local Server Costs. Based on (3), the costs include network costs, electricity, server depreciation expenses, and personnel costs. The price of a server was assumed to be NT 60,000 depreciated over 5 years; therefore, the depreciation was CSDE=NT 1,000 per month. Electricity costs are based on the Taiwan Power Company and electricity kilowatt-hour (KWH) formula, shown in (16):
(16)KWH=electric  power(watts)×hours1,000.Regarding power consumption, Barroso [19] indicated a typical power use of 200 Watts for low-end servers; therefore, the KWH value was calculated as 200(watts)×24×30/1,000=144. The electricity cost was based on the Electricity Tariffs Table [20] and calculated on a per-month basis using (17):
(17)CE=144×2.68=385.92(NT/month).The network costs were omitted because both websites are in the university network. A student was hired to maintain this web server at a salary of 3000 (NT/month). The total cost of a traditional local server is shown in (18):
(18)CL=CN+CE+CSDE+CP=0+386+1,000+3,000=4,386(NT).(b) PaaS Platform Costs. The probability density functions for the NCTU and IFM websites are shown in (14). Thus, (19) is derived to calculate the costs of both (CC) in accordance with (4) if they operate on a PaaS platform.Consider(19)CC=(⌈ξ×∑k=0rk×(λt)ke-λtk!⌉-1)×CG.This study used actual data from the NCTU and IFM websites to calculate the cost for the GAE PaaS platform. The incoming bandwidth cost effects were ignored because the incoming bandwidth requirements were low. The actual data shown in Table14 were substituted for the parameters.Table 14
Cost parameter data for CCS.
Parameter
Real data
ξ
11793
×
2
-
30 GB
r
43,200,000 (requests)
k
0~43,200,000 (requests)
λ
0.7635 (requests/sec) in IFM8.3 (requests/sec) in NCTU
t
86400 (sec)
C
G
$0.12The bandwidth cost per day of the NCTU website on the PaaS platform was calculated using (20):
(20)CC=(⌈ξ×∑k=0rk×(λt)ke-λtk!⌉-1)×CG=(⌈∑k=043,200,000k×(8.3×86,400)k×e-8.3×86,400k!11,793×2-30×∑k=043,200,000kffff×(8.3×86,400)k×e-8.3×86,400k!⌉-1)×$0.12=$0.84.Based on the spot exchange rate of the US dollar to approximately 29 Taiwan dollars, the monthly cost of the NCTU website is0.84×29×30=730.8 (NT). A comparison of CC and  CL indicates that if the NCTU website is deployed in the cloud, the NCTU can save 83.34% of its current costs.(c) Numerical Analysis. Sensitivity analyses of two parameters, CC and CL, and their rates of change with the change parameters were investigated as follows.Effect of
ξ
on
C
C
and
C
L
. Figure 13 shows the cost CC against ξ, which indicates that CC increases as the amount of data per request ξ increases. This phenomenon is explained as follows: when the amount of data per request increases, the cost CC is higher in the PaaS platform. Regardless of the amount of data per request changes, the cost CL for a traditional local server is not influenced. Figure 13 shows the importance of accounting for the amount of data per request when seeking cost reductions on a PaaS platform.Figure 13
Effect ofξ on CC and CL.Effect of
λ
on
C
C
and
C
L
. Figure 14 shows the cost CC against λ, which indicates that CC increases as the average request arrival rate λ increases. This phenomenon is explained as follows: as the average request arrival rate λ increases, the cost CC in the PaaS platform increases. Conversely, regardless of whether the average request arrival rate λ changes, the cost CL is not influenced in a traditional local server setup. Figure 14 shows the importance of the average request arrival rate λ in reducing costs on the PaaS platform.Figure 14
Effect ofλ on CC and CL.(
2
)   Criterion 2: Service Level Agreement. This study also examined the SLA in accordance with SBR. When a service provider cannot manage a large number of simultaneous users, service errors or an inability to complete the services occur, which may result in a loss of customers. Therefore, the SBR for traditional local servers and the PaaS platform was calculated based on the previously derived equations.(a) SLA for Local Servers. The majority of website developers use the Apache HTTP Server to build their websites. In the Apache HTTP Server, the directive sets the limit on the number of simultaneous requests that can be served, with a default value of 256. Therefore, it is assumed that c is equal to 256, which is the maximum number of connections that can be processed simultaneously.In accordance with the analytic models, the service process can be modeled using a simple M/M/c/c queue with the parametersλ and 1/μ, as shown in (15). The SLA can be calculated using (6) and (15). The parameters obtained from real data for the IFM and NCTU websites are shown in Table 15. Therefore, (21) and (22) are used to calculate the SLAs of the IFM and NCTU websites, respectively, for a local server.Table 15
SLA parameter data for a traditional local server.
Parameter
Real data
λ
0.0165 (requests/sec) for IFM8.3 (requests/sec) for NCTU
1
/
μ
12.62 (ms) for IFM24.24 (ms) for NCTU
ρ
0.00021 for IFM0.201 for NCTU
c
256 maximum clientsConsider(21)BL=Prl(c)=0.00021256/256!∑k=0256(0.00021k/k!)=3.586×10-1449⟹SL=1-BL=1-3.586×10-1449,(22)BL=Prl(c)=0.201256/256!∑k=0256(0.201k/k!)=3.958×10-686⟹SL=1-BL=1-3.958×10-686.(b) SLA for PaaS Platforms. For CCS, the probability that the maxima possible requests are exceeded in 1 minute was calculated; the SLA for the PaaS platform can be obtained by using (6) and (14). The actual data parameters are shown in Table 16. Equations (23) and (24) were subsequently used to calculate the SLAs of the IFM and NCTU websites in the PaaS platform, respectively.Table 16
SLA parameter data for CCS.
Parameter
Real data
λ
0.0165 (requests/sec) for IFM8.3 (requests/sec) for NCTU
t
60 (sec)
n
Maximum rate of 45,200 (requests)Consider(23)BC=∑k=n+1∞(λt)ke-λtk!=∑k=45200+1∞(0.0165×60)ke-0.0165×60k!=1.110×10-16⟹SC=1-BC=1-1.110×10-16,(24)BC=∑k=n+1∞(λt)ke-λtk!=∑k=45200+1∞(8.3×60)ke-8.3×60k!=10-10⟹SC=1-BC=1-10-10.(c) Numerical Analysis. A numerical analysis of the models was used to investigate the network behavior of the RAIT, amount of data, and service time. It was assumed that the arrival rate has an ED with a mean of λ and the service time has an ED with a mean of1/μ. The change in BC and BL was examined using the change parameters. The effects of the input parameters were examined as follows.Effect of
λ
on
S
C
and
S
L
. Figure 15 shows the SLA SC and SL against λ, and indicates that SC and SL increase as the average request arrival rate λ increases. This phenomenon is explained as follows: as the average request arrival rate λ increases, the SLA SC and SL for both the PaaS platform and the local server increases. The effect of λ on SC is more important than the effect of λ on SL. For an average arrival rate of λ=750 request/sec, the SLA decreases rapidly in the PaaS platform. By contrast, on a traditional local server, the SLA decreases slowly until an average arrival rate of λ=8000 request/sec is achieved. Although cloud computing has an infinite capacity, the PaaS platform is limited by its maximum rate quota. Figure 15, shows the importance of the average arrival rate λ in understanding the SLA on the PaaS platform versus a local server.Figure 15
Effect ofλ on SC and SL.Effect of
1
/
μ
on
S
C
and
S
L
. Figure 16 shows the SLA SC against 1/μ, which indicates that SL decreases as the average service time 1/μ increases. This phenomenon is explained as follows: as the average service time 1/μ increases, the SBR SL decreases in the traditional local server. Conversely, regardless of the manner in which the average service time 1/μ changes, the SLA SC has no effect in the PaaS platform. Figure 16 shows that the average service time 1/μ is a crucial factor in reducing the SLA on a local server. When the average service time is long, moving to a service that deploys on a PaaS platform may mitigate or avoid the SBR problem.Figure 16
Effect of1/μ on SC and SL.


## 4.2.3. Analysis of Deployment Strategy

For deployment strategy decision making, AHP is used to calculate the score of each strategy in this section. In accordance with (19), (20), (22), and (24), this study used (13) and a number of parameters to calculate the value of δ as (25) for the NCTU website deployment. The parameters were as follows:CL=4386,CC=730.8, SL=1-3.958×10-686, and SC=1-10-10. The results show that the value of δ is equal to 6.99934×10-11 and SC is larger than 0.99. Therefore, the NCTU website would be suitable for deployment as a CCS in the PaaS platform if the website administrator assumes that the weight of cost wC is equal to the weight of SLA wS (26). Because SL is similar toSC, the SLA has a small effect on strategy decision making. It is possible to deploy in a traditional local server when wS must be larger than (wC×1011)/6.99934 (see (27)). For the IFM case, the value of δ was smaller than that in the NCTU case because the cost of IFM website was lower than that of the NCTU website and the SLA of the IFM website is higher than that of the NCTU website. Therefore, the IFM website was also suitable for deployment as a CCS in the PaaS platform.Consider(25)δ=(CL+CC)(SL-SC)(CL-CC)(SL+SC)=(4386+730.8)[(1-3.958×10-686)-(1-10-10)](4386-730.8)[(1-3.958×10-686)+(1-10-10)]=6.99934×10-11,(26)wCwS=1>δ=6.99934×10-11,(27)wCwS<δ=6.99934×10-11⟹wS>wC×10116.99934.


## 4.3. Discussion

This study used two websites to simulate and analyze the cost and SLA of deploying services using GAE. The mathematical models based on AHP presented in Section3 were used to analyze the cost and SLA for the PaaS platform and a traditional local server. The results show that if the NCTU website is deployed using GAE, the university would save over 83.34% of its current expenditures compared to deploying on a traditional local server; this also has a negligible low effect on the SLA. This shows that the NCTU web service is appropriate for cloud computing, and its subsidiary website is suitable for IFM.A simulation analysis from a cost perspective shows that when the amount of data per request and average request arrival rateλ increase, the cost CC in the PaaS platform is higher. Conversely, variations in the amount of data per request or λ have no influence on the cost CL in a traditional local server. The results also show that as user demand on the network increases, the importance of SLA decreases, and deployment in the cloud may help to reduce average service times.


## 5. Conclusions and Future Work

This paper proposes an analytical framework that uses the curve-fitting method and analyzes user access records from the web server to generate the network behavior patterns for analyses of cost and SLA. Furthermore, this framework uses AHP to calculate the score of deploying on the PaaS platform and deploying on a traditional local server for decision making. When user demands are low, deploying services in the cloud costs less than deploying them on a traditional local server. Because it is more difficult to collect the records from business websites, academic websites which including the IFM and NCTU websites were selected as test cases and used to simulate and analyze the costs and SLA of deploying services in GAE. The results show that if the NCTU website is deployed using GAE, the university would save over 83.34% of its current expenditures than by deploying in a traditional local server; this also has a negligible effect on the SLA. However, the simulation analysis showed that, as user demand on the network increases, the importance of SLA decreases, and deploying in the cloud can help to reduce the average service time.In future studies, the authors plan to broaden their research criteria and analyze the uses of CPU time and time spent on accessing databases; for example, various types of services have various probability density functions. These services must be further investigated in subsequent studies. In addition, the business website administrators can use the proposed framework to analyze their website records and select an optimal strategy for CCS deployments.



---

*Source: 384305-2013-09-18.xml*