CARBON FOOTPRINT MINIMIZATION THROUGH

COST-AWARE LOAD BALANCING MODEL IN

CLOUD COMPUTING
A PROJECT REPORT

Submitted by

AJITHA S (15C009)
APARNA A (15C018)
KEERTHANAA K (15C054)

in partial fulfillment for the award of the degree

of

BACHELOR OF ENGINEERING
in

COMPUTER SCIENCE AND ENGINEERING

THIAGARAJAR COLLEGE OF ENGINEERING, MADURAI – 15

(A Government Aided ISO 9001: 2008 Certified Autonomous Institution Affiliated to Anna University)

ANNA UNIVERSITY: CHENNAI 600 025

APRIL 2019
 THIAGARAJAR COLLEGE OF ENGINEERING
MADURAI-15
(A Government Aided ISO 9001: 2008 Certified Autonomous Institution Affiliated to Anna University)

BONAFIDE CERTIFICATE

Certified that this project report “Carbon Footprint Minimization

Through Cost-Aware Load Balancing Model In Cloud Computing” is
the bonafide work of “AJITHA S (15C009), APARNA S (15C018),
KEERTHANAA K (15C054)” who carried out the project work under my
supervision during the Academic Year 2018-2019.

SIGNATURE SIGNATURE

Dr.S.Mercy Shalinie, M.E., Ph.D., Mrs. A. Malini, M.E.,

HEAD OF THE DEPARTMENT SUPERVISOR & ASSISTANT PROFESSOR,
COMPUTER SCIENCE AND ENGINEERING COMPUTER SCIENCE AND ENGINEERING
THIAGARAJAR COLLEGE OF ENGG. THIAGARAJAR COLLEGE OF ENGG.
MADURAI – 625 015 MADURAI – 625 015

Submitted for the VIVA VOCE Examination held at Thiagarajar College of

Engineering on ………………

INTERNAL EXAMINER EXTERNAL EXAMINER

 Acknowledgement

I wish to express my deep sense of gratitude to Dr.V.Abhai

Kumar, Principal of Thiagarajar College of Engineering for his
support and encouragement throughout this project work.

I wish to express my sincere thanks to Dr.S.Mercy Shalinie,

Head of the Department of Computer Science and Engineering for her
support and ardent guidance.

I owe my special thanks and gratitude to Mrs. A. Malini,

Assistant Professor, Department of Computer Science and Engineering
for her guidance and support throughout our project.

I am also indebted to all the teaching and non-teaching staff

members of our college for helping us directly or indirectly by all means
throughout the course of our study and project work.

I extremely thank my parents, family members and friends for

their moral support and encouragement for my project.

i
 Abstract
Balancing the incoming data traffic across the servers is termed as Load

balancing. In cloud computing, Load balancing means distributing loads

across the cloud infrastructure. The performance of cloud computing

depends on the different factors which include balancing the loads at the

data center which increase the server utilization. Proper utilization of

resources is termed as server utilization. The power consumption

decreases with an increase in server utilization which in turn reduces the

carbon footprint of the virtual machines at the data center. In this paper,

the cost-aware ant colony optimization-based load balancing model is

proposed to minimize the execution time, response time and cost in a

dynamic environment. This model enables to balance the load across the

virtual machines in the data center and evaluate the overall performance

with various load balancing models.

Keywords: cloud computing, data center, load balancing, cost, power,

energy, carbon footprint.

ii
 Table of Contents

Chapter No Title Page No

Abstract ii

List of Tables v

List of Figures vii

List of Abbreviations x

1. Introduction 1

2. Literature Survey 3

3. Requirements 6

3.1 Hardware Support 6

3.2 Software Requirements 6

3.3 Technologies Used 6

4. Proposed Method 7

4.1 UserBase 7

4.2 Data center Selector 7

iii
 4.2.1 Closest Data Center(CDC) 8

4.2.2 Optimise Response 9

Time(ORT)

4.3 VM selector and allocator 9

5. Implementation 11

6. Experimental Results and Discussions 17

6.1 Experimental Setup 18

6.1.1 Simulation Scenarios 20

6.2 Results 21

6.2.1 Processing Time 22

6.2.2 Response Time 28

6.2.3 Total Cost 35

6.2.4 Power and Energy 36

Consumption

6.2.5 Carbon Footprint 39

Reduction

7. Conclusion and Future work 41

8. References 42

9. Publications 46

10. Plagiarism Report 56

iv
 List of Tables
1. Facebook subscribers statistics as of June 30, 17
2017

2. User Configurations used in the experiments 18

3. DataCenter Parameter values used in the 19

experiments

4. Scenarios chosen for Simulation 20

5. Processing time of various algorithms for 22

CDC and ORT under S1:One data center with
25 VMs, located at region 0

6. Processing time of various algorithms for 24

CDC and ORT under S2:Two data centers
with 25 VMs each, located at region 0 and 2
respectively

7. Processing time of various algorithms for 25

CDC and ORT under S3:Two data centers
with 25,50 VMs, located at region 0 and 2
respectively

8. Processing time of various algorithms for 27

CDC and ORT under S4:Three data centers
with 25,30, 50 VMs, located at three different
regions 0, 2, and 1 respectively

v
9. Response time of various algorithms for CDC 29
and ORT under S1:One data center with 25
VMs, located at region 0

10. Response time of various algorithms for CDC 30

and ORT under S2:Two data centers with 25
VMs each, located at region 0 and 2
respectively

11. Response time of various algorithms for CDC 32

and ORT under S3: Two data centers with
25,50 VMs, located at region 0 and 2
respectively

12. Response time of various algorithms for 33

CDC and ORT under S4: Three data centers
with 25,30, 50 VMs, located at three
different regions 0, 2, and 1 respectively
13. Comparative Analysisof Total Cost 35

14. Comparative Analysis of Power Consumption 37

15. Comparative Analysis of Energy 38

Consumption

16. Comparative Analysis of Carbon Footprint 39

vi
 List of Figures
1. CACO load balancing model 8

2. CACO load balancing algorithm 10

3. Workspace Creation 11

4. Creating New java project 12

5. Execution of load balancing algorithm 13

6. UserBase configuration 13

7. Data center configuration 14

8. Advanced configuration 14

9. Internet configurations 15

10. Simulation under progress 15

11. Completion of Simulation 16

12. Screenshot of the result generated in 21

CloudAnalyst

13. Average Processing time of various 23

algorithms for CDC under S1:One data
center with 25 VMs, located at region 0

14. Average Processing time of various 23

algorithms for ORT under S1:One data
center with 25 VMs, located at region 0

15. Average Processing time of various 24

algorithms for CDC under S2:Two data
centers with 25 VMs each, located at region
0 and 2 respectively

vii
16. Average Processing time of various 25
algorithms for ORT under S2:Two data
centers with 25 VMs each, located at region
0 and 2 respectively

17. Average Processing time of various 26

algorithms for CDC under S3:Two data
centers with 25,50 VMs, located at region 0
and 2 respectively

18. Average Processing time of various 26

algorithms for ORT under S3:Two data
centers with 25,50 VMs, located at region 0
and 2 respectively

19. Average Processing time of various 27

algorithms for ORT under S4:Three data
centers with 25,30, 50 VMs, located at three
different regions 0, 2, and 1 respectively

20. Average Processing time of various 28

algorithms for ORT under S4:Three data
centers with 25,30, 50 VMs, located at three
different regions 0, 2, and 1 respectively

21. Average Response time of various 29

algorithms for CDC under S1:One data
center with 25 VMs, located at region 0

22. Average Response time of various 30

algorithms for ORT under S1:One data
center with 25 VMs, located at region 0

23. Average Response time of various 31

algorithms for CDC under S2:Two data
centers with 25 VMs each, located at region
0 and 2 respectively

viii
24. Average Response time of various 31
algorithms for ORT under S2:Two data
centers with 25 VMs each, located at region
0 and 2 respectively

25. Average Response time of various 32

algorithms for CDC under S3: Two data
centers with 25,50 VMs, located at region 0
and 2 respectively

26. Average Response time of various 33

algorithms for ORT under S3: Two data
centers with 25,50 VMs, located at region 0
and 2 respectively

