How To Migrate A Jee Ntier Application To Cloud With The Best Configuration

Configuration challenges when migrating applications to a cloud:

the JEE use case

Alain Tchana

, Noel De Palma

, Xavier Etchevers

, and Daniel Hagimont

1

_{University Joseph Fourier, LIG Laboratory, Grenoble, France, (alain.tchana, noel.depalma)@imag.fr}

_{Orange Labs, Grenoble, France, [email protected]}

3

_{Toulouse University, IRIT Laboratory, Toulouse, France, [email protected]}

Abstract—Cloud computing brings new opportunities and challenges to run applications’ scalability on a per-demand. Migrating an application to the Cloud raises two main ques-tions: (i) which configuration of VM (in terms of resources) is appropriated for the application, while minimizing price? and (ii) what are the appropriated configuration parameters for the application, regarding the type of the VM? In this paper we answer these questions by studying the case of JEE n-tier applications, which are composed of several types of servers, making their configuration very complex. Based on experiments we have conducted in our private cloud on a reference JEE benchmark (RUBiS), we show how to migrate such applications to cloud platforms with their best configurations.

Keywords:JEE; Cloud Computing; Performance

1. Introduction

Cloud computing brings new opportunities and challenges to run applications’ scalability since it provides the capacity to deliver IT resources and services automatically on a per-demand, self-service basis over the network. IT resources can be provisioned in a matter of minutes rather than days or weeks like in traditional enterprises IT. One of the main characteristic of the cloud technology is its pay-for-use pricing model. Indeed, application providers (customers) only pay for the resources they have used, for their uptime. For these reasons, companies are increasingly migrating their infrastructures to the cloud. When migrating to the cloud, customers are faced with several configurations/types of VMs (each with identify by a particular CPU, memory, disk space, and bandwidth resources) provided by the cloud platform. For example, Amazon EC2 defines 14 types of VM and Windows Azure proposes 5. Even if some platforms give some guidelines about the choice VM according to the expected workload of the running server, this diversity of VM configurations increases the difficulty of config-uring applications, which depends on their hosting VM. In summary, migrating an application to the Cloud raises two main questions: (i) which type of VM is appropriated for the application, while minimizing price? and (ii) what are the appropriated value for the application configuration parameters, regarding the type of the VM?

In this paper we answer these questions by studying the case of JEE n-tier applications. These applications are com-posed of several types of servers, making their configuration very complex. A bad configuration of one participant server can lead to a poor application performance (in terms of throughput for example). We conduct several experiments in our private cloud, on a reference JEE benchmark (RU-BiS [10]) composed of a Tomcat server linked to a MySQL server. According to the conclusion of [9], we focus on their threads pool configuration parameters: maxThreads parameter for Tomcat and max_connections parameter for MySQL. (1) We observe that the appropriate configuration value of the MySQL max_connections parameter is the number of vcpu of the MySQL VM. (2) We show that even if the bottleneck tier of such applications is the MySQL tier, the Tomcat tier allows the application to maintain its maximum throughput. (3) Finally, we show that replicating Small VMs is more efficient than running Medium or Large VM type, even if the latter have twice or four times the size of the former in terms of resources.

The remainder of this paper is structured as follows. Sec-tion 2 presents the motivaSec-tions of this work. SecSec-tion 3, 4, 5, and 7 detail experiments we have conducted. Section 8 and 9 present respectively the related work and the conclusion of this paper.

2. Problem Statement and Experimental

Context

2.1 Problem Statement: JEE applications in

the Cloud

These last years have seen the development of the JAVA technology (JEE) for complex web applications based on the n-tier architecture. With the PHP technology, JEE appli-cations are one the most executed appliappli-cations in the web. For that reason, most popular cloud platforms provide pre-packaged virtual machines (VM for short) including JEE servers ([2], [1], [3]). Deploying such applications to the cloud raises two questions ([6]):

• (Q1) What is the best configuration for each tier of the application?

