jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Strange Behaviour with JavaImpl & Load Balancer
Date Mon, 25 Mar 2013 19:38:34 GMT
On Monday, March 25, 2013, sebb wrote:

> On 25 March 2013 17:31, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>>
> wrote:
> > Hello,
> > Thanks sebb, see my notes below.
> >
> > On Mon, Mar 25, 2013 at 6:21 PM, sebb <sebbaz@gmail.com <javascript:;>>
> wrote:
> >
> >> On 25 March 2013 14:17, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>
> >
> >> wrote:
> >> > Hello,
> >> > I noticed a strange behaviour when Load Testing an application
> recently.
> >> >
> >> > There was a Load Balancer in the middle:
> >> >
> >> >    - Using Java Implementation I had around 8% of error
> >>
> >> What kinds of error?
> >>
> >> Session is lost, so it means load balancer redirects to other Apache
> > ignoring Session Stickiness.
>
> What controls the session?


A cookie one created by LB for session stickyness and one created by Apache
HttpServer

>
> Does it use cookies?

Yes

> Does it rely on the connection in any way?
>
> I don't think so. Hc do not have this issue.



> >> >    - Using HC3 or HC4 Implementations it was 0%
> >> >
> >> >
> >> > I am sure it comes from Load Balancing as if it pointed on only one
> >> Apache
> >> > then there was no issue.
> >>
> >> Note that the Java implementation may reuse connections between threads.
> >> That's one reason JMeter started using HC3 and HC4.
> >>
> >> > Now playing around with some Java System properties, I discovered that
> >> > setting  *-Dhttp.keepAlive=false* fixed the error issue:
> >>
> >> That suggests it might be the connection reuse.
> >>
> > Agree
> >
> >>
> >> > -
> >> >
> >>
> http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-keepalive.html
> >> >
> >> > Another way to fix this was to  uncheck KeepAlive checkbox in
> samplers.
> >>
> >> Likewise, that should stop cross-thread connection sharing, as it will
> >> stop any sharing.
> >>
> >> >
> >> > Now my question is:
> >> >
> >> >    - Is this regular ? It seems strange to me that HC31 and HC4 impl
> do
> >> not
> >> >    have this behaviour
> >> >    - If yes, we should absolutely document this behaviour no ?
> >>
> >> I think it is; but it could perhaps be made more obvious.
> >>
> > Where is it ? Didn't see any mention of -Dhttp.keepAlive in docs
>
> The docs don't mention the property but they do mention why the Java
> implementation is unsuitable; e.g.:
>
> >>
> The Java HTTP implementation has some limitations:
> *    There is no control over how connections are re-used. When a
> connection is released by JMeter, it may or may not be re-used by the
> same thread.
> <<
>
> Well reading this I wouldn't have thought we would face such failure.


> By all means add details of the property if you think it would help.
>
> I will.
I am not a big user of JAva Impl , had to as this same application failed
to record with HC some requests, ie when played by Http Server Proxy they
didn't return response returned by browser or Java Impl.

But I must say it came to me as a bad surprise and would like if keepalive
is not handled correctly to kind of avoid these cases by adding it to
startup script of not allowing keepAlive in this case.
But this may also only be related to this application and reveal an
underlying issue in application.
That's why I was asking about your experiences with Java Impl.


> >>
> >> >    - Could it be a JDK 7 bug ?java version "1.7.0_13"
> >>
> >> No, it's by design.
> >>
> >> In theory the connnection sharing should be OK (otherwise I assume
> >> Java would not do it), but maybe there is a subtle bug in the
> >> application that relies on independent connections.
> >>
> >> I think it is something like this or a Load Balancer issue.
> > But as it is not easy to simulate using Browser, it is hard to prove.
> >
> >> >
> >> >
> >> > Note that tested application was not perfect as it had many Content
> >> > Encoding behaviour and other non fully standard issues.
> >> >
> >> > Thanks for you notes.
> >> > Regards
> >> > Philippe
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>


-- 
Cordialement.
Philippe Mouawad.

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