27. Average Response time of various 34

algorithms for CDC S4: Three data centers
with 25,30, 50 VMs, located at three
different regions 0, 2, and 1 respectively

28. Average Response time of various 34

algorithms for ORT S4: Three data centers
with 25,30, 50 VMs, located at three
different regions 0, 2, and 1 respectively

29. Comparison of Total Cost($) under various 36

scenarios

30. Comparison of Power (kW) under various 37

scenarios

31. Comparison of Energy (kWh) under various 38

scenarios

32. Comparison of carbon footprint (tons) 40

various scenarios

ix
 List of Abbreviations
CPU Central Processing Unit

ACO Ant Colony Optimization

GHz Giga Hertz

XML Extensible Markup Language

VM Virtual Machine

CDC Closest Data Centre

ORT Optimise Response Time

DC Data Centre
CACO Cost-Aware Ant Colony Optimization

BW Bandwidth

GMT Greenwich Mean Time

MB Mega Byte

VMM Virtual Machine Monitor

GB Giga Byte

TB Tera Byte

RR Round Robin

ESCE Equally Spread Current Execution

LA Location Aware

HB Honeybee

ms milliseconds

kW KiloWatt

kWh KiloWatt-hour

x
CHAPTER 1

INTRODUCTION

Cloud Computing is a buzzing technology in today’s internet world. Cloud

enables flexible usage of data and resources. Cloud users can conveniently store
and access data anytime anywhere. Its ubiquitous nature has resulted in the
increasing number of users in this domain. As per National Institute of Standards
and Technology, “Cloud computing is a model for enabling ubiquitous,
convenient, on-demand network access to a shared pool of configurable computing
resources (e.g., networks, servers, storage, applications, and services) that can be
rapidly provisioned and released with minimal management effort or service
provider interaction(Mell & Grance, 2011).” Cloud eases the feature of data
sharing for the internet users. The availability and scalability feature of cloud has
resulted in avoiding the investments of larger capital costs for companies thereby
attracting the users in a large scale.

For the betterment of our environment, the idea of green computing has
emerged. Green computing is a technique of efficiently utilizing IT resources by
applying better policies and algorithms. One of the important key concepts of
green computing is virtualization (Jain & Choudhary, 2016,March). Virtualization
is generally referred as the abstraction of computing resources such as CPU,
memory, network, storage and database related applications and the clients
utilizing the service provisioned by the cloud providers (Kumar & Charu, 2015). It
enables multi-tenancy model by providing a scalable, shared resource platform for
all tenants (Xing & Zhan, 2012).

Besides the advantages of virtualization in cloud computing, one of the

environmental issues is increase in carbon footprint. Carbon footprint is the

1
amount of carbon dioxide emission in the environment. In context of cloud, this
issue is faced due to inefficient usage of data center. The data center’s efficiency
can be increased by applying appropriate load balancing algorithms. By balancing
the workload across all the nodes of a cloud, overheating is reduced which in turn
reduces the energy consumption (Uddin, Darabidarabkhani, Shah, & Memon). As
the energy consumption increases, carbon footprint increases. Therefore, by
reducing the energy consumption, the aim of green computing is achieved (Thakur
& Chaurasia, 2016,January).

In this paper, ACO based carbon aware load balancing model is proposed for
improving the allocation of tasks to the virtual machines. This model also provides
the comparison with various load balancing algorithms. The objective of the
proposed work is 1)To reduce the processing time 2)To lessen the response time
3)To lower the cost 4)To bring down the power consumption 5)To minimize the
carbon footprint .The load balancing algorithms are analyzed under different
service broker policies in order to provide better performance analysis.

This paper is organized as follows: Chapter 2 shows some of the existing

load balancing algorithms, Chapter 3 lists the hardware and software requirements,
Chapter 4 discusses the proposed ACO based carbon aware load balancing model
and its overall design, Chapter 5 deals with the real time
implementation,Chapter6depicts the experimental results and discussions and
results and Chapter7 presents the conclusion.

2
CHAPTER 2

LITERATURE SURVEY

(Naqvi, Javaid, Butt, Kamal, Hamza, & Kashif, 2018) has proposed a bio-
inspired algorithm called Ant Colony optimization for load balancing. The ant
colony optimization algorithm is the swarm based genetic algorithm. It works on
the mechanism of real ants using pheromones in order to explore its path. In the
same way, the allocation path of the cloudlets is identified based on the minimal
path cost in a probabilistic manner.

(Meftah, Youssef, & Zakariah, 2018) aims to illustrate the how the load
balancing algorithms which are defaultly available in the cloud analyst tool work
under various service broker policies .It is inferred that throttled is better than
Round Robin and equally spread by analysing performance parameters sucha as
average processing time and average response time with respect to different
scenarios.

(Subalakshmi & Malarvizhi, 2017) has suggested the algorithm called

Equally Spread current execution load Algorithm. The Equally Spread current
execution load algorithm balances the load across the virtual machines. It
maintains the index table that contains the number of requests and currently
allocated virtual machines. When a new request arises, the least loaded virtual
machine is identified by referring to the index table. If there is more than one least
loaded virtual machine, then the first identified virtual machine is chosen.

3
 (Rong, Zhang, Xiao, Li, & Hu, 2016) focuses on technologies for energy
conservation in data center environment.The energy measure is calculated bases on
power usage effectiveness which is ratio of facility load to IT load.This paper
analyses the energy consumption under different scenarious for various time
periods.

(Kushwaha & Gupta, 2015)has proposed the algorithm called Round-robin

load balancing algorithm. The Round-robin load balancing algorithm uses the time
quantum for the allocation of virtual machines. The first virtual machine is selected
randomly and then further allocations are made in a circular manner based on the
time quantum. The major drawback of this algorithm is that the task is made to
wait for a long time in the queue if the virtual machine is not available thereby
increasing the execution time.

(Patel & Patel, 2015) has implemented and compared the service broker
policies in cloud analyst which is built over cloudsim in both static and dynamic
approaches. The paper concludes that proposal of broker policy is based on cost
and performance which includes Processing time and Response time.

(Kashyap, 2014)Suggested the genetic algorithm called Honey bee load

balancing algorithm. The Honey bee algorithm is the bio-inspired algorithm based
on the behaviour of the honey bee. It keeps tracking the workload of each virtual
machine. The task from the overloaded virtual machine is removed and is given
higher priority so that it can be assigned to the next lightly loaded machines.

(Kishor, 2014)has proposed a new service broker policy. The main role of
any service broker policy is to select a data center for processing a request within a
region. The algorithm is designed in such a way that it selects a data center based
4
on the underlying infrastructure. Based on the number of computing elements
available and the resource handling capacity of the data centres, proportion weight
is assigned to each data centres. The data centre with the greatest proportion
weight will be selected for processing the user requests.

(Nitika, 2012) has implemented the algorithm called throttled load

balancing algorithm. The throttled algorithm maintains the index table that
contains the virtual machine and its state. When a new request arises, it checks for
the availability of the virtual machine by referring the index table. If all the virtual
machines are active, then the requests are queued until the virtual machine
becomes available.

The proposedload balancing model is done with the FaceBookdataset

available from (internetworldstats, 2018)and energy-aware simulator CloudAnalyst
(Zhao, Peng, Xie, & Dai, 2012, November). The CloudAnalyst is an extension of
CloudSim toolkit with an additional Graphical User Interface which allows the
user to configure the cloud environment in detail and also enables the user to
experiment with the large scale cloud environment easily. (Wickremasinghe &
Buyya, 2009).

5
CHAPTER 3
REQUIREMENTS
Hardware Support

This project has the fallowing minimum hardware requirement

Processors : Intel(R) Core(TM)

Architecture : i5

CPU Speed : 2.30 – 2.40 GHz

Installed RAM : 4.00 GB

System type : X64-based processor

Software requirements

The software requirements of the project are :

Operating System : Windows 10 pro

Version : 1607

Tools : (i) Eclipse 3.7.0 and above

(ii) CloudAnalyst

Technologies used

Technologies used for this project are :

 Java
 XML
6
CHAPTER 4
PROPOSED METHOD

