jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Oberman <ober...@gmail.com>
Subject Re: jmeter + amazon ec2 + load balancing (elb)
Date Wed, 21 Apr 2010 12:37:48 GMT
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 <sebbaz@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 <brettcave@gmail.com> wrote:
> > Hi William,
> >
> >  Thanks for the feedback. Have 1 question:
> >
> >
> >  On Tue, Apr 20, 2010 at 10:12 PM, William Oberman <oberman@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-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message