Brett: just so you know, I started a thread over in AWS's forums on this issue: https://developer.amazonwebservices.com/connect/message.jspa?messageID=175221#175221 No one has responded yet. If anything comes up, I'll reply here (and add to the wiki).
will On Wed, Apr 21, 2010 at 8:37 AM, William Oberman <ober...@gmail.com> wrote: > Brett: yes, I saw amazon recently added two levels of stickiness (load > balancer, and application). I have both disabled. I was referring to TCP > stickiness, though my only attempt to test it was using HTTP over TCP. I've > mentally ruled out the new stickiness feature as the problem because I don't > get a consistent backend using different load balancer IPs from the pool > (and, I'd assume that true stickiness would be global). But I did get > stickiness on a per-load balancer IP basis. Even though my evidence is all > observation based, I'm in 100% agreement with "According to user reports in > other forum posts, clients from a single IP address will tend to be > connected to the same back-end instance.". This is due to the fact that at > the exact moment my DNS resolved to a new LB from the pool, all connections > switched to a new backend instance every single time. All I want (and need) > is "anti-stickiness" at all levels, including on a individual load balancer > basis.... If there is no real solution, I'm left with switching providers, > or installing my own load balancer (HAProxy, nginx are early hits on load > balancer + ec2, and I've configured HAProxy before). On a different note, > you mentioned you're doing HTTPS (which is load balanced at the TCP level). > As a FYI, you do know amazon isn't doing SSL termination, so you _can't_ do > proper sticky load balancing, and you'll lose the client IP address. > > Sebb: I'm fairly new to using Jmeter, but I'd be happy to try and figure > out where in the wiki to add this information. The page on processing > results was very helpful for me. > > will > > > > On Wed, Apr 21, 2010 at 6:11 AM, sebb <seb...@gmail.com> wrote: > >> May I suggest that the findings are added to the JMeter Wiki? >> >> This will make it easier to find, update and refer to later. >> >> On 21/04/2010, Brett Cave <brettc...@gmail.com> wrote: >> > Hi William, >> > >> > Thanks for the feedback. Have 1 question: >> > >> > >> > On Tue, Apr 20, 2010 at 10:12 PM, William Oberman <ober...@gmail.com> >> wrote: >> > >> > > >> > > 2.) For a given ELB IP, there seems to be a static mapping of client >> IP <-> >> > > backend instance. This is a slightly complicated statement that >> assumes a >> > > some knowledge of how amazon in general, and ELBs in particular, >> work. If >> > > it's still up, this page: >> > > >> > >> > >> > Are you referring to HTTP stickiness here, or did you find that client >> IP >> > <-> backend instance is mapped for TCP connections too? (have been >> > discussing this on the forums, and not getting an answer to this). On >> the >> > 7th of April, Amazon introduced sticky HTTP sessions on ELB (check the >> > sticky forum post for more info - >> > http://developer.amazonwebservices.com/connect/ann.jspa?annID=646). >> This >> > should result in each thread in a jmeter test plan going through to the >> same >> > node if you have a cookie manager. Then again, if there is indeed a >> static >> > mapping of client IP to instance, you would need to use multiple >> instances >> > of jmeter-server with a central controller to effectively test load >> > balancing >> > >> > One of the responses to my post contained the link below, which states >> > "According to user reports in other forum posts, clients from a single >> IP >> > address will tend to be connected to the same back-end instance." but i >> was >> > wondering if you have been able to verify this? Our scenario is greatly >> > affected by this characteristic of ELB, as our entire web app is >> > HTTPS-based. >> > >> > >> > >> > > >> > > >> http://www.shlomoswidler.com/2009/07/elastic-in-elastic-load-balancing-elb.html >> > > has pretty much everything you need to know. >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org >> >> >
