Which recommendations can help ensure load-testing HTTP requests are evenly distributed across the four webservers?

A startup s photo-sharing site is deployed in a VPC. An ELB distributes web traffic across
two subnets. ELB session stickiness is configured to use the AWS-generated session
cookie, with a session TTL of 5 minutes. The webserver Auto Scaling Group is configured
as: min-size=4, max-size=4. The startups preparing for a public launch, by running
load-testing software installed on a single EC2 instance running in us-west-2a. After 60
minutes of load-testing, the webserver logs show: Which recommendations can help ensure
load-testing HTTP requests are evenly distributed across the four webservers? Choose 2
answers.

A.
Re-configure the load-testing software to re-resolve DNS for each web request.

B.
Use a 3rd-party load-testing service which offers globally-distributed test clients.

C.
Configure ELB and Auto Scaling to distribute across us-west-2a and us-west-2c.

D.
Configure ELB session stickiness to use the app-specific session cookie.

E.
Launch and run the load-tester EC2 instance from us-east-1 instead.

22 Comments on “Which recommendations can help ensure load-testing HTTP requests are evenly distributed across the four webservers?

  1. Sandeep says:

    CD is my answer

    A – this option is ruled our because DNS is used only when there is cross region traffic distribution

    B – This is also ruled out again because its speak about globally distributed clients

    c:- I have ruled out this option because it speaks about running a load tester only from one
    instance.

    Please share your views

    1. Baibhav Vishal says:

      https://aws.amazon.com/articles/1636185810492479
      When Elastic Load Balancing scales, it updates the DNS record with the new list of IP addresses. To ensure that clients are taking advantage of the increased capacity, Elastic Load Balancing uses a TTL setting on the DNS record of 60 seconds. It is critical that you factor this changing DNS record into your tests. 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.

      Sticky Sessions
      Elastic Load Balancing has features that support sticky sessions (also known as session affinity) using cookies. By default, these features are disabled, and enabling them is a simple change. There are two types of stickiness policies that you can use, but the net effect is the same. If the elastic load balancer has sticky sessions enabled, this traffic will be routed to the same back-end instances as the user continues to access your application. When you design your load tests and are using sticky sessions, it will be important to decide how you will test this feature. Consider how sticky sessions can be an issue in both load testing and in the real world.

      Considering both paras from Aws site, the answer should be a,b. Reason- Test needs to be global, and requests are from various users, so Dns resolution should occur with each requests

  2. Balsak says:

    Read this: https://aws.amazon.com/articles/1636185810492479

    “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.”

  3. Duck Bro says:

    A,B

    D is not coorect
    http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
    The key to managing sticky sessions is to determine how long your load balancer should consistently route the user’s request to the same instance. If your application has its own session cookie, then you can configure Elastic Load Balancing so that the session cookie follows the duration specified by the application’s session cookie. If your application does not have its own session cookie, then you can configure Elastic Load Balancing to create a session cookie by specifying your own stickiness duration.

  4. BDA says:

    A, B

    A – you will need to ensure clients re-resolve DNS to utilize IP’s of both 2a and 2b EC2
    B – use a globally distibuted client strategy to ensure your stickiness doesn’t get you stuck routing all traffic to 2a, despite available capacity in 2b

    C is wrong, there is no mention of a 2c
    D is wrong , there is no mention of an app-generated cookie
    E is wrong, using only one availability zone for the load tester will result in the same traffic shaping, unless DNS is re-resolved in A

    your thoughts?

  5. evgeni says:

    A, B (if you read through https://aws.amazon.com/articles/1636185810492479)

    C is wrong since ELB traffic is already distributed across us-west-2a and us-west-2b
    D is wrong since session affinity doesn’t help to distribute the traffic – `If the elastic load balancer has sticky sessions enabled, this traffic will be routed to the same back-end instances as the user continues to access your application`. Thus it just ensures that the last request will go to the same server as the first one of the same user.
    E is wrong, a different AZ does not help if DNS is not re-resolved.

  6. geek says:

    A.
    Re-configure the load-testing software to re-resolve DNS for each web request. >>> RIGHT ….we all agree on this

    B.
    Use a 3rd-party load-testing service which offers globally-distributed test clients.>> RIGHT

    Load Testing with Session Affinity
    If your configuration leverages session affinity, then it is important for the load generator to use multiple clients, so that Elastic Load Balancing can behave as it would in the real world. If you do not make these adjustments, then Elastic Load Balancing will always send requests to the same back-end servers, potentially overwhelming the back-end servers well before Elastic Load Balancing has to scale to meet the load. To test in this scenario, you will need to use a load testing solution that uses multiple clients to generate the load.

    C.
    Configure ELB and Auto Scaling to distribute across us-west-2a and us-west-2c. >>>WRONG
    – since if you see in graph, request from private beta users is already going across 4 servers

    D.
    Configure ELB session stickiness to use the app-specific session cookie. >> WRONG
    Session Stickiness is still there,

    E.
    Launch and run the load-tester EC2 instance from us-east-1 instead. >> WRONG

    even if we launch from another region, it will still result the same (Session Stickiness)

    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


Leave a Reply

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