• (Q2) Which type of VM (e.g. small, medium, large) is appropriated for each tier of the application while avoiding resources waste, and minimizing cost?

2.1.1 Question Q1

As reported by [7], the configuration of a JEE application is very difficult. In the scope of this paper, our consid-ered JEE application (RUBiS) is composed of HAProxy loadbalancer, Tomcat, MySQL-Proxy and MySQL servers. Regarding the number of parameters, it is obviously non feasible to tune all of them. Qingyang shows in [9] that parameters which define thread and database connection pool are very crucial. These parameters correspond to the Tomcat maxThreads and the MySQL max_connections parameters in our considered RUBiS configuration. Therefore, a bad configuration of the Tomcat maxThreads or the MySQL max_connections parameters impacts the overall perfor-mance of the application. Fig. 1 (vUsers is the number of emulated Internet clients) shows the behavior of the RUBiS application when the Tomcat maxThreads parameter is set to 1. We observe that the application is unable to maintain a stable throughput (about 180req/s, Fig. 1(a)), whereas the response time is under 10ms (Fig. 1(b)) and the Tomcat server is not saturated (Fig. 1(c)).

2.1.2 Question Q2

Since the configuration of the JEE application depends on the resources of machines housing its servers, this task be-comes more difficult in the context of cloud computing. This comes from the diversity of the configurations/types of VM proposed by the cloud platform. Although cloud platforms provide some guidelines to help customers to choose VM configurations according to the expected workload of their applications, these informations are not sufficient. In fact, the cloud platform is not able to provide depth studies about all existing applications.

2.2 Experimental context

2.2.1 The JEE application benchmark: RUBiS

The JEE application we use is provided by RUBiS [10] (servlet version), a JEE benchmark. RUBiS implements an auction web site modeled over eBay. It defines interactions such as registering new users, browsing, buying or sell-ing items. RUBiS is provided with a web client emulator which implements the behavior of one/many e-commerce customers, including human think time. This emulator is equipped with different types of workloads, allowing it to generate browsing and browsing mix traffics. We con-figure this tool to progressively generate traffics for our experiments. To remain within allowable page length, we only present in this paper experiments results for browsing requests.

2.2.2 Cloud environment

Our experiments were carried out using the Grid’5000 [13] platform, which is composed of clusters in different areas of France. We used two Grid’5000’s clusters (Chinqchint and Chicon) to deploy the RUBiS servers and the RUBiS client emulator servers separately. The two clusters run OpenStack [12] and Xen hypervisors (version 3.2) to set up a virtualized cloud providing three types of VM with configurations similar to those defined by Amazon EC2 [2]: Small, Medium and Large. They run the same operating system as the nodes which host them: Linux Ubuntu 10.0.4 distribution with a 2.6.30 kernel, over a gigabit connection.

2.2.3 Experiments workflow

The workflow of experiments we have realized is the following:

• First of all, we identify the first tier that we will begin the experiment with. This corresponds to the bottleneck tier.

• Secondly, we evaluate the appropriate configura-tion value of Tomcat maxThreads and MySQL max_connections parameters for each type of VM. This experiment results in a guideline we propose concerning the choice of these parameters.

• Thirdly, we determine which type of VM is appropri-ated for Tomcat and MySQL tiers when they are well configured.

• Finally, we evaluate the limit of each tier when in-creasing the replication degree of the other tier. This is helpful to implement scalability strategies, which is commonly encountered in JEE applications.

2.2.4 Metrics

For these experiments, we considered the following met-rics:

• The CPU and memory loads of VM servers; • The response time for requests and their throughput; • The number of vUsers.

We focus on the maximal throughput (given by the RUBiS client emulator) provided by the application in various configurations which all maintain a percentage of requests under a given response time threshold. We consider that the RUBiS application has reached is maximum capacity when the response time for more than 10% of requests exceeds this threshold (set to 5 seconds). This is in line with the conclusion of [11], where a response time longer than 5 seconds was described as likely to make 10% of potential customers navigate away in a e-commerce appli-cation. Based on these parameters, we defined the notions of goodThroughput (respectively badThroughput), which represents the throughput of requests below the threshold (respectively above the threshold). The throughput metric

