Application resource and activity footprinting to influence management in next generation clouds

Application Resource and Activity Footprinting to Influence Management in Next Generation Clouds

C. Peoples, G. Parr and B. Scotney School of Computing and Information Engineering

Faculty of Computing and Engineering University of Ulster

Coleraine, United Kingdom {c.peoples; gp.parr; bw.scotney}@ulster.ac.uk

S. Sarangi and S. Kar Bharti School of Telecommunication Technology and

Management Indian Institute of Technology Delhi

New Delhi, India [email protected]; [email protected]

Abstract—Standardised and interoperable management solutions are an objective for the next generation of cloud to autonomically provision and configure resources in a manner generically applicable across platforms and applications. Cloud interoperability is desirable in spite of platforms having variable management requirements and applications having various resource demands. In this paper, the resource footprint of an application, Wisekar, developed at the Indian Institute of Technology Delhi is explored, alongside consideration of its scalability with increasing volumes of requests. The limiting network resource in this deployment is bandwidth, which restricts the extent to which memory and CPU resources can be consumed, regardless of the number of application requests sent to the server. Definition of resource consumption relationships between attributes while servicing application requests leads to recommendations on server and network loading which optimises the overall utilisation across all. This results in an average footprint across CPU, memory and network of 0.85 (max. of 1).

Keywords—application profiling, resource footprint, server provision, cloud management, performance optimisation.1

I. INTRODUCTION

Application footprinting can influence the availability and configuration of resources across networks and, particularly, clouds where resources are dynamically deployed in response to Quality of Service (QoS), resilience and energy efficiency objectives. While interoperable architectures are a desirable feature of next generation clouds [1], a standardised approach to profile applications and influence management decisions is being accommodated in the workplans of standardisation bodies: Study Group 16 of the ITU-T, for example, is using application profiling in current work [2], recognising that each application has unique requirements and a profile is needed to define service features, functions, and operation attributes.

Application profiling is important from the perspectives of next generation cloud management in the sense of accommodating ‘big’ data, supporting a dynamic cloud fabric, and achieving interoperability. Clouds contribute to optimised network operation through provision of fewer redundant components requiring management and greater utilisation of

978-1-4799-2361-8/14/$31.00 ©2014 IEEE

available resources. Awareness of application requirements is therefore essential in intelligent service provision. Two aspects associated with application operation are considered as part of this approach: 1) The resource consumption footprint of application transactions, and 2) Activities executed when using the application. A resource footprint indicates the extent to which cloud compute, storage and network resources are consumed during individual transactions and application sessions. Activities associated with application execution include step-by-step processes invoked and paths followed through a website. When both aspects of application operation are considered together, these highlight the volume, duration, configuration and positioning of cloud resources required.

In this paper, footprints and activities associated with an application developed in the Indian Institute of Technology Delhi, Wisekar, is explored [6] [7]. The application platform supports upload and download of e-health and e-agri datasets. When profiling the application footprint, the limiting resource is bandwidth, which subsequently restricts server CPU and memory utilisation. This scenario can be improved by making application resources available across a multi-server environment; application activities are therefore also captured to advise on how this should occur for optimised QoS.

The remainder of the paper continues as follows: In Section II, related work in the field is reviewed from the perspectives of application and activity profiling solutions from industry and the independent research community. The research approach of resource and activities profiling is described in Section III, and experimental results are presented in Section IV. The paper concludes and presents further work in Section V.

II. RELATED WORK

Related work within the context of this research includes application resource footprinting, activities executed when using applications, and their influence on management decisions. Solutions are currently rolled-out in an ad hoc manner, being specific to application types and not generically applicable across all. SAP, for example, defines Standard Application Benchmarks [8] to define how hardware is used by their software and influence optimised resource roll-out. An ‘Assemble to Order’ (ATO) Benchmark, for example, defines a scenario with high sales volumes and short production times