The ACO based carbon aware model identifies a solution for efficient load
balancing by considering factors such as processing time, response time to reduce
carbon footprint in the cloud computing environment. The Proposed algorithm is
based on genetic algorithm Ant colony optimization which uses path cost and
threshold. The major components are 1) User Base2) Data centreselector 3) VM
selector and allocator 4) Efficiency analyzer.

UserBase

The User base is a collection of users grouped under a region. The chosen
configuration includes 6 regions across the world (Limbani, 2012). A Single-user
base may consist of thousands of users and each user, in turn, may request for
thousands of tasks. The user bases generate traffic as in real time. The increasing
number of users determines the efficiency of the simulation. The number of
simultaneous users in each user base can be bundledasa single unit by grouping
factor.

Data center selector

The data center Selector maps the data center with the traffic generating user base
depending on the service broker policy. The service broker policies are Closest
Data Center(CDC) and Optimise Response Time(ORT).

7
 Closest Data Center (CDC)

The user bases are routed to the data center which has the minimum network
latency irrespective of network bandwidth (Patel & Patel, 2015).If there are two
data centers under the same region proximity one of them are randomly chosen.
This policy calls the data center selector to identify the closest data center. This
default broker policy is advantageous in case of the requests arebeing processed by
the data center within the same location.

Fig. 1.CACO load balancing model

8
 Optimise Response Time (ORT)

This service broker policy uses the same methodology as the closest data center
policy to select the data center as per the network latency (Kishor, 2014). In
addition, it calculates the current response time and checks whether the estimated
response time is the same as that of the closest data center. Otherwise, the data
center with the least response time or that within the closest proximity is chosen
evenly with the occurrence ratio of 50:50.

VM selector and allocator

VM selector and allocator use the VM load balancer to allocate the cloudlets (user
requested tasks) to the Virtual Machine. The existing load balancing policies in
cloud analyst are Round-Robin, Equally Spread current execution load, Throttled,
Honey bee, Ant colony optimization.

Cost-aware ACO Based model for Load Balancing

The proposed CACO algorithm uses the approach of swarm-based Ant colony
optimization algorithm. Ants deposit a type of biochemical substance known as a
pheromone in order to explore its path. Similarly, ants are considered as cloudlets.
Each cloudlet maintains the pheromones table in which path cost is updated.
Initially, each cloudletchoosesthe virtual machine randomly. The next available
virtual machine is identified based on the score function and workload. After
completing its tour, update the pheromones table. If all the cloudlets completed
their trips then calculate the makespan of the cloudlets and retain the optimal
solution. If it reaches the maximum limit of iteration then stops the iteration and
yield the best solution.

9
CACO Load Balancing Algorithm
Input:List of ants and VM’s

Output:Allocation of ants to the VM’s

Steps:

Initialize VM’s state and count

Initialize Pheromones table

Set the upper and lower threshold values

Initialize under Loaded and Over Loaded queues

Get next AvailableVM() {

Position each ant in a virtual machine randomly

While (every ant has not build a solution) do

For each ant do

Choose VM for next task by:

Min (Path cost+ ((Max BW-current BW)/Max BW) +

VM cost+ Memory Cost)

If chosen VM is overloaded then choose the VM from the

underloaded Queue

Update the count of ants assigned to the chosen VM

Initialize under Loaded and Over Loaded queues

End for

End while

Update the pheromone

Fig. 2.CACOload balancing algorithm

10
CHAPTER 5

IMPLEMENTATION

In our project, we have used Eclipse editor for implementing the proposed
algorithm and integrated CloudAnalyst with Eclipse for running the simulation.The
detailed description of our work is explained below:

Fig. 3. Workspace Creation

11
Fig. 4. Creating New java project

12
Fig. 5. Execution of load balancing algorithm

Fig. 6. UserBase configuration

13
Fig. 7. Data center configuration

Fig. 8. Advanced configuration

14
 Fig. 9. Internet configurations

Fig. 10. Simulation under progress

15
Fig. 11. Completion of Simulation

16
CHAPTER 6

EXPERIMENTAL RESULTS AND DISCUSSIONS

The purpose of our model is to reduce the carbon footprint by efficiently allocating
the tasks to the virtual machines by using different service broker policies. Social
networking media connect people across the world in the online platform .It is one
of the largest internet applications that can be satisfied via cloud
computing.Facebook is one such social media application with a large population
of users. As of 30 June 2017, Facebookhas 1.97 million users across various
geographic locations as shown in Table I . In our experimental model, we have
used CloudAnalyst tool for the simulation to analyze the characteristics of
Facebook application in the cloud environment.

Table 1. Facebook subscribers statistics as of June 30, 2017 (internetworldstats, 2018)

World Regions Facebook 30 June 2017

Africa 160,207,000
Asia 736,003,000
Europe 343,273,740
Latin America/Caribbean 370,975,340
Middle East 86,700,000
North America 263,081,200
Oceania/Australia 19,463,250
World Total 1,979,703,530

17
 Experimental setup

We have chosen six user bases to indicate the various geographic locations as
shown in Table 2. For the ease of simulation, we have chosen 1/10 th of Facebook’s
population. The peak utilization time is assumed to be at night for about 2 hours
which is considered as the time zone. It is also assumed that 1% of users are using
the platform simultaneously during the peak hours and a single tenth of them are
using the platform simultaneously during the off-peak hours. The CloudAnalyst
tool enables various parameters as input as mentioned in Table 3.

Table 2. User Configurations used in the experiments

Simultaneous Simultaneous
Peak
Online Users Online Users
User Base Region Hours
During Peak During Off-
(GMT)
Hours peak Hours
13:00–
N. America 0 2630812 263081
15:00
15:00–
S. America 1 3709753 370975
17:00
20:00–
Europe 2 3432737 343273
22:00
01:00–
Asia 3 7360030 736003
03:00
21:00–
Africa 4 1602070 160207
23:00
09:00–
Oceania/Australia 5 194632 19463
11:00

18
 Table 3.DataCenter Parameter values used in the experiments

Parameters Values assigned

Number of VMs Based on the Scenario
Image size 10,000
Virtual Machine (VM) Memory 512 MB
Bandwidth 1000 MB
Region Based on the scenario
Architecture x86
Operating system Linux
Virtual Machine Monitor
Xen
(VMM)
Memory per machine 4 GB
Data center
Storage per machine 100 TB
Available bandwidth per
1000000 MB
machine
Number of processors 4
Processor Speed 10000 MB
VM Policy Time shared
User grouping factor in user bases 10000
Request grouping factor in data centers 1000
Executable instruction length 250

19
 Simulation Scenarios

We have used CloudAnalystsimulation tool to analyze the performance of the

Facebook application in cloud environment under two service broker policies
1)Closest Data Centre(CDC) and 2)Optimize Response Time(ORT) for six load
balancing algorithms including ACO based carbon aware algorithm under different
scenarios as mentioned in Table 4.

Table 4. Scenarios chosen for Simulation (Meftah, Youssef, & Zakariah, 2018)

Scenario ID Scenario Configurations

S1 One data center with 25 VMs, located at region 0
Two data centers with 25 VMs each, located at region 0 and
S2
2 respectively
Two data centers with 25,50 VMs, located at region 0 and
S3
2 respectively.
Three data centers with 25,30, 50 VMs, located at three
S4
different regions 0, 2, and 1 respectively

In Scenario S1, simulation is executed with single data center with 25 VMs located
in region 0.In the second scenario S2, two data centersare chosen with same count
of VMs at different locations. In third scenario S3, twodata centers are chosen with
variable count of VMs at different geographical locations. In fourth scenario, three
data centers with variable count of VMs are chosen at different geographical
locations across the globe. The chosen algorithms along with the proposed one are
simulated in all the four scenarios and their respective behaviours are analyzed.

20
 Results

The Min, Max, and overall average values of processing time and response time
arerecorded for each scenario during the simulation for about 60 hours as shown in
Table 5 to Table 8 and Table 9 to Table 10 respectively. The existing algorithms
such as Round Robin (RR), Equally Spread Current Execution Load (ESCE),
Location Aware (LA), Honeybee (HB), Ant Colony (ACO) and the proposed
CACO Algorithm are taken into consideration for analysis. The results are
recorded for the factors including processing time, response time, total cost and
power consumed and are tabulated in Table 5 to Table 8, Table 9 to table 12, Table
13 and Table 14respectively. A sample screenshot of the result generated is shown
in Fig. 12.

