Return-Path: Delivered-To: apmail-jakarta-jmeter-user-archive@www.apache.org Received: (qmail 10399 invoked from network); 21 Apr 2010 12:40:01 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Apr 2010 12:40:01 -0000 Received: (qmail 78980 invoked by uid 500); 21 Apr 2010 12:40:00 -0000 Delivered-To: apmail-jakarta-jmeter-user-archive@jakarta.apache.org Received: (qmail 78929 invoked by uid 500); 21 Apr 2010 12:39:59 -0000 Mailing-List: contact jmeter-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "JMeter Users List" Reply-To: "JMeter Users List" Delivered-To: mailing list jmeter-user@jakarta.apache.org Received: (qmail 78921 invoked by uid 99); 21 Apr 2010 12:39:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Apr 2010 12:39:59 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of oberman@gmail.com designates 72.14.220.157 as permitted sender) Received: from [72.14.220.157] (HELO fg-out-1718.google.com) (72.14.220.157) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Apr 2010 12:39:53 +0000 Received: by fg-out-1718.google.com with SMTP id e12so2845720fga.13 for ; Wed, 21 Apr 2010 05:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:content-type; bh=D2wi3eajmy9sn8WVwI8uVOuyr7BbKUuxdJcxk8CTJjo=; b=dxy712T95mhqc9L3V8l4gmoZPQ2Kaeat4M0VDcHT1470Bl+RZzgnmaOS2JfR0f1CSC z3J6IVtLf+tdScDlI9GJBaJ/dLU6DJxg2XDOGGD4uQ2mpwi/1Bn52qirms9UjPNcW6PU vbhwvoKlrTejni0ADHFmRl6DEuMM4j6Ai70yU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=tW4h89OrzvhKKKfLMWV9Zvi2xaol1RFl+Z7YmwiEnpt88kKC9M2lI5ApUO531FwKkT qm+rYiy9ihA2NRXLWClE0nj0DgsK/m4JOVlipCLsU7N4M/KXfu+DqHPQAOd4Jbfgptl4 zBctgvQijjVYYu0lyFixNZZ10VCIUOWHv/5EY= MIME-Version: 1.0 Received: by 10.223.125.133 with HTTP; Wed, 21 Apr 2010 05:37:48 -0700 (PDT) In-Reply-To: References: From: William Oberman Date: Wed, 21 Apr 2010 08:37:48 -0400 Received: by 10.223.92.153 with SMTP id r25mr1034165fam.76.1271853488569; Wed, 21 Apr 2010 05:38:08 -0700 (PDT) Message-ID: Subject: Re: jmeter + amazon ec2 + load balancing (elb) To: JMeter Users List Content-Type: multipart/alternative; boundary=00151747b640647d1f0484be776a X-Virus-Checked: Checked by ClamAV on apache.org --00151747b640647d1f0484be776a Content-Type: text/plain; charset=ISO-8859-1 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 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 wrote: > > Hi William, > > > > Thanks for the feedback. Have 1 question: > > > > > > On Tue, Apr 20, 2010 at 10:12 PM, William Oberman > 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-unsubscribe@jakarta.apache.org > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org > > --00151747b640647d1f0484be776a--