eXo Blog – Java Middleware for Cloud Services

The following post is from Henri Gomez, IT Operations Manager at eXo.

Last week Amazon announced a new Java Platform-as-a-service offering: AWS Elastic Beanstalk. Here at eXo, we rely on several Amazon cloud computing services (S3 and EC2), so I was intrigued. Following a quick review of the Getting Started Guide and the Amazon Blog post, Introducing AWS Elastic Beanstalk, I was convinced that I had to take a closer look at the platform. This article is a summary of my initial impressions.

Getting Started

Since eXo already has accounts on AWS, I used our QA account to connect to the Elastic Beanstalk console.

When you access the service, Elastic Beanstalk asks you to create your application from an Amazon sample, or upload your own application (i.e., your web app).

Next you have to choose an application URL, provide a simple description, select the underlying AWS model (32/64bits Linux), then upload your .war file.

Basically, Elastic Beanstalk is an EC2 instance with a dedicated Apache Tomcat 6 web server.

The environment then initializes on the AWS infrastructure.

And after initialization, you see that it’s ready to serve.

In the previous screenshot you can see version history, since I uploaded 3 versions of our sample application. I had to do this because the first attempt resulted in Elastic Beanstalk reporting an error with our application. After some digging, I discovered Elastic Beanstalk is monitoring your application via a monitoring health URI. By default this URI is ‘/’, reminding you that it’s always a good practice to define a welcome-file in web.xml.

First Impressions

Elastic Beanstalk provides basic but useful tools to set up and monitor your application.

Logs

To get a log from a Tomcat operation, click Snapshot Logs.

The log file contains the typical Apache Tomcat logs:

Notes:

• Elastic Beanstalk provides Apache Tomcat 6.0.29 with the Tomcat Native library 1.1.20 for better performance.
• HTTP and AJP are available, but the Elastic Beanstalk front end does not use mod_jk or AJP 1.3 (more on this later).
• Our application is renamed ROOT.war (sus the / in URI), which shows Elastic Beanstalk’s mono web app approach.

Monitoring

The available monitoring capabilities are basic but should cover general usage requirements.

Clicking on one of the graphs will show you more detailed statistics. Here you can see CPU usage:

And this panel shows status of your application:

Configuration

When the configuration is complete, you can define instance size, load-balancing, database, notifications and even JVM settings.

Instance Sizing

Load Balancing

• HTTP/HTTPs front end and Health Monitoring URL:

• Session Stickiness

Auto Scaling

This is the most important feature in Elastic Beanstalk, and where “elastic” becomes a true description.

• Min/Max instances

You can start with a minimal instance, and fix max instances where your application will be replicated.

• Scaling Triggers

Scaling Triggers determine how Elastic Beanstalk will decide to deploy more instances to handle the load.
Triggering Metrics could be networks, CPU or disk operations.

Databases

If your application needs database support, Amazon RDS (MySQL clone) is available for use.

Notifications

Notifications are important for any IT operations team responsible for apps in production.

The support is simple for now, and uses email notifications:

Container

This is where you’ll set your JVM environment, min/max heap, perm gen size, and specific VM flag.

Another nice feature is the ability to use AWS S3 to store log archives; since eXo is on AWS infrastructure, having log file rotation on S3 storage could be useful.

Notes:

We tested the default 32bits AMI provided by Elastic Beanstalk and discovered the JVM used is OpenJDK 1.6

java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.1) (amazon-44.1.9.1.16.amzn1-i386)
OpenJDK Client VM (build 19.0-b06, mixed mode)

At this time, I don’t know if Amazon will provide other JVMs, i.e. Sun/Oracle, IBM or JRockit (maybe license reasons prevent them from offering others now?).

Stress Tests

I wanted to see how the Elastic Beanstalk instance performs, so I installed our Performance Meter web app on the instance.

PerfMeter servlet is configurable via URI parameters, so we could select the response wait time and size. In my test, the wait time and content were set to a minimal ‘OK’ string.

Of course, to reduce network latency, I connected to one of our EC2 instances on the same Amazon Area (i.e. US).

[hgomez@xxxx ~]$ ab -c 50 -n 10000 -k -H 'Accept-Encoding:gzip, deflate' http://exo-qa-perftest.elasticbeanstalk.com/PerfMeter?waittime=-1\&responsesize=10240
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking exo-qa-perftest.elasticbeanstalk.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests

Server Software: Apache-Coyote/1.1
Server Hostname: exo-qa-perftest.elasticbeanstalk.com
Server Port: 80

Document Path: /PerfMeter?waittime=-1&responsesize=10240
Document Length: 10240 bytes

Concurrency Level: 50
Time taken for tests: 12.81536 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 1909
Total transferred: 104139566 bytes
HTML transferred: 102651967 bytes
Requests per second: 827.71 [#/sec] (mean)
Time per request: 60.408 [ms] (mean)
Time per request: 1.208 [ms] (mean, across all concurrent requests)
Transfer rate: 8417.64 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 7.3 1 83
Processing: 3 57 41.2 53 1433
Waiting: 2 39 37.5 33 1429
Total: 3 59 41.9 55 1434

Percentage of the requests served within a certain time (ms)
50% 55
66% 67
75% 79
80% 86
90% 102
95% 117
98% 134
99% 153
100% 1434 (longest request)

CPU / Networks loads reflect the load test:

Notes:

AutoScaling

Elastic Beanstalk performed pretty well, and scaled automatically, as reported by events status:

2 micro instances were reported by the EC2 control panel for my application:

On the HTTP side

• The load-balancing system didn’t use HTTPd/jk, but instead used Amazon Load Balancing, Server Software reporting as Apache-Coyote/1.1 (i.e. Apache Tomcat HTTP stack).
• The bad news: gzip compression is not enabled by default on HTTPConnector (easy to fix in server.xml).

Conclusions

My first tour through Elastic Beanstalk showed a solid Java application platform for the cloud, loaded with many features:

• Simple configuration
• Good monitoring features
• Nice load-balancing, with support for SSL
• Rich auto-scaling
• Native S3/RDS support

And of course, you should be able connect to this EC2 instance using SSH KeyPair.

I’m looking forward to investigating Elastic Beanstalk further, both to understand how it works under the hood, and to learn how to customize it for eXo’s purposes.