Fig. 12. Screenshot of the result generated in CloudAnalyst

21
 Processing Time

Processingtimeis calculated based on the length of the tasks requested by users and
the capacity of the virtual machines which are assigned to handle the respective
tasks (Rehman, Javaid, Ali, Saif, Ashraf, & Abbasi, 2018,October). The processing
time resulted from the algorithms are represented in milliseconds (ms). The
processing time for various algorithms under CDC and ORT service broker
policies for S1, S2, S3 and S4 are tabulated in Table 5,Table 6, Table 7 and Table 8
respectively and are graphically represented in Fig. 13 to Fig. 20.

Table 5. Processing time of various algorithms for CDC and ORT under S1:One data center with
25 VMs, located at region 0

Service broker Load balancing Processing Time(ms)

policy algorithms Min Max Avg
RR 0.84 21806.17 3665.93
ESCE 0.85 22002.57 3761.71
Closest
LA 1.13 18433.90 1907.22
Data
HB 0.74 22045.58 3865.17
Center(CDC)
ACO 0.59 12315.32 1472.31
CACO 0.44 12041.89 1467.47
RR 0.74 21921.68 3665.43
ESCE 0.74 22052.77 3761.66
Optimize
LA 0.87 18622.17 1907.24
Response
HB 0.63 22084.75 3862.56
Time(ORT)
ACO 0.61 13753.35 1478.39
CACO 0.65 11757.60 1464.39

22
 S1-CDC
4500

4000

3500
Processing Time(ms)

3000

2500

2000

1500

1000

500

0
RR ESCE LA HB ACO CACO

Fig. 13. Average Processing time of various algorithms for CDC under S1:One data center with
25 VMs, located at region 0

S1-ORT
4500

4000

3500
Processing Time(ms)

3000

2500

2000

1500

1000

500

0
RR ESCE LA HB ACO CACO

Fig. 14. Average Processing time of various algorithms for ORT under S1:One data center with
25 VMs, located at region 0

23
 Table 6. Processing time of various algorithms for CDC and ORT under S2:Two data centers
with 25 VMs each, located at region 0 and 2 respectively

Service broker Load balancing Processing Time(ms)

policy algorithms Min Max Avg
RR 0.95 21827.41 3747.73
ESCE 0.95 21998.47 3827.53
Closest
LA 1.13 18442.04 1939.80
Data
HB 0.94 22045.41 3917.16
Center(CDC)
ACO 0.30 12542.06 1551.65
CACO 0.11 12220.72 1536.39
RR 0.42 20394.68 3021.56
ESCE 0.57 20583.83 2995.13
Optimize
LA 1.18 17404.51 1533.97
Response
HB 0.47 22060.21 3238.77
Time(ORT)
ACO 0.36 11961.45 1199.31
CACO 0.42 10886.67 1204.37

S2-CDC
4500
4000
3500
Processing Time(ms)

3000
2500
2000
1500
1000
500
0
RR ESCE LA HB ACO CACO

Fig. 15. Average Processing time of various algorithms for CDC under S2:Two data centers with
25 VMs each, located at region 0 and 2 respectively

24
 S2-ORT
3500

3000
Processing Time(ms)

2500

2000

1500

1000

500

0
RR ESCE LA HB ACO CACO

Fig. 16. Average Processing time of various algorithms for ORT under S2:Two data centers with
25 VMs each, located at region 0 and 2 respectively

Table 7. Processing time of various algorithms for CDC and ORT under S3:Two data centers
with 25,50 VMs, located at region 0 and 2 respectively

Service broker Load balancing Processing Time(ms)

policy algorithms Min Max Avg
RR 0.95 21827.41 3747.56
ESCE 0.95 21998.47 3827.38
Closest
LA 1.13 18442.04 1939.82
Data
HB 0.94 22045.41 3917.24
Center(CDC)
ACO 0.46 6462.12 1005.82
CACO 0.40 6073.58 1013.01
RR 0.32 20590.02 3025.23
ESCE 0.43 20583.83 2982.01
Optimize
LA 1.18 26519.36 2659.75
Response
HB 0.36 21335.74 3153.68
Time(ORT)
ACO 0.30 6534.64 838.33
CACO 0.32 6268.55 834.18

25
 S3-CDC
4500

4000

3500
Processing Time(ms)

3000

2500

2000

1500

1000

500

0
RR ESCE LA HB ACO CACO

Fig. 17. Average Processing time of various algorithms for CDC under S3:Two data centers with
25,50 VMs, located at region 0 and 2 respectively

S3-ORT
3500

3000

2500
Processing Time(ms)

2000

1500

1000

500

0
RR ESCE LA HB ACO CACO

Fig. 18. Average Processing time of various algorithms for ORT under S3:Two data centers with
25,50 VMs, located at region 0 and 2 respectively

26
Table 8. Processing time of various algorithms for CDC and ORT under S4:Three data centers
with 25,30, 50 VMs, located at three different regions 0, 2, and 1 respectively

Service broker Load balancing Processing Time(ms)

policy algorithms Min Max Avg
RR 0.95 21827.41 3646.30
ESCE 0.95 21998.47 3737.48
Closest
LA 1.13 18442.04 1894.75
Data
HB 0.94 22045.41 3832.11
Center(CDC)
ACO 0.34 10591.74 1076.16
CACO 0.34 9604.01 1099.48
RR 0.31 21863.07 2555.43
ESCE 0.56 20549.64 2642.84
Optimize
LA 0.56 17255.84 1274.77
Response
HB 0.61 20791.62 2762.32
Time(ORT)
ACO 0.25 9599.71 713.79
CACO 0.12 9143.17 770.70

S4-CDC
4500
4000
3500
Processing Time(ms)

3000
2500
2000
1500
1000
500
0
RR ESCE LA HB ACO CACO

Fig. 19. Average Processing time of various algorithms for ORT under S4:Three data centers
with 25,30, 50 VMs, located at three different regions 0, 2, and 1 respectively

27
 S4-ORT
3000

2500
Processing Time(ms)

2000

1500

1000

500

0
RR ESCE LA HB ACO CACO

Fig. 20. Average Processing time of various algorithms for ORT under S4:Three data centers
with 25,30, 50 VMs, located at three different regions 0, 2, and 1 respectively

Response Time

Response time is the time taken by the data center to receive requests from the user
base. The response time resulted from the algorithms are represented in
milliseconds(ms).The response time for various algorithms under CDC and ORT
service broker policies for S1, S2, S3 and S4 are tabulated in Table 9 to Table 13
respectively and are graphically respresented in Fig. 21 to Fig. 28.

28
Table 9. Response time of various algorithms for CDC and ORT under S1:One data center with
25 VMs, located at region 0

Service broker Load balancing Response Time(ms)

policy algorithms Min Max Avg
RR 187.41 28802.40 4958.24
ESCE 187.41 29078.84 5058.76
Closest
LA 148.86 28547.56 3443.52
Data
HB 190.03 29126.29 5151.42
Center(CDC)
ACO 152.56 18386.79 2999.04
CACO 145.60 18446.03 2993.72
RR 181.46 28657.20 4957.53
ESCE 181.46 29597.80 5059.27
Optimize
LA 141.28 28571.93 3444.01
Response
HB 181.46 29505.49 5149.31
Time(ORT)
ACO 150.30 19664.18 2999.79
CACO 152.27 18390.22 2992.78

S1-CDC
6000

5000
Response Time(ms)

4000

3000

2000

1000

0
RR ESCE LA HB ACO CACO

Fig. 21. Average Response time of various algorithms for CDC under S1:One data center with
25 VMs, located at region 0

29
 S1-ORT
6000

5000
Response Time(ms)

4000

3000

2000

1000

0
RR ESCE LA HB ACO CACO

Fig. 22. Average Response time of various algorithms for ORT under S1:One data center with 25
VMs, located at region 0