(e.g., PCs, cars). The Benchmark is defined in terms of steps executed when the application is used: 0: Log-on, 1: Main screen, 2: Create customer order, 3: Enter order, and so on. Output of an ATO benchmark is throughput i.e., orders per hour. An ‘E-Selling’ Benchmark, on the other hand, defines catalog activities, which are characterised by high browsing and low shopping activity: 0: Start application, 1: Select product category, 2: Display product details, 3: Select another product category, and so on. The application benchmarks rolled out by SAP capture core activities when using their software.

Oracle uses Applications Benchmarks [9] to measure performance for Financial Systems (e.g., accounts payable, accounts receivable), Human Resource Management Systems, Customer Support, and Supply Chain Management (e.g., order management, purchasing, and shipping). The Benchmark is defined within two main modes of operation: online and batch. Metrics reported for the online benchmark are ‘user count’ and ‘average response time’. For batch, ‘throughput’ is the key metric. This benchmark measures neither application resource requirements nor key activities. It does however, capture performance achieved, which inherently reflects relationships between resource requirements and availability. Infosys, on the other hand, define metrics to characterise operation and performance of applications [10]. These include peak and off-peak periods, total and concurrent number of users, key transactions frequency and complexity, usage patterns, and data access intensity. VMware VMmark [11] is another technique which captures application performance in relation to both application operation and overall system scalability.

Contributions are also available from the independent research community: In [3], the objective is to eliminate contention across multi-tier applications by using their footprint profiles. Applications are characterised according to the workload type and request rate variation. In [4], the authors present an approach in which mobile application performance is captured, using jitter, bandwidth and battery consumption. The authors in [5] contribute a management solution which optimises overhead associated with application profiles by using a sampling technique operated for this purpose.

There are therefore a range of solutions by which application operation may be captured. These are specific however, to the applications monitored, with roll-out of strategies on an ad hoc and organisation-specific basis. While both the independent research community and the standardisation bodies contribute solutions, this remains a research area in which there is scope to make a contribution in the definition of a standardised approach to cloud management.

III. RESEARCH APPROACH: WISEKAR SERVER FOOTPRINT

In the current Wisekar deployment, clients place simultaneous requests on a single server to retrieve or upload datasets. Wisekar datasets are large collections of unprocessed e-agri and e-health data (every upload can be approximately 200 KB, and with just 1000 such images, the total size can go up to 200 MB), uploaded to the repository, and downloadable if made available for this purpose. Data transfers to and from the Wisekar server are therefore not interactive, and the unique requirements of such applications are not needed as part of this

management scheme. Servers supporting Wisekar in a larger deployment (for which this management approach is developed) will allow infinite users to make application requests: Overall network capability supporting Wisekar, in that case, may be from a single server, as in the current deployment, or application data may be replicated across multiple servers or placed across a distributed server set. Servers may also migrate across cloud hosts in response to the sites from which application requests are received and resource availability across end-to-end paths. Data distribution and replication across servers is influenced by dataset popularity.

Cloud server resources are a finite pool of compute, storage and network capability. Resource footprints are captured using open source monitoring tools in Linux (described in greater detail in Section IV). This application resource and activities profiling is based on the concept that, if application throughput trends can be predicted, trends for compute, storage and network consumption footprints can similarly be predicted, and dynamic resource roll-out, which fulfils demand and performance requirements, influenced. This also takes into account ability to capture trends in application activity profiles.

The consumption of one resource affects ability to consume others. In general, as network consumption, for example, increases, CPU consumption increases. The extent to which this can occur however, is restricted within finite resource availability. Correlations between resource consumptions are therefore calculated to influence effective server loading based on normalised (xnormalised) CPU, memory and network footprints (between 0 and 1) across a monitored period.

minmax

min

xx

xxxnormalised

(1)

It is significant that footprints are normalised to eliminate the effect of specific units (e.g., KB/s or %), a characteristic dependent on resource type, configuration and operation: Correlation coefficient r between resource x and y is calculated:

2222 yynxxn

yxxynr

(2)

