We have been working for the past few days on building a benchmark for our new web containers and its built-in integration with the apache load balancer.
The benchmark was running on Amazon EC2/EBS cloud and was deployed using our new web based cloud tools.
The benchmark goal is to measure the scalability of the web layer using an industry-standard web based application – the Pet Clinic.
With this benchmark the data is stored in the GigaSpaces's In-Memory-Data-Grid (IMDG) and persisted into a MySQL database in an asynchronous manner. We used GigaSpaces SLA containers (the "Service Grid") to host the relevant services when running in a cloud environment.
The benchmark uses the following components:
– The Standard Spring based pet clinic application ported to use GigaSpaces DAO instead of Hibernate DAO when accessing the data. See the GigaSpaces ported version here.
– JMeter – the popular benchmark and measurement tool.
– Ant – Ant has a nice support for JMeter.It allows you for example to inject different numbers of users into a JMeter test plan and run it headless. – GigaSpaces XAP 6.6
– Amazon EC2
– Apache 2.2 as a load-balancer running on the cloud
– GigaSpaces Apache 2.2 load-balancer agent running on the cloud
– Jetty web server running as a web container within the GigaSpaces Service Grid.
– GigaSpaces web based cloud tool.
– Sun MySQL database – running on the cloud using Amazon Elastic Block Store (EBS). The database is configured and started automatically once the AMI instance is started.
– GigaSpaces Amazon EC2 large AMI that includes JMeter , ant , XAP 6.6 , apache , mysql , ganglia (and more) pre-configured , integrated and fully tuned.
– Result analyzer application that parses the results created by JMeter and produces a table with the average response time vs. amount of concurrent users.
As you can see from the list above – it is a unique mix of commodity and standard infrastructure running on the cloud and is used by the majority of our customers on EC2. We use JMeter to simulate heavy web-traffic generated by large amount of end-users. The traffic is generated in the same network as the web servers , apache load-balancer and the IMDG.
As you can see from the graph below the response time latency is decreased when having more web servers are running:
Users browsing the Internet are usually tolerant of a latency of between 500-1000 ms between mouse click and page download. From the graph above, if a single user response time latency over the LAN is about 5 ms , it means you could serve ~100 real web users without them to be annoyed with the delay.
Extrapolating these numbers provides us the following graph:
This means that with 3 web servers sharing the same IMDG you could serve 400 concurrent users with less than 1 sec latency. This assumes the network latency is 200 ms and there is some additional overhead involved when having large amount of users hitting the apache load-balancer , web container and the IMDG concurrently.
We have measured also the IMDG max throughput when having 1 , 2 and 3 web servers. See the results below:
As we can see the IMDG load is increased when adding more web servers almost in a linear manner. This means the bottleneck is the web layer – when scaling the web layer we provide better latency. We could have used local cache or local view to eliminate the access to the IMDG , but the test was focused with measuring the web layer scalability and not with optimizing the data access layer or caching it within the web-server runtime.
Now, a few words about the user experience and ease-of-use when faced with such a large amount of different components running in this new cloud environment: It was surprisingly simple thanks to the new GigaSpaces Web-based Cloud deployment and management UI.
In order to run the benchmark there is no need to have the applications files on your local machine or be familiar with the EC2 cloud API or management tools. All the application related files have already been placed on the cloud (using Amazon S3 repository). The user is only required to specify some simple configuration choices using an XML document and the GigaSpaces web cloud deployment and management UI is responsible for instantiating the AMIs, starting relevant GigaSpaces containers and deploying the application while controlling the entire life cycle of all the different application components.
See below a screenshot of the new GigaSpaces web UI cloud tools interface:
The above proves that scaling a web application composed of multiple components on EC2 is not a "far fetch dream" anymore; it is here today, at your fingertips!
If you would like to run this benchmark yourself , drop us line to: firstname.lastname@example.org.