Table 10. Response time of various algorithms for CDC and ORT under S2:Two data centers
with 25 VMs each, located at region 0 and 2 respectively

Service broker Load balancing Response Time(ms)

policy algorithms Min Max Avg
RR 182.76 28341.49 4812.20
ESCE 182.76 28863.58 4897.30
Closest
LA 139.36 28351.87 3231.50
Data
HB 182.76 28974.32 4978.48
Center(CDC)
ACO 150.35 18613.98 2821.73
CACO 144.46 18412.41 2816.04
RR 102.62 26672.75 3989.20
ESCE 109.88 27152.84 3954.76
Optimize
LA 99.60 26512.16 2668.63
Response
HB 107.57 28813.53 4214.67
Time(ORT)
ACO 105.52 17484.57 2351.26
CACO 95.62 17264.21 2355.61

30
 S2-CDC
6000

5000
Response Time(ms)

4000

3000

2000

1000

0
RR ESCE LA HB ACO CACO

Fig. 23. Average Response time of various algorithms for CDC under S2:Two data centers with
25 VMs each, located at region 0 and 2 respectively

S2-ORT
4500
4000

3500
Response Time(ms)

3000

2500
2000
1500

1000

500

0
RR ESCE LA HB ACO CACO

Fig. 24. Average Response time of various algorithms for ORT under S2:Two data centers with
25 VMs each, located at region 0 and 2 respectively

31
 Table 11. Response time of various algorithms for CDC and ORT under S3: Two data centers
with 25,50 VMs, located at region 0 and 2 respectively

Service broker Load balancing Response Time(ms)

policy algorithms Min Max Avg
RR 182.76 28341.49 4812.08
ESCE 182.76 28863.58 4897.09
Closest
LA 139.36 28351.87 3231.53
Data
HB 182.76 28974.32 4978.48
Center(CDC)
ACO 139.28 19543.43 2558.67
CACO 143.33 19485.51 2562.36
RR 121.42 26672.75 3995.93
ESCE 14.96 27152.84 3938.21
Optimize
LA 100.23 26519.36 2659.75
Response
HB 114.43 27605.41 4123.56
Time(ORT)
ACO 107.71 19019.52 2272.13
CACO 104.02 19241.94 2331.38

S3-CDC
6000

5000
Response Time(ms)

4000

3000

2000

1000

0
RR ESCE LA HB ACO CACO

Fig. 25. Average Response time of various algorithms for CDC under S3: Two data centers with
25,50 VMs, located at region 0 and 2 respectively

32
 S3-ORT
4500
4000
3500
Response Time(ms)

3000
2500
2000
1500
1000
500
0
RR ESCE LA HB ACO CACO

Fig. 26. Average Response time of various algorithms for ORT under S3: Two data centers with
25,50 VMs, located at region 0 and 2 respectively

Table 12. Response time of various algorithms for CDC and ORT under S4: Three data centers
with 25,30, 50 VMs, located at three different regions 0, 2, and 1 respectively

Service broker Load balancing Response Time(ms)

policy algorithms Min Max Avg
RR 182.76 28341.49 4723.75
ESCE 182.76 28863.58 4819.42
Closest
LA 139.36 28351.87 3235.45
Data
HB 182.76 28974.32 4902.15
Center(CDC)
ACO 144.56 16244.45 2648.50
CACO 140.71 15908.06 2653.38
RR 100.96 28444.23 3451.17
ESCE 88.33 27170.47 3542.93
Optimize
LA 103.06 26514.46 2280.09
Response
HB 101.76 27061.56 3656.81
Time(ORT)
ACO 104.87 15564.01 2183.32
CACO 107.04 15749.67 2241.60

33
 S4-CDC
6000

5000
Response Time(ms)

4000

3000

2000

1000

0
RR ESCE LA HB ACO CACO

Fig. 27. Average Response time of various algorithms for CDC S4: Three data centers with
25,30, 50 VMs, located at three different regions 0, 2, and 1 respectively

S4-ORT
4000

3500

3000
Response Time(ms)

2500

2000

1500

1000

500

0
RR ESCE LA HB ACO CACO

Fig. 28. Average Response time of various algorithms for ORT S4: Three data centers with
25,30, 50 VMs, located at three different regions 0, 2, and 1 respectively

34
From Table 5 to Table 12, we can infer that the proposed CACO Algorithm gives
better results in terms of processing time and response time when compared to
other existing algorithms other than ACO. A quick look-over to the resultsrevealed
that, in general, the proposed CACO load balancing algorithmoutperforms the
other existing algorithms including ACO in scenario1 and scenario 2 with the CDC
servicebroker policy as the overall processing time and the overall response time
iscomparatively better.

Total Cost

One of the most important parameters of cloud computing is cost. The total cost
includes virtual machine migration cost and data transfer cost. During the
simulation, the algorithms such as Round Robin, Equally Spread Current
Execution Load, Location Aware, and Honeybee give the same results for Total
cost as the cost is not included as a factor in these algorithms. The total cost of the
algorithms is represented in dollars ($). Hence these algorithms are altogether
referred to as “Others” in Table 13, Table 14, Table 15 and Table 16.

Table 13.Comparative Analysisof Total Cost

Load balancing Total Cost ($)

Service broker policy
algorithms S1 S2 S3 S4

ACO 76303.30 76507.53 51254.80 57545.02

Closest Data
CACO 76288.00 76436.58 51318.66 57489.16
Center(CDC)
Others 119274.92 119370.97 119370.97 119467.02

ACO 76362.44 76424.50 52615.82 58213.03

Optimise Response
CACO 76281.93 76475.46 52399.65 58583.57
Time(ORT)
Others 119274.92 119370.97 119370.97 119467.02

35
 140000

120000

100000

80000
Total Cost ($) S1
Total Cost ($) S2
60000
Total Cost ($) S3
Total Cost ($) S4
40000

20000

0
ACO CACO Others ACO CACO Others
Closest Data Center(CDC) Optimise Response Time(ORT)

Fig. 29.Comparison of Total Cost($) under various scenarios

Power And Energy Consumption

Power is the rate at which the user requests are satisfied by the data center. Thus,
power consumption includes the total power consumed by all the data centers
under various scenarios for different algorithms mentioned in Table 14. Power is
represented in KiloWatt(kW). The graphical representation of Power consumption
is mentioned in Fig. 30.

36
 Table 14 .ComparativeAnalysis ofPower Consumption

Load Power (kW)

Service broker
balancing
policy S1 S2 S3 S4
algorithms
ACO 10597.68 10626.04 7118.72 7992.36
Closest Data
CACO 10595.55 10616.19 7127.59 7984.61
Center(CDC)
Others 16565.96 16579.30 16579.30 16592.64
Optimise ACO 10605.89 10614.51 7307.75 8085.14
Response CACO 10594.71 10621.59 7277.73 8136.61
Time(ORT) Others 16565.96 16579.30 16579.30 16592.64

18000

16000

14000

12000

10000 Power (kW) S1

Power (kW) S2
8000
Power (kW) S3
6000
Power (kW) S4
4000

2000

0
ACO CACO Others ACO CACO Others
Closest Data Center(CDC) Optimise Response Time(ORT)

Fig. 30.Comparison of Power (kW) under various scenarios

37
Datacenter consumes a large amount of energy because of its high-performance
components. Energy is one of the beneficiary factors in the management of
datacenters in the cloud (Rong, Zhang, Xiao, Li, & Hu, 2016).Energy is
represented in Kilowatt-hour (kWh) for the chosen scenarios represented in Table
15. The graphical representation of energy consumption is mentioned in Fig. 31.

Table 15 .Comparative Analysis of Energy Consumption

Service broker Load balancing Energy(kWh)

policy algorithms S1 S2 S3 S4
ACO 635860.8 637562.4 427123.2 479541.6
Closest Data
CACO 635733 636971.4 427655.4 479076.6
Center(CDC)
Others 993957.6 994758 994758 995558.4
Optimise ACO 636353.4 636870.6 438465 485108.4
Response CACO 635682.6 637295.4 436663.8 488196.6
Time(ORT) Others 993957.6 994758 994758 995558.4

1200000

1000000

