Busty requests

unjc email unjc.email at gmail.com
Mon Jun 20 17:50:29 UTC 2011


Hi Dmitry,

Thanks so much for your reply.  After the email I had with you last
time, we figured it was some setting with the CSP that caused the
problem with the persistent connection.  Due to that, we don't need to
implement session in the workload.  However, we encountered another
problem (that is what Kevin Harris described in his last email).   We
will try to send you a copy of our workload and hope you can help us
sort out what is causing the bursting requests.

As like Kevin said, we are testing NTLM authentication with persistent
connection value set to 30.   We have set a constant request rate for
robots in the test.   I suppose you will see the details of the test
by the time we send you the workload file.

Greatly appreciate your help again.



Thanks,
Jacky


On Mon, Jun 20, 2011 at 11:07 AM, Dmitry Kurochkin
<dmitry.kurochkin at measurement-factory.com> wrote:
> 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