Busty requests

[unjc email]

Hi Dmitry,

I am not sure if you have received the workload file from my work
email.  If not, attached is the pg file we are using for our CSP test.
 Could you please have a look and see if there is any problem with the
setup that causes the bursty traffic.



Thanks,
Jacky


On Mon, Jun 20, 2011 at 1:50 PM, unjc email <unjc.email at gmail.com> wrote:
> 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
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CSP_constant_load_M1.pg
Type: application/octet-stream
Size: 10761 bytes
Desc: not available
URL: <http://lists.web-polygraph.org/pipermail/users/attachments/20110621/6aaf0f8a/attachment.obj>