Fig. 1: The consequence of a bad configuration of Tomcat maxThreads parameter (set to 1) on the RUBiS performance: (a) application throughput, (b) response time, and (c) servers CPU and memory loads.

determines the capacity of the RUBiS application while ensuring an SLO response time. In addition to throughput, we considered the number of vUsers (emulated Internet clients) causing application saturation.

3. The bottleneck tier

To prevent skewing the satisfaction results, the beginning tier should be the first bottleneck tier, since its behavior may bias the configuration of other tier if it is not well configured. The first bottleneck tier was the one limiting application performance (maximum throughput in our case). To identify this tier, we tested a RUBiS configuration comprising a Tomcat server linked to a MySQL server, each other runs on Small VM. Their crucial parameters are kept to their default value: maxThreads to 200 and max_connections to 100. The results of this experiment are shown in Fig. 2. It is clear that the MySQL VM CPU reaches 100% at 380 s (Fig. 2(a)), while the Tomcat VM CPU load is negligible (close to 1%). In terms of memory load, neither VM becomes saturated (Fig. 2(b)). The maximum throughput for the application (about 180 req/s) is shown to be achieved when the CPU load of MySQL VM reaches 100%. In fact, the throughput increases until 380 s, and remains constant for the remainder of the experiment, whereas the number of vUsers continues to increase (Fig. 2(c)). For the response time (Fig. 2(d)), there is no badThroughput until the MySQL VM CPU reaches 100% (time 380s, curve "Good SLA"). After this time, some requests take more than 10 s to execute (curve "Bad SLA").In conclusion, the bottleneck tier is MySQL and its bottleneck resource is the CPU. Thus, we start investigating the configuration of the RUBiS application in the cloud by MySQL.

4. Tuning the MySQL max_connections

parameter

We tested different values of max_connections from 1 to 500 (1, 20, 40, 60, 80, 100, 200, 300, 400, and 500). These experiments were performed for the three types of VM housing the MySQL server. During these tests, Tomcat was

deployed on a Small VM, and its maxThreads parameter was maintained at its default value. This Tomcat configuration does not affect the experimental results since MySQL is the bottleneck tier, as shown above.

Small VM: The application has the same capacity (180 req/s) whatever the value of max_connections. Maximum capacity is reached from 110 vUsers. However, although the response time remains below the defined threshold, its grows with the value of max_connections (Fig. 3). This is due to the fact that the increase in max_connections increases the number of threads running on the MySQL VM. This reduces the server’s efficiency since its VM uses CPU time to switch between process contexts.

Medium VM: Once again, the application has the same capacity (210 req/s) whatever the value of max_connections from 2 to 500. Maximum capacity is reached from 130 vUsers. However, a lower capacity (180 req/s) is noted when max_connections is set to 1 because with 1 thread, the Medium VM (2 vcpus) does not use its overall CPU resources. The increase in response time observed is due to the reasons outlined above.

Large VM: The application has a capacity of 240 req/s whatever the value of max_connections from 4 to 500. This throughput is reached from 130 vUsers. When max_connections is set to 1, throughput is 180 req/s; it is 210 req/s with max_connections set to 2 and 3. The response time increases with max_connections as for the other two VM sizes tested.

Conclusion: The results of all these experiments are sum-marized in Fig. 4. The appropriate value of max_connections appears to be equal to the number of virtual CPUs (vcpus) available on the VM hosting MySQL. Higher max_connections values increase the response time, and multiplying the resources available to the MySQL VM does not result in a proportional increase in application performance.

Fig. 2: Bottleneck tier detection: the MySQL server is CPU-bound. (a) Server CPU load, (b) Server memory load, (d) Application throughput, and (d) application response time (below and above the threshold)

