Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Improve ELB performance with these workarounds

AWS Elastic Load Balancing can improve workload performance, but has its limitations. Developers can bypass some of these constraints to improve the ELB service.

Every tool or feature has limitations, specifically in real-time scenarios. And AWS Elastic Load Balancing is no...

exception. Compared to other load balancers, such as NGINX and HAProxy, AWS ELB is easy to manage because of its friendly user interface. However, constraints do still exist, and developers should be aware of the limitations with AWS ELB performance.

Consider a scenario in which a developer has AWS Elastic Load Balancing with two NGINX back-end servers and wants to determine his clients' locations or regions according to their public IP addresses. By default, AWS Elastic Load Balancing only reports private IPs, so clients' public IPs will not appear in a server's access log or application log. However, developers can add a back-end server to their X-Forwarded configuration, as shown below, then reload the NGINX back-end server to apply changes:

/etc/nginx/nginx.conf

set_real_ip_from 0.0.0.0/0;

real_ip_header X-Forwarded-For;

real_ip_recursive on;

In this case, developers can use 0.0.0.0/0 as the ELB IP because the ELB private IP always changes. Here is a simple PHP script that can check client public IPs.

test.php

<? php

echo $_SERVER["REMOTE_ADDR"];

?>

Redirecting HTTP to HTTPS for security

AWS Elastic Load Balancing doesn't allow redirection changes, such as when site visitors try to reach unsecured (http://) URLs that are only available as secure (https//:) URLS.

However, developers can use the X-Forwarded-Proto configuration to make changes. For example, in the Nginx conf file:

if ($http_x_forwarded_proto = 'http') {

       return 301 https://example.com $request_uri;

 }

ELB latency

AWS ELB shunts traffic between servers, but gives limited visibility into its own performance. AWS ELB distributes traffic between EC2 instances according to proprietary algorithms that track instance sizes and inbound traffic patterns. However, in some cases, the system might experience higher levels of latency due to the ELB performance. Developers can use the Amazon CloudWatch metric, "Latency," to gauge ELB performance.

Despite its limitations, AWS ELB provides several advantages for developers, most notably its elasticity and easy configurability.

Another useful CloudWatch metric is "HTTPCode_ELB_5XX," which keeps track of the number of requests that could not be balanced properly, for whatever reason. However, ELB can't always identify these occurrences. And lastly, while it doesn't allow users to control the number of requests, the "Request Count" CloudWatch metric can be especially useful to calculate how many Web requests are made per minute if you notice any ELB errors.

Developers can also replace their current ELB instance or use AWS Route 53 routing policy. There are two different options for routing policies: weighted, in which traffic is distributed according to user specification, and latency, in which traffic is distributed to the data center with the lowest latency.

Limited idle timeout

ELB uses two connections for each client request: one with the back-end server and one is with the client. The load balancer triggers timeouts if no data is sent or received for a particular period of time for either connection, at which point the load balancer closes the connection(s). The default ELB connection idle timeout limit is 60 seconds, and it can be changed -- albeit not easily -- via the user interface.

Developers can increase or decrease the idle timeout value -- from one to 3,600 seconds -- by configuring connection settings:

aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionSettings\":{\"IdleTimeout\":160}}"

In the code above, "my-loadbalancer" is the ELB name. It's important to note that if a Web proxy is in the back end, developers have to change the keep-alive timeout limit and make sure "MaxClients" values are high enough to handle requests, processing times and response times.

No default ELB log store

By default, AWS ELB does not store access logs. However, users can store ELB logs in Simple Storage Service buckets for testing and troubleshooting purposes.

This sample code enables the access log and defines the S3 bucket.

aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes file://elblog.json

elblog.json

{

 "AccessLog": {

      "Enabled": true,

      "S3BucketName": "mylog",

      "EmitInterval": 60,

      "S3BucketPrefix": "my-webapp"

   }

}

ELB predominantly acts as a Transmission Control Protocol load balancer, and is relatively easier to manage than other load balancers. Despite its limitations, AWS ELB provides several advantages for developers, most notably its elasticity and easy configurability. And these workarounds could further improve ELB performance for many developers.

Next Steps

NGINX provides alternative to ELB

Deploy applications with AWS ELB

Boost availability, app performance with ELB

This was last published in February 2016

Dig Deeper on AWS CloudWatch and application performance monitoring

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What performance issues have you experienced with AWS ELB?
Cancel

-ADS BY GOOGLE

SearchCloudApplications

TheServerSide.com

SearchSoftwareQuality

SearchCloudComputing

Close