The closer the coefficient to one, the greater the correlation.

IV. WISEKAR: APPLICATION AND ACTIVITY PROFILING

In addition to profiling while idle, ability to cope with increasing numbers of clients (between 25 and 75) is explored by emulating GET requests on the Wisekar server using JMeter [12] (Table 1). The Wisekar server has a hard disk of 70 GB, 16 GB memory, 4 cores per processor, and runs Ubuntu 10.04

Table 1 Average Resource Footprints across Scenarios with Increasing Numbers of Clients

# Client Threads Contribution to Footprint Average CPU Network Memory

Idle 0.112 0.361 0.296 0.256 25 0.419 0.549 0.552 0.506 50 0.469 0.572 0.482 0.507 75 0.692 0.867 0.657 0.738 Average (active): 0.53 0.66 0.56 0.583

LTS. Application resource profiles are captured using sysstat [13], while activity profiling uses Google Analytics [14].

When the sever is idle, there is a CPU footprint of 0.1, a network footprint of 0.36, and memory footprint of 0.3. A footprint is incurred while allowing the device to exist on the network and represents the cost to receive, process and respond to management packets despite not processing application traffic. Of specific interest for this research is the way which the consumption footprint increases once processing application traffic. Greatest change in the footprint occurs when transition between idle and active modes occurs (e.g., the CPU footprint increases from 0.112 to 0.419). Further increases in client load (i.e., from 25 to 50 or 75 threads) however, contribute a lesser impact on the footprint (i.e., the CPU footprint increases from 0.419 to 0.469 when supporting

Figure 1 Memory and CPU Correlation: 25 clients

Figure 2 Memory and CPU Correlation: 50 clients

Figure 3 Memory and CPU Correlation: 75 clients

between 25 and 50 clients). Pressure on resources occurs once 75 clients are supported, with average consumption across all resources of 0.738. This is contrasted with the average footprint of 0.507 for 50 clients and 0.506 for 25 clients. Network bandwidth is the bottleneck on operation and performance in this scenario, limiting the extent to which the other server resources, CPU and memory, may be used.

A. Relationships between CPU and Memory Footprints

Relationships between CPU and memory consumption, while streaming to a local desktop client in Delhi, are captured (Figure 1 to Figure 3). Clusters in operation become more apparent when operating at higher workload volumes (Figure 3). This refers to both operation for 75 client threads beyond a footprint of 0.6 for both memory and CPU resources, and for 50 client threads (Figure 2) beyond a footprint of 0.9 for both memory and CPU. As the number of clients decreases by 25, there is decline in the footprint by approximately 0.3. Figure 3 reveals the way in which maximum memory consumption restricts ability to maximise CPU consumption. Figure 2 reveals that, when CPU consumption is maximised, memory consumed is at minimal levels, and vice versa. The fact that resource footprints in Figure 1 are spread across the range of footprints possible indicates that there are no restrictions on network operation in response to this volume of loading – resources are allocated and used as required and the acceptable volume of workload allocated could further be increased. These results reveal trends in performance that can influence network management: as the number of clients supported at the server increase, the footprints of clients cluster around approx. 0.6 (i.e., lower than optimal contributions to the footprint), suggesting that this is the point where maximum levels of performance are achieved in the current set-up. Maximum utility of all resources provisioned and available however, is not achieved at this point, and there is an opportunity to improve this through more effective resource provisioning.

B. Relationships between CPU and Network Footprints

Footprint clusters also occur when supporting higher workload volumes for CPU and network resources (Figure 4). Footprint calculations reveal that bandwidth limits full CPU utilisation within the context of this file download scenario. This becomes apparent by the greater extent of clustering

Figure 4 CPU and Network Correlation: 75 clients

Figure 5 Network and Memory Correlation: 50 clients

