Busty requests

Dmitry Kurochkin dmitry.kurochkin at measurement-factory.com
Mon Jun 20 15:07:31 UTC 2011


Hi Jacky.

On Mon, 20 Jun 2011 10:02:19 -0400, unjc email <unjc.email at gmail.com> wrote:
> We are testing the NTLM authentication with 200 robots workload and
> slowly ramp it up. We saw 120 bursting new requests from new
> connections in 1 second at around 10th minutes, which overloaded the
> authentication helpers in Squid.
> 
> It seems like the robots are clumping together with their
> authentication requests… we are reauthenticating about every 30
> seconds, so we don’t expect to see more then a handful of
> authentication requests in any one second, but we are seeing them very
> bursty.
> 
> I hope this is clear enough that you might be able to shed some light.
> 

Can you give more details on how reauthentication works?  IIRC we
suggested you several options, but I do not know which one you
implemented.  In the last email you asked me about how to configure
Robot sessions, so I assume you use sessions to make Polygraph
reauthenticate itself and workaround the issue originally reported by
Jacky.  If this is the case, than sessions are likely what is causing
the problem.  If session busy_period goal is time-based
(i.e. busy_period.duration is set) and a constant idle_period_duration,
e.g.:

  Session S = {
    busy_period.duration = 30sec;
    idle_period_duration = const(10sec);
  };

Polygraph restarts all Robots every 40sec.  There is no randomness, all
Robots would be started at the same time (well, not exactly the same,
but very close, especially if you are using a single Polygraph process).

If this is the problem indeed, you may try to use a non-constant
distribution for idle_period_duration.

Regards,
  Dmitry

> 
> 
> Thanks in advance for any help you can offer,
> Jacky



More information about the Users mailing list