Fig. 3: Tuning the MySQL max_connections parameter does not significantly affect the application’s response time

Fig. 4: Recommended settings for the MySQL max_connections parameter

5. Tuning the Tomcat maxThreads

pa-rameter

After the MySQL server, the second tunable parameter in the RUBiS application is the Tomcat maxThreads setting. For this experiment, MySQL was run on a Small VM with max_connections set to 1 (its best value). We chose this type

of VM for MySQL because the other types only increase the application’s throughput. They are therfore equivalent in this second experiment. For the Tomcat server we tested a Small, Medium and Large VM with the maxThreads parameter varying from 1 to 2500 (1, 20, 40, 60, 80, 100, 200, 300, 400, 500, 1000, 1500, 2000, 2500). Because Tomcat is not the first bottleneck tier, the same behavior was observed for all three VMs. The application’s capacity is determined by MySQL. The results of this second RUBiS tuning step are shown in Fig. 5 for the Small Tomcat VM. This analysis reveals that the maximum throughput for the application remains unchanged whatever the value of maxThreads: 180 req/s reached from about 110 vUsers. However, with maxThreads set to 1 (Fig. 5(a)), the application cannot maintain this throughput even though the response time remains below the threshold. One thread is obviously insufficient to serve all the injectors’ requests. At values between 20 and 400, a constant response time is maintained throughout the ex-periment (Fig. 5(b)); while the response time declines with maxThreads from 500 to 2500 (Fig. 5(c)). This degradation can be explained by context switching between processes and the higher number of processes overall. Increasing maxThreads results in increases in both CPU and memory loads for Tomcat. However, Tomcat is still not the bottleneck for the application since it saturates after the MySQL server. Nevertheless, its saturation affects the application’s ability to maintain throughput. In our experiments, the optimal

Fig. 5: Impact of the Tomcat maxThreads parameter on application throughput

maxThreads setting is 100.

6. Which type of VM for each tier?

After configuring Tomcat and MySQL servers for each type of VM, let us now investigate what is the best type of VM for each tier. Experiments we presented above show that among the tree type of VM, the Small one is the best candidate. In fact, concerning MySQL tier, Medium VM (respectively Large VM) does not dubbed (respectively quadruple) the performance of the application even if their resources represent twice (respectively four times) the Small VM. About Tomcat, the Small VM is sufficient since it is not the bottleneck tier. Thus, for this tier, we need to know if micro VM type (as also provided by Amazon EC2) can provide the same performance as Small Tomcat VM. We

experiment two types of Tomcat micro VM and compare their results with Small VM:

• [SmallV M]/2: a half of a Small VM, • [SmallV M]/4: a quarter of a Small VM.

Fig. 6 and 7 show the comparison of the three types of VM in terms of maximum throughput and the ability of the application to maintain this throughput. We observe the same maximum throughput (180req/s) whatever the type of VM (Fig. 6). However, this throughput is not maintainable with

[SmallV M]/4 (the application is down after 1200vUsers, Fig. 6(a)). This is due to the saturation of Tomcat (CPU and Memory). Regarding[SmallV M]/2, it gives about the same performance as Small Tomcat VM. However the application maintains only 60% of goodThroughput in this configuration ("% of Good Throughput" curve in Fig 7(b)). The other requests are performed with at least 20s of response time. In conclusion, the micro VM [SmallV M]/4 type is not recommended. If the customer just wants to maintain the maximum throughput, the [SmallV M]/2 is sufficient for Tomcat. If he wants both the maximum throughput with good response time, at least the Small VM Tomcat is required.

7. JEE tiers replication/scalability

We have shown in section 5 that MySQL is the first bot-tleneck tier; in this step, we determined the saturation point for the Tomcat server (i.e., how many replicated MySQL servers are needed to make Tomcat into the bottleneck tier). To do this, the experiment was repeated varying the number of MySQL servers. Experiments were stopped when the application’s capacity (maximum throughput) in the current experiment (running n MySQL servers) was the same as in the previous experiment (running n-1 MySQL servers); n-1 MySQL servers are therefore required to saturate the Tomcat tier. This was performed for one (Fig. 8(a)) and two (Fig. 8(b)) Tomcat instances.