Figure 6 Network and Memory Correlation: 75 clients across Figure 4 in comparison to the results across Figure 1 to Figure 3. Even when supporting lower levels of loading, clusters in CPU and network consumption become apparent. These results also highlight that full utilisation of one resource can restrict full utilisation of another (Figure 4): when supporting 75 clients, for example, full utilisation of network bandwidth restricts full CPU utilisation. Taking action to prevent the full utilisation of one resource is therefore important to balance the consumption across others.

C. Relationships between Network and Memory Footprints

Relationships between network and memory consumption footprints are also captured (Figure 5 and Figure 6). As with the other results collected, clusters in operation and constraints on performance become more obvious when supporting higher volumes of workload, as seen particularly when supporting 75 clients. The results also indicate how full utilisation of one resource limits ability to fully utilise other resources: When supporting 50 clients, for example, the network reaches a scenario where it is almost fully consumed, as indicated by the footprint close to 1, while the memory footprint is substantially lower, below 0.1. This result therefore indicates that network resource consumption restricts ability to fully consume server memory and CPU, and greater resource consumption may be possible through improved bandwidth availability.

D. Application Activity

In addition to resource footprints associated with application requests, popular paths through a website are also influential in resource provisioning decisions. Paths through

Wisekar have therefore been tracked between Sep. to Oct. 2013, revealing, for example, probability of user bounce from the home page, the depth to which the website is explored by any user, and the most popular pages visited across all visitors.

In an exemplar scenario: A user enters Wisekar through the ‘index’ page, with visitors then alternatively visiting the ‘main’ or ‘about us’ pages. From the ‘about us’ page, visitors during this monitored period then exit the website. From the ‘main’ page, on the other hand, visitors access ‘user list’, ‘active sets’ and ‘file update’ pages. From each, visitors then go on to visit other pages, to variable levels of depth. The most popular webpages visited during the monitored period are ‘index’ (13), ‘home’ (6) and ‘main’ (6). These are accessed by users on an international basis, although the majority of users reside in India (22 in India in comparison to 2 in the UK). The findings indicate that additional resources may continue to be rolled-out on a localised basis due to the placement of users making requests on the website. The most popular webpages accessed indicate that there may be an opportunity for replication of (cached) webpages of the level of demand increases from the localised client base. The performance results also indicate that particular pages are visited less frequently than others, and need therefore not be replicated across the cloud deployment.

Application activity considered within this paper is for a small demographic group while the prototype has been under development, capturing core activities of website users. While it is more difficult to track live user activity for a prototype development, website activity has been emulated to stress-test performance and operation when the most resource-intensive activity (file download) is executed to capture resource consumption footprints, as detailed in the following section.

E. Wisekar Workload Throughput

One of the objectives of this research is to use Wisekar’s resource and activity footprints on compute, network and

Figure 7 Total Throughput Read (KB/s): 75 clients Table 2 Correlation between Throughput and Footprints

Correlation between Throughput and … # Client Threads Memory CPU Network 25 0.31 0.28 0.31 50 0.36 0.36 0.42 75 0.58 0.64 0.93 Average: 0.42 0.43 0.55

Table 3 Correlation Matrix between Network Resources clients memory CPU network clients 1 0.1479 0.3615 0.2689 memory 0.1479 1 -0.0616 0.1208 CPU 0.3615 -0.0616 1 0.8175 network 0.2689 0.1208 0.8175 1

Table 4 Average Variation between Actual and Calculated Resource Consumptions

memory CPU network

cpu

net

wor

k

mem

ory

net

wor

k

mem

ory

cpu

25 0.149 0.029 0.127 0.251 0.121 0.018 50 0.158 0.096 0.063 0.072 -0.04 -0.039 75 0.132 -0.05 0.0579 0.118 -0.05 0.057 Average: 0.146 0.058 0.082 0.147 0.071 0.038

memory resources to pre-empt network activity and therefore resources required. The corresponding results for throughput have therefore additionally been captured (e.g., in Figure 8 for 75 clients). These results are as anticipated, increasing in parallel with the number of clients. There is an average throughput rate of 472.5 KB/s for 25 clients, 596.5 KB/s for 50 clients, and 810.5 KB/s for 75 clients. Throughput increases at a faster rate once the number of clients increases towards the maximum number supportable (determined from server stress-testing experimentation under increasing workloads).