800000
Energy(kWh) S1
600000
Energy(kWh) S2

400000 Energy(kWh) S3
Energy(kWh) S4
200000

0
ACO CACO Others ACO CACO Others
Closest Data Center(CDC) Optimise Response Time(ORT)

Fig. 31.Comparison of Energy (kWh) under various scenarios

38
 Carbon Footprint Reduction

Data center carbon footprint is the amount of carbon released into the atmosphere.
By considering the social welfare into account, the CACO model has aimed at
reducing the carbon footprint in the cloud environment. Reduction of power usage
greatlycontributes to reducing the carbon footprint (Khosravi & Buyya, 2018). It is
assumed that 1000kWh of power consumption emits 0.72 tons of CO2 (Uddin,
Darabidarabkhani, Shah, & Memon).The carbon footprint analysis is represented
in Table 16 an the corresponding graphical respresentation is shown in Fig. 32.

Table 16 .Comparative Analysis of Carbon Footprint

Load Carbon Footprint(tons)

Service broker
balancing
policy S1 S2 S3 S4
algorithms
ACO 457.8198 459.0449 307.5287 345.27
Closest Data
CACO 457.7278 458.6194 307.9119 344.9352
Centre(CDC)
Others 715.6495 716.2258 716.2258 716.802
Optimise ACO 458.1744 458.5468 315.6948 349.278
Response CACO 457.6915 458.8527 314.3979 351.5016
Time(ORT) Others 715.6495 716.2258 716.2258 716.802

39
 800

700

600

500
Carbon Footprint(tons) S1
400
Carbon Footprint(tons) S2

300 Carbon Footprint(tons) S3

Carbon Footprint(tons) S4
200

100

0
ACO CACO Others ACO CACO Others
Closest Data Center(CDC) Optimise Response Time(ORT)

Fig. 32.Comparison of carbon footprint (tons) various scenarios

The proposed Cost-aware ACO based load balancing model has been compared
withother load balancing algorithms. The main focusof our work is to reduce the
carbon footprint in cloud data center. In most of the scenarios, under both service
broker policies, our proposed CACO model gives better results in terms of cost,
power, energy and carbon footprint. Thus by managing the carbon footprint
efficiently, our model contributes to the betterment and welfare of the
environment.

40
CHAPTER 7

CONCLUSION AND FUTURE WORK

In this paper, we have analyzed the effects of various load balancing algorithms
and service broker policies under different scenarios in a large scale cloud
environment. The existing algorithms namely, Round Robin, Equally Spread
Current Execution Load, Location Aware and Honeybee and Ant Colony
algorithms and the service broker policies such as closest data center and optimise
response time are taken into consideration in order to analyze the performance of
the proposed work. In order to accomplish our work, we have chosen
CloudAnalyst simulation tool andFaceBook dataset for configuration. The results
are tabulated and it clearly revealed that the proposed CACO Algorithm performs
better in scenario 1 and scenario 2 with the CDC service broker policy. As power
consumption increases, carbon footprint also increases. Therefore, by reducing the
power consumption we can reduce the carbon footprint which greatly benefits the
environment. Future work concentrates on finding more procedures to reduce the
power consumption and also focus onthe power supply fordata centers by
renewable energy sources.

41
CHAPTER 8

REFERENCES

1. internetworldstats. (2018, August 26). Retrieved February 22, 2019,

fromhttps://www.internetworldstats.com/stats.htm

2. Jain, N., & Choudhary, S. (2016,March). Overview of virtualization in cloud

computing. In 2016 Symposium on Colossal Data Analysis and Networking
(CDAN) (pp. 1-4). IEEE.

3. Kashyap, D. &. (2014). A survey of various load balancing algorithms in

cloud computing. Int. J. Sci. Technol. Res , 3(11), 115-19.

4. Khosravi, A., & Buyya, R. (2018). Energy and carbon footprint-aware

management of geo-distributed cloud data centers: A taxonomy, state of the
art, and future directions. In Sustainable Development: Concepts,
Methodologies, Tools, and Applications. (pp. 1456-1475). IGI Global.

5. Kishor, K. &. (2014). An efficient service broker policy for Cloud

computing environment. International Journal of Computer Science Trends
and Technology (IJCST) , 2(4).

6. Kumar, R., & Charu, S. (2015). An importance of using virtualization

technology in cloud computing. Global Journal of Computers & Technology
, 1(2).

7. Kushwaha, M., & Gupta, S. (2015). Response Time Reduction and

Performance Analysis of Load Balancing Algorithms at Peak Hours in
Cloud Computing. International Journal of Computer Applications ,
128(17).

42
8. Limbani, D. &. (2012). A proposed service broker policy for data center
selection in cloud environment with implementation. International Journal
of Computer Technology & Applications , 3(3), 1082-1087.

9. Meftah, A., Youssef, A. E., & Zakariah, M. (2018). Effect of Service Broker
Policies and Load Balancing Algorithms on the Performance of Large Scale
Internet Applications in Cloud Data centers. INTERNATIONAL JOURNAL
OF ADVANCED COMPUTER SCIENCE AND APPLICATIONS , 9(5), 219-
227.

10. Mell, P., & Grance, T. (2011). The NIST definition of cloud computing.

11. Mishra, R. &. (2012). Ant colony optimization: A solution of load balancing
in cloud. International Journal of Web & Semantic Technology , 3(2), 33.

12. Naqvi, S. A., Javaid, N., Butt, H., Kamal, M. B., Hamza, A., & Kashif, M.
(2018). Metaheuristic optimization technique for load balancing in cloud-fog
environment integrated with smart grid. International Conference on
Network-Based Information Systems (pp. 700-711). Cham: Springer.

13. Nitika, M. S. (2012). Comparative analysis of load balancing algorithms in

cloud computing. International Journal of Advanced Research in Computer
Engineering & Technology , 1(3), 120-124.

14. Patel, H., & Patel, R. (2015). Cloud analyst: an insight of service broker
policy. International Journal of Advanced Research in Computer and
Communication Engineering , 4(1), 122-127.

43
15. Rehman, M., Javaid, N., Ali, M. J., Saif, T., Ashraf, M. H., & Abbasi, S. H.
(2018,October). Threshold based load balancer for efficient resource
utilization of smart grid using cloud computing. In International Conference
on P2P, Parallel, Grid, Cloud and Internet Computing (pp. 167-179).
Cham: Springer.

16. Rong, H., Zhang, H., Xiao, S., Li, C., & Hu, C. (2016). Optimizing energy
consumption for data centers. Renewable and Sustainable Energy Reviews ,
58, 674-691.

17. Subalakshmi, S., & Malarvizhi, N. (2017). Enhanced hybrid approach for
load balancing algorithms in cloud computing. Int. J. Sci. Res. Comput. Sci.,
Eng. Inf. Technol. IJSRCSEIT , 2(2).

18. Thakur, S., & Chaurasia, A. (2016,January). Towards Green Cloud

Computing: Impact of carbon footprint on environment. 6th International
Conference-Cloud System and Big Data Engineering(Confluence) (pp. 209-
213). IEEE.

19. Uddin, M., Darabidarabkhani, Y., Shah, A., & Memon, J. Evaluating power
efficient algorithms for efficiency and carbon emissions in cloud data
centers: A review. . In Renewable and Sustainable Energy Reviews (pp. 51,
1553-1563).

20. Wickremasinghe, B., & Buyya, R. (2009). CloudAnalyst: A CloudSim-

based tool for modelling and analysis of large scale cloud computing
environments. MEDC project report , 22(6), 433-659.

44
21. Xing, Y., & Zhan, Y. (2012). Virtualization and cloud computing. In In
Future Wireless Networks and Information Systems (pp. 305-312). Springer,
Berlin, Heidelberg.

22. Zhao, W., Peng, Y., Xie, F., & Dai, Z. (2012, November). Modeling and
simulation of cloud computing: A review. In 2012 IEEE Asia Pacific cloud
computing congress (APCloudCC) (pp. 20-24). IEEE.

45
CHAPTER 9

PUBLICATIONS

46
47
48
 Enhancing Test Suites through analysis of Code
