Amazon ELB HTTPS Stickiness

Stickiness is needed in most of the complex applications when scaled up in cloud. Say one user logs in. Now his information should be attached to him. If not, each time, he would be routed to a random instance, which will not identify him. Attaching a session id would provide the stickiness, where a particular user can be forwarded to the particular instance. 

I tried using amazon elb-api commands using terminal to enable stickiness for the elastic load balancer. it gave error when trying to apply the stickiness for the port 443, and works fine for 80.

Create Stickiness Policy
pradeeban@pradeeban:~/pem$ elb-create-app-cookie-stickiness-policy wso2cloud1-as -p my-app-cookie-lb-policy -c jsessionid -K KEY.pem -C CERT.pem
OK-Creating App Stickiness Policy

Setting the Policy to the Listener - Fails for port 443
pradeeban@pradeeban:~/pem$ elb-set-lb-policies-of-listener wso2cloud1-as --lb-port 443 --policy-names my-app-cookie-lb-policy -K KEY.pem -C CERT.pem
elb-set-lb-policies-of-listener: Service error: aws:Client.InvalidConfigurationRequest AWSRequestId:4b2c7fc3-4fbf-11e0-a778-d17858cabec6

Setting the Policy to the Listener - Works for port 80
pradeeban@pradeeban:~/pem$ elb-set-lb-policies-of-listener wso2cloud1-as --lb-port 80 --policy-names my-app-cookie-lb-policy -K KEY.pem -C CERT.pem
OK-Setting Policies

So it seemed, it was an issue with https/stickiness from the amazon's end. It was not giving any error when tried with amazon management console nevertheless, but simply not allowing to enable stickiness for the listener with the tcp protocol.

It works for --lb-port 80 --lb-port 443, but not for --lb-port 443 --lb-port 80 (since it picks the first entry only, it seems).

Tried the same with elb-create-lb-cookie-stickiness-policy (elb controlled stickiness) and the results was same.

So I felt, https/stickiness is not working for both application based or amazon elb based cookies, while it works for http.


But Amazon announced in Oct, 2010 that they have started supporting HTTPS stickiness.


I reported this in AWS forum, but later found that it (Setting stickiness policy) works. What we had to change was the protocol to https from tcp for the port 443.

--listener "lb-port=443,instance-port=9443,protocol=https"

HTTPS/Stickiness is fine with Amazon's, but not TCP/Stickiness. The TCP/Stickiness issue has already been discussed in another thread [1] in AWS forums. Hence we resolved the issue, by changing the protocol from TCP to HTTPS for the port 443. However we also noted that aiCache provides web application HTTPS acceleration and stickiness for TCP too.

[1] Service error when setting LB policies of listener
[2] Elastic Load Balancing with Sticky Sessions
[3] Amazon Makes the Cloud Sticky
[4] jmeter + amazon ec2 + load balancing (elb)
[5] How can I force "non-sticky" connections for my ELB? 
[6] Load Balancer (ELB) - port forwarding on the load balancer itself
[7] "Sticky connection" on ELB for https?  
[8] Using ELB to Serve Multiple Domains Over SSL on EC2 for Giggles and Unicorns
[9] Amazon Simple Monthly Calculator

Performance Testing and WSO2 Carbon

Finally we were wrapping up the Messagebox program we had created using Apache Axis2. Now comes the final point. Yes, we had to do a performance analysis using Apache Jmeter. Our Messagebox program has four operations: createMessagebox, storeMessages, takeMessages, deleteMessagebox. Being a web service, we have the axis2 archive (.aar) of our program.

We have developed a client to run our web service. Given the WSDL, wsdl2java will auto-generate the Client Stub and the Server Skeleton. Completing server skeleton with the necessary logic obviously has cost a much longer time, when compared with the writing of client code using the client stub. Now during the performance testing, we are going to use the same web service, but we will not use the client we have developed. Rather we will be using our test plan generated using JMeter, as the client to run our server. Now we need SOAP/XML-RPC Request for each operation.

This Jmeter performance analysis will be saved as a .jmx file. In the Admin Console of WSO2 WSAS (Web Services Application Server or WSO2 Application Server), we have "Add Axis2 Service" option in the left hand side panel. I uploaded our aar using that Add option. A success message appeared as expected. Then I clicked the List Menu for deployed services. There I clicked Try this service option for the MsgBoxService. I was taken to the Try the MsgBoxService service. 

WSAS has a nice GUI with textboxes to input the values. Getting the output instantly, I was walking through WSAS to see more. Found something under the monitor menu. SOAP Tracer! I configured the Configuration Status to ON. A warning says “Tracing will have a performance hit. Use with caution.” I will not overuse this functionality however. Then I went back to try the service. After trying all the four operations, I came back to the SOAP Tracer. SOAP messages for both the request and the response. Then it took me just minutes to copy-paste those SOAP messages for the four operation requests, into the respective SOAP/XML-RPC Request of Jmeter.

The conclusion of the performance analysis was not much difficult after that. Just adding a variable in place of the input value, a counter to have about 1000 users each user as a thread, timer, Loop Controller to send 10 msg for each user’s msgbox, and finally Graph results to see the performance of each operation visually.