The network attribute has the highest correlation coefficient with throughput (Table 2) and is therefore the most effective for predicting this metric. This indicates that bandwidth is the main influence on server memory and CPU utilisation. Correlations between the number of clients, and memory, CPU and network consumption are also captured (Table 3). The strongest correlation occurs between the CPU and network footprints (0.8175) (Figure 9). As network consumption increases, CPU consumption increases. This does not reach a correlation of 1 however, because CPU and bandwidth

Figure 8 CPU and Network Footprint Correlation

Figure 9 Memory and Network Footprint Correlation

Figure 10 Memory and CPU Footprint Correlation

availability is limited. Network and memory consumption have the lowest correlation (0.1208) (Figure 10). A decreasing relationship exists between CPU and memory, in that CPU consumption declines as memory consumption increases (Figure 11). As the number of clients increase, memory (0.1479), CPU (0.3615), and IO (0.2689) consumption increases. These results therefore reveal the variable extent to which each metric is influential on others, which can be used in cloud management decisions for optimised operation.

To be usable across scenarios, a generalised approach on the overall impact of resource consumption relationships is required. The contribution of this research therefore defines a method by which compute, storage and network resource footprints may be determined based on the consumption of other resources in the mix. For example, based on the memory footprint, it will be possible to determine CPU and network requirements. It is also possible to determine the point at which further loading of a resource may be restricted based on negative impact on others. The mechanism helps with the dynamic deployment of resources in response to the volume of application requests, in the sense that a certain memory or CPU requirement can be determined based on bandwidth availability. Previous results have identified that CPU loading can be limited based on the rate of traffic entering the device or extent to which memory is used. The objective is to limit scenarios where application requests cannot be supported by over-loading one resource at the expense of others.

Mechanisms have therefore been developed to use each metric to determine consumption requirements. CPU is used, for example, to calculate network and memory requirements; memory is used to calculate network and CPU requirements; and network is used to calculate memory and CPU requirements. Figure 11 and Table 4 capture the effectiveness of each in relation to actual values incurred. The network attribute is more effective at calculating memory requirements, memory is more effective at calculating CPU requirements, and CPU is more effective at calculating network requirements.

Using this approach, it is possible to assess network loading to allow optimum resource utilisation and instruct that additional resource roll-out is required. In the event that the CPU is fully loaded to a footprint of 1, the network will require loading to allow a footprint of 0.86 to support this utilisation, with memory loading to a footprint of 0.42 in the current scenario. If memory is fully loaded to a footprint of 1, the network can be utilised to a footprint of 0.42 with a CPU footprint of 0.42. If the network is fully loaded to allow a consumption footprint of 1, the CPU can be utilised to a footprint of 0.86 and the memory to a footprint of 0.42. It is recommended however, that CPU utilisation does not increase beyond 0.7 due to additional impact on power inefficiencies when operating beyond this level. Memory can subsequently be utilised to a footprint of 0.9006 and the network to a footprint of 0.9617. This results in an overall resource footprint of 0.85, which we advise is the optimal manner to operate.

The scheme proposed in this work is concerned with server loading based on relationships between loading of critical resources and ability to subsequently fully consume other affected resources. Data popularity based replication will

Figure 11 CPU, Network and Memory Footprints: 75 therefore not significantly affect suitability of the scheme beyond the fact that additional decision-making will be required to decide server selection based, firstly, on proximity, and then on residual resource availability and potential for further loading. We therefore do not consider that our approach will be affected by data replication across distributed sites, assuming that a centralised management overlay will control this aspect. Specific details of this consideration are, however, outside the scope of work described in this paper.

V. CONCLUSION & FUTURE WORK

