What are the IBM Rational Performance Tester (RPT) recommendations to load test through an Amazon Elastic Load Balancer ?
Load testing through the Amazon Elastic Load Balancer can result in accessing one single server behind the load balancer. You expect to test the load balancer distribution across multiple servers instead.
- To properly load test an Amazon Elastic Load Balancer, you must understand how the load balancer behaves.
In this document in the DNS Resolution section, you see the following information.
If you do not ensure that DNS is re-resolved or use multiple test clients to simulate increased load, the test may continue to hit a single IP address when Elastic Load Balancing has actually allocated many more IP addresses. Because your end users will not all be resolving to that single IP address, your test will not be a realistic sampling of real-world behavior.
To have the elastic load balancer re-resolve the DNS, add the following line to your RPT remote location(s) VMARGS settings.
- With KEEP_ALIVE_ACROSS_LOOPS_WITHIN_TEST set to false, you force RPT to make a new connection each time. Upon a new connection, the load balancer re-resolves the DNS. The consequence is the following.
The Elastic Load Balancing will return multiple IP addresses when clients perform a DNS resolution, with the records being randomly ordered on each DNS resolution request.
That way, you do not always hit the same server behind the load balancer. The load is distributed across multiple servers.
- KEEP_ALIVE_ACROSS_LOOPS_WITHIN_TEST controls connection keep-alive behavior in certain instances when a test contains loops. Normally with no looping in a test, RPT detects the last request to use a particular connection. RPT then closes that connection after it received the response to save resources. If this same condition occurs but the request is in a loop within a test, by default RPT does not forcefully close the connection, If you set this option to false, RPT always closes the connection after the last response that used that connection. This happens regardless of whether the requests take place in a loop or not.