Many thanks Shlomo for your reply.

All the best,
Ram

I’m glad you find this post helpful.

It sure would be great to use ELB as an internal component without incurring the extra bandwidth charge. Unfortunately that is not an option today. ELB is designed to be accessed via public IP addresses (which incur the internet bandwidth charge) because (presumably) the ELB system needs the ability to remap those public IP addresses to different virtual LB machines when one of them fails – exactly the same way you would remap an Elastic IP to recover from instance failure.

I guess it might be technically possible for AWS to deliver an ELB that is accessed via private IP addresses, for “internal-to-EC2″ use, but it would not be as resilient in the face of failure as “regular” ELB.

Awesome post!!

i’m using ec2 only for few month now and it keep on amaze me on how simple things are when using it correctly, i just implemented the ELB in our ec2 servers and it works perfectly, thank you for your great post!!!

one question though, from what i understand until now you can approach the load balancer only from the “outside” and i also would like to use the ELB to distribute internal requests between my instances within the cloud.. is it possible to create an EC2 load balancer which will work without going first outside the cloud?
i know it will work this way also but it will cost more and will take more time than if i could do it all internally.

once again, thank you for a great post!

Best,
Ram

If I understand correctly, you’re asking: “Is there a way to change the IP address of an instance from the AWS Management Console? And can you change the IP address of an instance whenever you want, for example once a day?”

Please correct me if I misunderstood your question.

Using the AWS Management Console (or the API, or the command-line tools) you can change the public IP address of an instance by associating and removing an Elastic IP. When you associate an Elastic IP, the original public IP address is released. When you remove an Elastic IP, a new public IP address is provided. Usually this new address is different from the original address (the address the instance had before the Elastic IP was associated), but sometimes it is the same.

To do this on a regular schedule you could write a script to call the appropriate command-line tools or API methods, and use standard scheduling tools (e.g. cron).

It’s likely that the tests are not causing the ELB to scale. This might be due to the DNS lookups on the JMeter hosts being improperly cached. Try launching the JMeter processes with the -D option to adjust the sun.net.inetaddr.ttl property as discussed in the article above.

I have not yet seen a ceiling for LB throughput in all the tests I’ve run and reviewed.

It looks to me that we are hitting the max throughput at ELB as we do not see any contention from the back end servers…

We are gardually increasing the request/seconds in 10 minutes duration.
Any Idea how to check what is the max throughput we can achieve from ELB?

Thanks a ton.

Let’s look at those numbers first.
Y is the response time. This number should stay constant across your two test cases, which are identical in all ways except for number of requests generated.
X is the req/sec served through the LB. When this number peaks it can mean one of two things:
1. You’ve hit the maximum throughput of the ELB.
2. You’ve hit the maximum throughput of the back-end instances.
The way to tell the difference is by looking at the back-end instances. If they are maxing out on CPU or network input/output (or some other observable constraint) then the bottleneck is in the back-end instances. If the back-end instances are not stressed on any axis then the bottleneck is in the LB.

In your case it sounds like you hit the maximum throughput of the LB. Your ELB would need to scale itself in order to handle more throughput.

However, as mentioned in the article, your test case does not really stress the scalability of ELB properly. The test case should gradually ramp up the req/sec over time in order for the LB to be able to scale itself to meet the load. So the X req/sec you observed is a false reading.

If you want to check the maximum performance of a single back-end instance, run your JMeter test cases against a single back-end instance.

A very informative post about the ELB.

I am new to the cloud and trying to do the Load Testing for a high traffic application using Jmeter.

I have one ELB routing the traffic to 4 Jboss instances (m1-XLarge) and 3 MySQL shards.

I ran a 7500 Vusers test using 1 Jmeter master and 8 Jmeter slave instances sitting in the cloud and I could reach up to X req/sec with Y ms as a response time. There was no contention at JBOSS and DB layer.

Just to find the break point I tried running the same test with 10K Vusers and increased the Jmeter slaves to 12; however I could see the test is still able to achieve same X req/sec with Y ms as response time. and there was no contention at the JBOSS and DB layer this time as well.

I am not sure whether I am hitting the ceiling of ELB in bound traffic or this could be due to some other reasons.

I would highly appreciate your suggestions on this.

Thanks in advance.