Coverage and Mutation Testing
S. Ajitha#1, A. Aparna#2, K. Keerthanaa#3
#
Computer Science and Engineering,
Thiagarajar College of Engineering,
Madurai 625015, Tamil Nadu, India
1
ajithasundarjee@gmai
l.com
2
aparnaarunpandi@gmai
l.com
3
keerthanaakalyan@gma
il.com

Abstract— Code Coverage and Mutation testing is an important White box Testing
aspect of Software testing. Code Coverage helps to explore the
areas which are not covered by the test cases while mutation White box testing is also known as structural or glass box
testing explores the robustness of the test cases. Automated tools testing is a testing technique that considers the internal
help us to enhance coverage, stability, testability, and mechanism of a system. White box testing is mostly used for
maintainability. The choice of choosing the appropriate testing verification.
tool is still a challenge for developers. This paper aims to
provide an analysis of code coverage and mutation testing tools, Types of Testing
thereby helping the developers to choose their testing tools
suitably. Therefore, we performed a controlled experiment to There are many types of testing[21] .They are listed as
investigate the performance of these tools by implementing follows.
Bubble sort algorithm in the Eclipse plug-in.
1. Unit Testing
Index Terms— Code Coverage, Analysis of Code Coverage 2. Functional Testing
Tools, Mutation testing, Analysis of mutation testing tools. 3. Integration Testing
4. System Testing
5. Stress Testing
I. INTRODUCTION 6. Regression Testing
[9]
Software testing is used to ensure that the software 7. Acceptance Testing
system is defect free by ensuring that the actual results meet 8. Usability Testing
9. Performance Testing
the expected results. It is used for verification of System
10. Beta Testing
under Test. It is used to identify the errors or missing
requirements to make the software system better. Software Unit Testing
testing can be done either manually or by using automated Unit testing is a type of white-box testing which tests a
tools. single unit or group of related units. It is used by the
programmer to test if the units are producing the expected
Black box Testing output against given input for the program executed.
Black box testing also known as functional testing is a testing
technique that does not take the internal mechanism of the Functional Testing
system into account rather focuses on the output generated by
the system against any given input. In black box testing, tests Functional testing is the type of Black box testing which
are done from a user’s point of view and test cases can be ensures that the functionality specified in the system
written with the help of specification alone. Black box testing requirements works correctly.
is mostly used for validation.