With one Tomcat instance (Fig. 8(a)) 18 instances of MySQL fully saturate the Tomcat tier. Plotting the CPU and memory loads for different servers in these experiments reveals Tomcat as the first bottleneck tier, with a CPU load of 100%.

With two Tomcat instances (Fig. 8(b)) the Tomcat tier became saturated with 30 MySQL instances. Note that even when the number of Tomcat instances is doubled, the number of MySQL instances needed to saturate the Tomcat tier does not increase proportionally. Indeed, the application’s performance is not doubled either. This is also the case when MySQL instances are doubled.

8. Related work

Few research works are conducted in order to help appli-cations deployers (particularly JEE in our case) to configu-ration their applications in cloud environments. [6] proposes

Fig. 6: Comparison of micro Tomcat VMs ([SmallV M]/2,

[SmallV M]/4) with Small VM: the throughput view.

a self-provisioning system that help applications deployers to choose the appropriate VM configuration according to the workload of the application, considering the cost of the type of VM. Many research works are done about the optimiza-tion of resources usage for JEE applicaoptimiza-tions. [14] describes an analytic model for capacity planning of JEE applications deployed in a large scale environment. It identifies the same questions as us about the configuration of a JEE application (bottleneck tier, resources needed, maximum throughput, etc.). However, [14] is concentrated to the analysis of the JEE application performance when receiving different type of workloads. The impact of the configuration of each JEE server is not treated as we have done. [15] is in line with [14]. It proposes a performance prediction model for JEE applications, based on messages exchanged between the

Fig. 7: Comparison of micro Tomcat VMs ([SmallV M]/2,

[SmallV M]/4) with Small VM: the throughput maintain-ability view.

JEE components. In comparison with [14], the [15]’s model operates at the application design phase and requires that the JEE components communicate via a message server.

About JEE applications tuning, [16] studies the perfor-mance of several implementations of EJB. It analyses the influence of each type of EJB implementation on the overall performance of the JEE application, and also compares an JEE application based on EJB vs JEE application imple-mented exclusively with servlets. [17] reports the importance of threads pool parameters in JEE application, and proposes a middleware to tune them automatically. [5] identifies 28 configuration parameters for an 3-tier e-commerce ap-plication. As [17], it shows that threads pool parameters are the most crucial. It analyzes their impact on the JEE application performance. In comparison to our work, [5] only

(a) (b)

Fig. 8: How many instances of MySQL makes Tomcat the bottleneck tier with one (a) and two (b) Tomcat instances?

experiments lower and higher allocation values. In the same vein, [8] proposes a methodology to help administrators to determine the appropriate configuration of each JEE application layer. This methodology is based on random configuration values for each parameter. The problem of this methodology is that random values are chosen in a range of values identified by authors, but without any justifica-tion. [4] automates the generation of configuration files in JEE applications composed of Apache, Tomcat and MySQL servers. More important, [4] proposes a dependency graph of parameters in such applications, which can be used to determine the configuration workflow in such applications.

9. Conclusion

This paper explores the deployment of a JEE applications in the Cloud. As reported by [7], this is a hard task. We have realized several experiments in order to determine the ap-propriate configuration of each JEE server, regarding cloud provided VM configuration. Our experiments was carried out in our private cloud, with a reference JEE application, RUBiS: composed of Tomcat and MySQL servers. We have explored several configurations of each JEE server, running on thee types of VM (Small, Medium and Large) with comparable characteristics as the Amazon EC2 cloud.

As a future research, we plan to extend this work with browsing mix and write workloads.

Acknowledgment

This work is supported by the French Fonds National pour la Societe Numerique (FSN) and Poles Minalogic, Systematic and SCS, through the FSN Open Cloudware project.

