Amazon Load balancing issues

Start your free, no-risk, 4 week trial!

Amazon Load balancing issues

As we move a greater number of services towards the cloud (Amazon Web Services) we pioneer our way into an brand new universe of opportunity. We also come across technical issues for which no documentation exists on the internet (we know sounds a bit like Star Trek and Lucasfilm). So we are learning every day, which makes this process very enjoyable.

To give an example, take amazon’s Load Balance service (ELB).
We moved some of our script-serving traffic to an auto-scaling load balancer and watched the results with all types of monitoring tools. The response time is fantastic! On their instances, the scripts are served in 0.15 seconds, our previous provider (one of the largest of the US / world) served scripts in 0.20 seconds. Thats a 25% speed increase !!

There is, however, a downside: Once in a while it takes 1.5 seconds to load a script. We are currently investigating with amazon why this is happening, the explanation appears related to keeping tomcat conncections alive.
There is no reason for us to keep connections alive on a stand-alone server, but with the instances talking to the load balancer only, keeping the connections open could be a another speed increase. Our main concern of course is random spike in loading time, but we’re confident to figure it out pretty soon.

UPDATE:
after some conversation with Amazon techies it seems we have resolved the issues.

Here’s some things they they wrote: ”

The load balancer tries to reuse persistent connections if the instance speaks HTTP/1.1. In this case, the load balancer may end up using a stale connection because the instance did not send the “Connection: close” header. This race condition may also have something to do with the non-2xx responses.

For HTTP load balancing, the keep-alive setting is a per-connection setting. What I mean by this is, When you change the setting on your web server, it affects the connection between ELB and your server. It does not have any affect on the connection from the client to ELB. So, although you may only expect your ultimate clients to each make single infrequent requests, ELB ends up concentrating requests from many clients over a smaller number of connections if you allow connection persistence on your server. This will offload much of the connection work from your server and also make better use of the available bandwidth. “

So We did some more test with keep-alive but nothing seemes to really help

Eventually we set our

maxKeepAliveRequests=”1″

as that gave us the best performance.

from tomcat documentation:
maxKeepAliveRequests
The maximum number of HTTP requests which can be pipelined until the connection is closed by the server. Setting this attribute to 1 will disable HTTP/1.0 keep-alive, as well as HTTP/1.1 keep-alive and pipelining. Setting this to -1 will allow an unlimited amount of pipelined or keep-alive HTTP requests. If not specified, this attribute is set to 100.

UPDATE 2:
One thing to mention though is that after i gave it some weeks of rest, and accepting the random lag, i did the test again and almost all the lag is gone !!

Not sure if amazon changed anything or that the loadbalancer ‘learned’ how much connections were needed. but you dont hear me complaining.

Start your free, no-risk, 4 week trial!

Setting up tomcat 6 with APR and ssl

Start your free, no-risk, 4 week trial!

Setting up tomcat 6 with APR and ssl

Last week i had to configure a new tomcat server to work with ssl and the apr libary, i’m going to put my notes here cause it took me some time to figure it all out, and maybe it will help some other people too

Step 1. update your server to ahve all the nessacary stuff
We need OpenSSL including the devel-libs and ofcourse the APR libs

yum install openssl openssl-devel apr apr-devel

Step 2. Building the tomcat-native-apr libs
I assume you have a working tomcat allready installed, mine is in /home/tomcat change it to your tomcat home dir
you need to unpack the  sourcefiles located in your tomcathome/bin directory

cd /home/tomcat/bin/
tar xvfz tomcat-native.tar.gz

go to  the building directory

cd tomcat-native-*/jni/native/

configure and make the lib files with the path to your apr-config and the openssl libs

./configure –with-apr=/usr/bin/apr-1-config –with-ssl=/usr/lib/openssl
make
make install

Step 3. Having tomcat find your APR libs
Tomcat needs to know the location of the APR libaries, so you need to add the following line to your startscript or

-Djava.library.path=/usr/local/apr/lib

restart tomcat and you should be done!

Start your free, no-risk, 4 week trial!

Setting up a auto scaling, load-balanced, webserver with Amazon

Start your free, no-risk, 4 week trial!

Setting up a auto scaling, load-balanced, webserver with Amazon

Step 1. Define your loadbalancer
As of now, Amazon only supports 2 ports: the default web-traffic on port 80 and ssl secure https traffic on port 443.

Unfortunatly you need to choose 1 of them,  but i hope they will change it in the future. You also need to select a availabilityzone, make sure your servers are in the same zone..

elb-create-lb LoadBalancerNameHere –headers –listener “lb-port=80,instance-port=8080,protocol=HTTP” –availability-zones YourPreferedZone

Step 2. Define your LaunchConfiguration
The  LaunchConfiguration stores the ami you want to autoscale and the instancetype to go with that

as-create-launch-config LaunchConfigurationNameHer –image-id YourAmiIdHere –instance-type YourInstanceTypeHere

Step 3. Define your AutoScalingGroup
Your AutoScalingGroup combines the data from the previous 2 steps and adds the minimum and maximum amount of instances you want the auto-scaling mechanism to launch

as-create-auto-scaling-group AutoScalingGroupNameHere –launch-configuration LaunchConfigurationNameHere –availability-zones YourPreferedZone –min-size 1 –max-size 5 –load-balancers LoadBalancerNameHere

Step 4. Defining your trigger and launching it all
From the moment you define your trigger, Aws will launch what you have defined.
This example wil launch 1 instance with a trigger to add one instances to maximum of 5 when the 1 minute average CPU load has become higher than 80% for 10 minutes, and will scale down with one instance when the CPU load of the instances has been lower than 40% for 10 minutes

as-create-or-update-trigger –trigger TriggerNameHere –auto-scaling-group AutoScalingGroupNameHere –namespace “AWS/EC2” –measure CPUUtilization –statistic Average –dimensions “AutoScalingGroupName=AutoScalingGroupNameHere” –period 60 –lower-threshold 40 –upper-threshold 80 –lower-breach-increment=-1 –upper-breach-increment 1 –breach-duration 600

Step 5. Monitor and finetune
You can use the folowing to check and monitor if your setup is working

as-describe-scaling-activities AutoScalingGroupNameHere

as-describe-triggers AutoScalingGroupNameHere

Start your free, no-risk, 4 week trial!