49
Integration Testing
Integration testing is the technique of ensuring that the
group of combined components produces the aimed output.
Also, the relation and interaction between the software and
hardware components are tested using Integration testing. It
may be used as both white box testing and black box testing
depending upon the software system.
System Testing
System testing is the technique to ensure that the software
is compatible in different environments (e.g., Operating
Systems. System testing can be done only with the full system
implementation and environment. It fits inside the class of
black box testing.
Stress Testing
Stress testing is a type of black box testing. It is the
technique to evaluate how the system works under
unfavorable conditions. This Testing is performed beyond
limits mentioned in the specifications.
beta version. Beta testing aims to cover the unexpected errors
that have occurred in the system unknowingly.
II. CODE COVERAGE
Code coverage [12]
is the measurement of the extent to which
the source program is executed when the corresponding test
suite runs. It is measured in percentage. If the program has
high code coverage then there is less chance of undetected
bugs while lower coverage results in more undetected bugs
comparatively. Different metrics are used to calculate Code
coverage. The basic measure of code coverage is the coverage
item. Coverage item is anything that could be counted and to
see it is covered or not by the test suites.
Coverage can be measured by the following formula:
Coverage= (Number of coverage items exercised / Total
number of coverage items)*100.

Analysis of Code Coverage Tools

Regression Testing
This section presents Java based code coverage
Regression testing is the black box technique performed by tools[6],[7],[13],[17] that perform code coverage analysis [2],[11] .We
either modifying the system, component, or a group of related
have taken the bubble sort program and corresponding test
units in order to ensure that the change does not affect the
program are shown in Fig. 1, 2 to measure the code coverage.
progress and is producing the correct output.
There are many code coverage tools[4],[10] that are available
either for free or commercially.
Acceptance Testing
Acceptance testing is performed by the customer in order to
public class BubbleSort {
ensure that the product has met the specified requirements on
public int[] bubbleSort(int[] arr,int ) {
its delivery and the system works as per the expectations of
the customer. It comes under black box testing. int temp = 0;
if(n>0){
for(int i=0; i < n; i=i+1){
Usability Testing for(int j=1; j < (n-i); j=j+1){
Usability testing is performed based on the perspective of if(arr[j-1] > arr[j]){
the client by providing attractive GUI and ease of handling
the system to the clients. It helps to assess the proficiency of temp = arr[j-1];
the system design. It comes under black box testing. arr[j-1] = arr[j];
arr[j] = temp;
}
Performance Testing }
Performance testing is the technique of assessing the speed }
and effectiveness of the system. Also, it makes sure that the }
results are generated within the specified time as mentioned return arr;
in the system’s performance measures. It comes under black }
box testing. }

Beta Testing Fig. 1. Bubble Sort input code

Beta testing is the black box technique done by the end

users, a team outside development, or releasing full pre-
version of the product to the public which is known as the

50
 is of less cost compared to other commercially available
import java.io.*;
import java.util.*; coverage testing tools Coverage reporting is done in XML,
import junit.framework.*; HTML, or via a Swing GUI. It also provides clear and
public class BubbleSortTest extends TestCase understandable metrics displayed in HTML reports. Clover
{
can be integrated with test frameworks including JUnit,
private BubbleSort s1; TestNG, and Spock.
public void setUp()
{
s1 = new BubbleSort();
}

public void test1() throws IOException

{
int[] ar={2,3,4};
int[] res=s1.bubbleSort(ar,ar.length);
int[] exp={2,3,4};

for(int i=0;i<exp.length;i++)
{
assertEquals(exp[i],res[i]);
Fig. 3. Coverage results-Clover
}
}
public void test2() throws IOException
{ int[] ar={2,3,4,5,6,1};
assertNotNull(ar);
}
public void test3() throws IOException
{
int[] arr1={6,3,3};
int[] res=s1.bubbleSort(arr1,arr1.length);
int[] exp={3,3,6};

for(int i=0;i<exp.length;i++)
{
assertEquals(exp[i],res[i]);
} Fig. 4. Test run explorer window-Clover
assertArrayEquals(exp,res);
}
public void test4() throws IOException
{
int[] arr2=new int[]{2,2,2};
int[] res=s1.bubbleSort(arr2,arr2.length);
int[] exp={2,2,2};
for (int i=0;i<exp.length;i++)
{
assertEquals(exp[i],res[i]);
}
assertArrayEquals(exp,res);

}
Fig. 5. Generated report -Clover
Fig. 2. Bubble Sort Test code

A. Clover
Clover [14] is available as either an Eclipse or IDEA plug-
ins. It also works using ANT script. It supports Java and .Net
programming. It supports statement, branch, method, class,
and package coverage. This tool provides an accurate and
configurable coverage analysis. It is not open source yet it

51
 Fig. 9. Boolean analyzer-CodeCover
Fig. 6. Class coverage distribution and complexity-Clover

B. CodeCover
CodeCover[15] is an extensible open source testing tool for
Java programmers. It can be integrated into Eclipse. It
performs source code instrumentation and provides statement
and branch coverage. It helps to increase test quality and
helps to develop new test cases. It generates the report in
HTML .The GUI support provided by code cover helps in
easy observation on the coverage of the code. It uses a Fig. 10. Correlationmatrix-CodeCover
correlation matrix to find redundant test cases and optimize
the test suite .It can be integrated with the JUnit framework.

Fig. 11. Coverage analyzer-CodeCover

C. EclEmma
EclEmma[16] is free code coverage tool for java. It provides
Fig. 7. Coverage results-CodeCover
source code instrumentation. It performs dead code analysis
and verifies the parts of the program that are exercised by the
test suite. It supports class, method, line and basic block
coverage .It provides GUI support and generates report in
XML and HTML. It can be integrated with JUnit framework.

Fig. 8. Instructions covered-CodeCover

52
 D. Observations
For the conducted experiment, Bubble sort program is taken
and executed. The coverage for bubble sort program in case of
CodeCover is 95.13% with overall coverage of 98%.It also
enables the results to be viewed as Boolean analyzer,
Correlation matrix, coverage graph, and test session. The
coverage in EclEmma is similar to CodeCover and it is
supported in Eclipse kepler version and further updated
versions. EclEmma is easy to handle since it displays the
coverage results easily but it does not provide results in the
form of graph or matrix as in case of CodeCover. Clover, on
the other hand resulted in 94.4% of coverage with overall
coverage of 97.9% .It is not open source but trial version for
Fig. 12. Coverage results-EclEmma 30 days is available. Clover provides further more in depth
reports than the other two tools including Boundary value
analysis, Class complexity and method complexity which of
these cannot be observed from the other two tools.

TABLE II
COMPARISON OF COVERAGE METRICS

Coverage Tools
metrics Clover CodeCover EclEmma
Statement 100 100 100

Branch 87.5 75 87.5

Loop - 66.7 -
Fig. 13. Instructions covered-EclEmma
Condition - 87.5 -
TABLE I Method 94.4 - 100
COMPARISON OF CODE COVERAGE TOOLS

Tools
Features
Clover CodeCover EclEmma III. MUTATION TESTING
Access Charge Open-source Open-source Mutation testing [5] is a type of white box testing mainly
Supported used for unit testing. It is done by mutating certain statements
Java,.Net Java Java
Languages
Instrumentati in the program, thereby checking that the test cases are able
Source code Source code Byte code
on to find the error or not. The program is mutated only to a
Statement,
Statement, Statement, smaller extent so as not to affect the overall objective of the
Coverage Block
method, class, Branch, loopand
Measures Method and program. It is also called Fault based testing strategy. The
and package condition
Supported Class goal of mutation testing is to make the software more robust
coverage Coverage
Coverage
against failures.
Ant, Maven,
Grails, Eclipse, Mutation Score:
IDEA, Bamboo, Ant, Jenkins, Makefile and
Integrations
Gradle, Griffon, Eclipse ANT The mutation score is defined as the ratio of killed mutants
Jenkins, Hudson, to the total number of mutants represented in percentage. By
Sonar decreasing the count of live mutants, the mutation score can
be increased.
Junit Support Yes Yes Yes

GUI Support Yes Yes Yes

Mutation Score =(Killed Mutants / Total number of
Coverage, Mutants)* 100
correlation pdf,txt,HTM
Reports pdf,HTML,XML Boolean analyzer
L,XML
views & HTML
format

53
 Analysis of Mutation Testing Tools
This section presents Mutation testing tools[3],[8],[19] that
ensure the robustness of the formulated test suites. There are
mutation testing tools that are available either for free or
commercially. Following are some mutation testing tools.

A. Muclipse
Muclipse[18] is an open source mutation testing tool for the
java developers. It supports JUnit and can be integrated with
Eclipse. Muclipse provides both source code and byte code
instrumentation. By injecting mutants, the correctness of the
test cases is verified.

Fig. 16. Compare mutants window-Muclipse

B. PITclipse
PITclipse[20] is a Java based open source mutation testing
tool. It applies a configurable set of mutation operators[1] (or
mutators) to the byte code generated by compiling the code.
The reports produced by PIT are easily understandable. It
generates the report in HTML and XML. It supports JUnit
framework.

Fig. 14. Mutants creation-Muclipse

Fig. 17. Injected mutants-PITclipse

Fig. 15. Mutation score-Muclipse

Fig. 18. Mutants execution-PITclipse

54
 IV. CONCLUSION

In this paper, controlled experiments based on both code

coverage and mutation testing has been performed for Bubble
sort algorithm. Based upon the observations on code coverage
tools, it is inferred that clover is better than CodeCover and
Eclemma and based upon observations on mutation testing
tools Pitclipse is better than Muclipse as a developer. More
importantly, we hope that this paper assists the developers
and research community to increase their exposure on code
coverage and mutation testing tools, to choose the appropriate
Fig. 19. Generated coveragereport-PITclipse code coverage tool that improves the software quality, and to
improve the software testing process.
TABLE III
COMPARISON OF MUTATION TESTING TOOLS
REFERENCES
Tools
Features
Muclipse PITclipse [1] Andersson, M. (2017). An Experimental Evaluation of PIT’s Mutation
Operators.
Access Open-source Open-source [2] Dabas, N., & Solanki, K. (2013). Comparison of Code Coverage Analysis
Tools: A Review. International Journal of Research in Computer
Languages Applications & Information Technology (IASTER), 1(1), 94-99.
Java Java [3] H Halabi, Dana & Shaout, Adnan. (2016). MUTATION TESTING
Supported
TOOLS FOR JAVA PROGRAMS – A SURVEY. international journal of
Source-code and byte- computer science and engineering. 5. 11-22.
Instrumentation Byte-code
code [4] Hoskote, Y., Kam, T., Ho, P. H., & Zhao, X. (1999). Coverage estimation
Command line and for symbolic model checking. In Proceedings 1999 Design Automation
Interface Eclipse Plug-in Conference (Cat. No. 99CH36361) (pp. 300-305). IEEE.
Eclipse Plug-in
[5] Jia, Y., & Harman, M. (2011). An analysis and survey of the development
JUnit Support Yes Yes of mutation testing. IEEE transactions on software engineering, 37(5),
649-678.
Separate source and class Separate file in [6] Kajo-Mece, E., & Tartari, M. (2012). An evaluation of java code coverage
Mutant State files memory testing tools. BCI (Local), 72-75.
[7] Lingampally, R., Gupta, A., & Jalote, P. (2007, January). A multipurpose
GUI Support Yes Yes code coverage tool for java. In 2007 40th Annual Hawaii International
Conference on System Sciences (HICSS'07) (pp. 261b-261b). IEEE.
Reports Console window HTML,XML [8] Mariya, F., & Barkhas, D. (2016, October). A comparative analysis of
mutation testing tools for Java. In 2016 IEEE East-West Design & Test
Symposium (EWDTS) (pp. 1-3). IEEE.
[9] Pan, J. (1999). Software testing. Dependable Embedded Systems, 5,
2006.
C. Observation [10] Shahid, M., & Ibrahim, S. (2011). An evaluation of test coverage tools in
software testing. In 2011 International Conference on
For the conducted experiment, Bubble sort program is taken Telecommunication Technology and Applications Proc. of CSIT (Vol.5).
sn.
and executed. The coverage for bubble sort program in case of [11] Yang, Q., Li, J. J., & Weiss, D. M. (2009). A survey of coverage-based
CodeCover is 95.3% with overall package coverage of 98%.It testing tools. The Computer Journal, 52(5),589-597.a
[12] Code Coverage, https://en.wikipedia.org/wiki/Code_coverage
also enables the results to be viewed as Boolean analyzer, [13] Code coverage tools, https://stackify.com/code-coverage-tools/
Correlation matrix, coverage graph, and test session. The [14] Clover, http://www.atlassian.com/Software/clover/
[15] Code Cover, www.codecover.org
coverage in EclEmma is similar to CodeCover and it is [16] Emma, http://emma.sourceforge.net/
supported in Eclipse kepler version and further updated [17] Java code coverage tools,
https://en.wikipedia.org/wiki/Java_code_coverage_tools
versions. EclEmma is easy to handle since it displays the [18] Muclipse, http://muclipse.sourceforge.net/updatesite.php
coverage results easily but it does not provide results in the [19] Mutation testing, https://www.softwaretestingclass.com/what-is-mutation-
testing-tools-testing-types-and-its-challenges/
form of graph or matrix as in case of CodeCover. Clover, on [20] PITclipse, https://marketplace.eclipse.org/content/pitclipse
the other hand resulted in 94.7% of coverage with overall [21] Softwaretesting,https://www.codeproject.com/Tips/351122/What-is-
software-testing-What-are-the-different-ty
package coverage of 97.9% .It is not open source but the trial
version for 30 days is available. Clover provides further more
in depth reports than the other two tools including Boundary
value analysis, Class complexity and method complexity
which of these cannot be observed from the other two tools.

55
CHAPTER 10

PLAGIARISM REPORT

56