In this scenario, application footprinting has indicated that ability to fully load server resources is limited by residual bandwidth availability. By understanding the application profile, it is possible to influence resource loading for optimal levels of operation and performance. Due to inefficiencies associated with operating servers to the full levels achievable, we make recommendations on the extent to which network and memory may be loaded. Within the context of the current deployment, this results in a recommendation of a server loading of 0.7, memory loading of 0.9 and network loading of 0.96. This therefore results in a more balanced loading of all resources available while not over-loading the server.

In future work, we will explore the extent to which the recommended loading scenario is effective when measured in terms of the number of application requests supported, latency with which a response is delivered, and number of jobs which achieve sub-optimal levels of performance. Furthermore, while the specific correlations calculated are not currently incorporated into the mechanisms of the algorithm, they can be used within the management framework in future developments, and will result in a more effective approach. The correlation is variable depending on the amount of resource available in relation to other resources, and therefore varies on a situation-specific basis. By incorporating the coefficient into decisions made, there will be greater confidence that the workload allocation decisions made will be more accurate and, subsequently, more effective and efficient.

ACKNOWLEDGMENT

This work is supported by the India-UK Advanced Technology Centre of Excellence (IU-ATC) in Next Generation Networks, funded by the UK Engineering and Physical Sciences Research Council (EPSRC) Digital Economy Programme and Government of India Department of Science and Technology (DST). We also acknowledge Vikas Chawla, IIT Delhi, for his support.

REFERENCES (CORRECT AS OF JANUARY 31ST, 2014)

[1] C. Peoples, A. Oredope, G. Parr and K. Moessner, "The Standardisation of Cloud Computing: Trends in the State-of-the-Art and Management Issues for the Next Generation of Cloud," in Proc. of the Science and Information Conference, Oct. 2013, pp. 1-9; INSPEC No.: 13899578.

[2] International Telecommunication Union Telecommunication Standardisation Sector, “Question 25/16 – IoT Applications and Services”; Available at: http://www.itu.int/en/ITU-T/studygroups/2013-2016/16/Pages/q25.aspx.

[3] W. Dawoud, I. Takouna and C. Meinel, “Dyanmic Scalability and Contention Prediction in Pubic Infrastructure using Internet Application Profiling,” in Proc. of 4th IEEE Int. Conf. on Cloud Comp. Tech. and Science, 2012, pp. 208-216; DOI: 10.1109/CloudCom.2012.6427552.

[4] A. Diaz, P. Merino and F. J. Rivas, “Mobile Application Profiling for Connected Mobile Devices,” in IEEE Pervasive Computing, Vol. 9, Iss. 1, 2010, pp. 54-61; DOI: 10.1109/MPRV.2009.63.

[5] H. Kyu Cho, T. Moseley, R. Hawk and D. Bruening, “Instant Profling: Instrumentation Sampling for Profiling Datacenter Applications,” in Proc. of IEEE/ACM Int. Symp. On Code Gen. and Opt., 2013, pp. 1-10; DOI: 10.1109/CGO.2013.6494982.

[6] Wisekar Homepage: http://wisekar.iitd.ac.in/.

[7] S. Sarangi and S. Kar, “Wireless Sensor Knowledge Archive,” in Proc. of IEEE Int. Conf. on Electronics, Computing and Communication Technologies, Jan 2013, pp. 1-6; DOI: 10.1109/CONECCT.2013.6469315.

[8] SAP Standard Appliation Benchmarks Homepage: http://global.sap.com/campaigns/benchmark/index.epx.

[9] Oracle Applications Benchmark Homepage: http://www.oracle.com/us/solutions/benchmark/apps-benchmark/index.html.

[10] Infosys, “Recommendations for Performance Benchmarking,” White Paper, Jan. 2008, pp. 1-6.

[11] VMware VMmark Homepage: http://www.vmmark.org/.

[12] JMeter Homepage: http://jmeter.apache.org/.

[13] Sysstat Homepage: http://sebastien.godard.pagesperso-orange.fr/.

[14] Google Analytics Homepage: www.google.com/analytics.