Close

Request a demo

CliQr's groundbreaking technology makes it fast and efficient for businesses to move, manage and secure applications onto any private, public or hybrid cloud environment.

CliQr is now part of Cisco Learn More About Cisco
Request a Demo

Blog

Best @hpcloud sizing for N-tier #Java #webapp?

Figuring out all the different combinations of memory, # of CPUs, storage size, storage performance, network performance, and price, figuring out the right instance sizing for the different layers of an N-tier Java webapp in the cloud, any cloud, is a difficult task.  If you were to manually benchmark all relevant combinations, it would take a lot of labor and get expensive.  CliQr CloudCenter greatly simplifies this task, or any cloud benchmarking for that matter.

The goal of this experiment is to establish a set of guidelines for choosing HP Public Cloud instance sizes for an N-tier Java webapp.  Every N-tier Java Webapp is a little bit different, so the results here will not create hard and fast rules, but guidelines on how to size tiers properly.  The goal here is to pare down the number of possible combinations to a manageable number so that you can use the guidelines discovered here as a starting point for testing your specific application.

N-tier Java Webapp Test Parameters

The popular Spring Framework sample application, PetClinic, was used with an HAProxy load balancer distributing requests between two Tomcat 6 application servers, which then communicated with a single MySQL 5.1 database server.  Four VMs in all across three tiers.  To impart load on each tested installation, a JMeter script by Mark Nolan was retrieved from GitHub and adapted slightly to take advantage of the host IP address substitution feature of the CliQr benchmarking facility as well as changes to the root path expected by the script (the original assumed “/petclinic” instead of simply “/”) and an increased load (the original launches 550 transactions, modified 5500).   The resulting .jmx file can be found here.

Again, the goal of this test was to establish guidelines, not unbreakable rules.  As with all benchmark tests launched using CliQr CloudCenter, a test node is created and loaded with JMeter in the same region as the application being tested, US Central 1a in this case.

HP Cloud Instance Types Considered

From the published list of available HP Public Cloud instance types when the tests were performed in early March, 2014, tests started with the standard line of instance types:

Standard Instance Type (Flavor) Description
Standard Extra Small 1 HP Cloud Compute Unit, 1 virtual core, 1GB RAM, 20GB disk
Standard Small 2 HP Cloud Compute Units, 2 virtual cores, 2GB RAM, 40GB disk
Standard Medium 4 HP Cloud Compute Units, 2 virtual cores, 4GB RAM, 80GB disk
Standard Large 8 HP Cloud Compute Units, 4 virtual cores, 8GB RAM, 160GB
Standard XL 15 HP Cloud Compute Units, 4 virtual cores, 15GB RAM, 300GB

HP Cloud Instance Size Test Round 1: Shotgun Approach

The first round of testing sought to discover where the knee in the price-performance curve might be.  Load balancers tend to not need much CPU or memory, but under the circumstances network performance might impact the results.  Prior N-tier Java webapp experience tells us that the application server layer tends to be fairly even with regard to memory and CPU consumption while the database layer tends to put more of a strain on memory.

With those thoughts in mind, the following table shows the combinations executed in Round 1:

LB

App

DB

Standard.small Standard.small Standard.small Baseline
Standard.medium Standard.small Standard.small Slightly better LB
Standard.medium Standard.medium Standard.small Slightly better App
Standard.medium Standard.medium Standard.medium Slightly better DB
Standard.large Standard.medium Standard.medium Increase LB layer a 2nd time
Standard.large Standard.large Standard.medium Increase App layer a 2nd time

 

Among the powerful features of CliQr CloudCenter is that the profile for this multi-tiered PetClinic was constructed once and then reused across all 6 of these tests.  Once the series of tests were started, their cumulative execution around 55 minutes.

Running these tests manually would take several orders of magnitude longer than this and be subject to potential inconsistencies in the runs.  By using CliQr CloudCenter, the consistency of each of the 6 tests executed is guaranteed by the underlying automation and reuse of the same application profile.

The Round 1 table above is color coded to correspond to the graphed price-performance results, where being on the upper left is better:

hp-petclinic-round1

 

The first thing that pops out in this set of tests is the green test is very much out of line with the others.  As such, it will be rerun in Round 2.  Ignoring that for a moment, performance increases steadily as size is added to each tier, peaking with the orange test where all tiers are standard.mediums.  The red and dark blue tests indicate that no advantage is to be gained by adding more resources to the load balancing or app server tiers, but are those results an anomaly like the green one?

A typical N-tier Java Webapp will see gains with larger application servers and, sometimes, with larger load balancers but our first round results aren’t conclusive.  Let’s start Round 2 by re-executing the last 4 tests from Round 1 and adding some horsepower to the load balancing and application layers.

HP Cloud Instance Size Test Round 2: Seeking Precision

With data from the first set of tests in mind, Round 2 reruns some of those tests for validation and adds a smaller DB test.

LB

App

DB

Standard.medium Standard.medium Standard.small Medium LB/app, small DB
Standard.medium Standard.medium Standard.medium Increase the DB
Standard.large Standard.medium Standard.medium Increase the LB
Standard.large Standard.large Standard.medium Increase the app server
Standard.large Standard.large Standard.small Decrease the DB

 

Again, all that was required to run these additional tests using CliQr was to reuse the Application Profile from the first six, just with different sized machines for the different layers.  All 5 tests in this round took just over 40 minutes to complete and the results validated some things we saw in Round 1:

hp-petclinic-round2

 

The medium/medium/small, purple here, validated what we saw in Round 1 with similar results.  This set of tests, however, showed slightly better performance with larger load balancing and app tiers with some money saved on a smaller database tier (green).  Let’s run one more set of tests with standard.xlarge at the load balancing and app tiers to see if that makes a difference.

HP Cloud Instance Sizing Round 3: Xlarge LB and App Tiers

LB

App

DB

Standard.medium Standard.medium Standard.medium All mediums
Standard.large Standard.large Standard.medium Increased app and LB tiers
Standard.large Standard.large Standard.small Decreased DB tier
Standard.xlarge Standard.large Standard.small Increase LB
Standard.xlarge Standard.xlarge Standard.small Increase app

 

hp-petclinic-round3

A slight boost in performance was gained between the red configuration (all standard.mediums, with 144.73 requests per second) and the orange configuration (standard.large at the load balancing and application server tiers, but standard.small database, with 152.6 requests per second), but beyond that there were no further advantages for larger sizing.

 

Conclusions

The data collected here provides some useful guidance for multi-tiered Java applications on GCE, including:

  • Larger VMs at the load balancing layer can make a measurable performance difference for the application as a whole.
  • Application servers perform better on larger VMs and lower memory, higher CPU options available with the highcpu family are worth exploring.
  • Money can be saved on the database tier, which performed just as well with smaller VM sizes than with larger ones.

As always, it is best to run your exact application on a variety of configurations to get sizing that suits your specific needs.  All application workloads vary from others.  As this exercise has shown, though, CliQr CloudCenter makes it quick and easy to test different combinations so that you can get the data you need to make the best decision for your organization.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *


× five = 20

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Stay Informed

Subscribe to our email list for company updates.

CliQr Technologies, CliQr CloudCenter and CloudBlades are trademarks of CliQr Technologies, Inc. All other registered or unregistered trademarks are the sole property of their respective owners.