Or using a IP spoofing tool at the client side should server the purpose during load tests.
-Chaitanya M Bhatt On Wed, Apr 21, 2010 at 6:07 PM, 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 > > > > >