References

[1] Righscale web site, in http://www.rightscale.com, visited on 2012, October.

[2] Amazon Web Services, Amazon EC2 auto-scaling functions, in http://aws.amazon.com/fr/autoscaling/, visited on 2012, October. [3] Windows Azure, in www.windowsazure.com/, visited on 2012, October. [4] Wei Zheng, Ricardo Bianchini, and Thu D. Nguyen Automatic configuration of internet services. In Proceedings of the 2nd ACM SIGOPS/EuroSys European Conference on Computer Systems, pp. 219-229, Lisbon, Portugal, 2007.

[5] Monchai Sopitkamol, and Daniel A. Menasce A method for evaluating the impact of software configuration parameters on e-commerce sites. In Proceedings of the 5th international workshop on Software and performance, pp. 53-64, Palma, Illes Balears, Spain, 2005.

[6] Upendra Sharma, Prashant Shenoy, Sambit Sahu, and Anees Shaikh. A Cost-Aware Elasticity Provisioning System for the Cloud. In Proceedings of the 2011 31st International Conference on Distributed Computing Systems, pp. 559-570, Minneapolis, Minnesota, USA, 2011. [7] Bill Pugh and Jaime Spacco. RUBiS revisited: why J2EE benchmarking is hard InProceeding of the Companion to the 19th annual ACM SIG-PLAN conference on Object-oriented programming systems, languages, and applications, pp. 204-205, Vancouver, BC, Canada, October 2004. [8] Mukund Raghavachari, Darrell Reimer, and Robert D. Johnson The deployer’s problem: configuring application servers for performance and reliability. InProceedings of the 25th International Conference on Software Engineering, pp. 484-489, Portland, Oregon, 2003. [9] Qingyang Wang, Simon Malkowski, Deepal Jayasinghe, Pengcheng

Xiong, Calton Pu, Yasuhiko Kanemasa, Motoyuki Kawaba, and Lilian Harada. The impact of soft resource allocation on n-tier application scalability. InProceedings of the 2011 IEEE International Parallel & Distributed Processing Symposium, pp. 1034-1045, Washington, DC, USA, 2011.

[10] C. Amza, E. Cecchet, A. Chanda, A. L. Cox, S. Elnikety, R. Gil, J. Marguerite, K. Rajamani, and W. Zwaenepoel, Specification and implementation of dynamic web site benchmarks, in IEEE Annual Workshop on Workload Characterization, Austin, TX, USA, 2002. [11] Bojan Simic,The performance of web applications: Customers are

won or lost in one second, A. R. Library, 2008.

[12] Openstack web site, in http://openstack.org/, visited on 2012, April. [13] Grid’5000: a scientific instrument designed

to support experiment-driven research, in https://www.grid5000.fr/mediawiki/index.php/Grid5000:Home, visited on 2012, April.

[14] Samuel Kounev and Alejandro P. Buchmann,Performance Modeling and Evaluation of Large-Scale J2EE Applications, Proceedings of the 29th International Computer Measurement Group Conference, pp. 273-283, Dallas, Texas, USA, December, 2003.

[15] Yan Liu and Ian Gorton,Performance prediction of J2EE applica-tions using messaging protocols, Proceedings of the 8th international conference on Component-Based Software Engineering, pp. 1-16, St. Louis, MO, USA, May, 2005.

[16] Emmanuel Cecchet, Julie Marguerite, and Willy Zwaenepoel, Per-formance and scalability of EJB applications, Proceedings of the ACM SIGPLAN Conference on Object-Oriented Programming Sys-tems, Languages and Applications, pp. 4-8, Seattle, Washington, USA, November, 2002.

[17] Yan Zhang, Wei Qu, and Anna Liu,Automatic performance tuning for J2EE application server systems, Proceedings of the 6th international conference on Web Information Systems Engineering, pp. 520-527, New York, USA, November, 2005.