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 AWS instance sizing for an N-tier Java webapp?

Given 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.  Benchmarking all relevant combinations manually is laborious and expensive.  Luckily, CliQr makes it simple.

For this investigation, the goal is a set of guidelines for choosing AWS instance sizes for an N-tier Java webapp.  Not hard and fast rules, mind you, because every N-tier Java Webapp is a little bit different.  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

For this series of tests, 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.   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, so the AWS load balancing and database services were not used.  Instead, individually sized virtual machines were used for the load balancing and database layers.  As with all benchmark tests launched using CliQr CloudCenter, a test node was created and loaded with JMeter in the same region as the application being tested, AWS US West (Oregon) in this case.

AWS Instance Types Considered

From the published list of available AWS instance types when the tests were performed in early February 2014, several sizes were omitted from test consideration.  Given the nature of PetClinic, the micro size, any storage optimized sizes, or sizes with GPU processors were considered.  An edited table of potential choices, then, is as follows:

Instance Family

Instance Type

Processor Arch

vCPU

ECU

Memory (GiB)

Instance Storage (GB)

EBS-optimized Available

Network Performance

General purpose

m1.small

32-bit or
64-bit

1*1

1

1.7

1 x 160

-

Low

General purpose

m1.medium

32-bit or
64-bit

1

2

3.75

1 x 410

-

Moderate

General purpose

m1.large

64-bit

2

4

7.5

2 x 420

Yes

Moderate

General purpose

m1.xlarge

64-bit

4

8

15

4 x 420

Yes

High

Compute optimized

c1.xlarge

64-bit

8

20

7

4 x 420

Yes

High

Memory optimized

m2.xlarge

64-bit

2

6.5

17.1

1 x 420

-

Moderate

Memory optimized

m2.2xlarge

64-bit

4

13

34.2

1 x 850

Yes

Moderate

Memory optimized

m2.4xlarge

64-bit

8

26

68.4

2 x 840

Yes

High

 

AWS 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
M1.small M1.medium M1.medium Baseline
M1.medium M1.medium M1.medium Better network on LB;all moderate
M1.xlarge M1.medium M1.medium Better network on LB (high); rest moderate
M1.xlarge C1.xlarge M1.medium High CPU middle tier, moderate memory
M1.xlarge M2.4xlarge M1.medium High CPU and high memory middle tier
M1.xlarge M2.4xlarge C1.xlarge High CPU db
M1.xlarge M2.4xlarge M2.4xlarge High cpu and high memory middle tier

 

Among the powerful features of CliQr CloudCenter is that the profile for this multi-tiered PetClinic was constructed once and then reused across all seven of these tests.  Once the series of tests were started, their cumulative execution took just over an hour and the cloud time on AWS totaled just $17.18.

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 seven 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:

AWS-PetClinic-Round1

As one might expect, the larger instance sizes performed better, but at considerably higher cost, making the first four tests more interesting for further exploration.  The green test suggests that the M1.small isn’t sufficient for the load balancer, but comparing the orange and purple tests suggests that the M1.xlarge doesn’t offer substantial benefits compared to the M1.medium.  Also, the size of the database tier doesn’t appear to have much of an effect on the overall outcome, so perhaps it can be reduced even further.

AWS Instance Size Test Round 2: Seeking Precision

For this round, the best price-performance test of the first round was re-executed for both comparisons sake and to see if the results are consistent given that VM provisioning sometimes produces randomly poor performing instances.  Next, additional tests are added to see if money can be saved with a smaller database tier.

LB App DB
M1.medium M1.medium M1.medium Better network on LB;all moderate
M1.medium M1.medium M1.small Small DB
M1.medium C1.xlarge M1.small Small DB with larger middle tier
M1.medium C1.xlarge M1.medium Larger middle tier

 

Again, all that was required to run these additional tests using CliQr was to reuse the Application Profile from the first seven, just with different sized machines for the different layers.  The results proved interesting:

AWS-PetClinic-Round2

This second set of tests took less than an hour and accumulated just $3.70 in AWS cloud charges.  Throughput on the green configuration, with the smaller database, suffered only slightly compared to the red configuration with M1.medium VMs at all layers (57.56 requests per second vs 58.45, whose details are available upon mouseover in the CloudCenter benchmark results screen this image was created from).  Keeping that smaller database, but increasing the size of the application servers, as shown with the orange configuration, increased throughput to 63.49 transactions per second.

Conclusions

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

  • Better network associated with slightly larger VMs on the load balancing tier is worth the additional cost.
  • Application servers can perform better on larger VMs, but might not be worth the additional cost, depending upon the unique characteristics of your application.
  • Money can be saved on the database tier, which performed just as well with smaller VM sizes than with larger ones.

As stated at the beginning, it’s always best to run your exact application on a variety of configurations to get sizing that suits your specific needs, but this exercise has shown just how easy it is to do with CliQr CloudCenter.

Leave a Reply

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


9 − four =

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.