On Tue, Nov 13, 2012 at 2:48 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Tue, Nov 13, 2012 at 2:44 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>> On 13.11.2012 14:58, Mark Phippard wrote:
>>
>>> We did some testing in our lab, and the KeepAlive settings help a lot
>>> here. Without any KeepAlive, then obviously every Serf request on
>>> every connection needed to be re-authenticated. With KeepAlive on and
>>> the connection limit set high enough then it was reduced to just the 4
>>> connections that Serf opens to the server. So for our case, making
>>> sure this was in place on our server, and then doing some more testing
>>> to figure out the increases we needed to make in our backends was the
>>> main issue to deal with.
>>
>>
>> Did you do some testing with Windows domain authentication as well? Because
>> last time I did some testing with that, KeepAlive doesn't do anything there.
>> For some setups (for example, if the user GUEST is enabled on the domain
>> controller) the re-authentication traffic is more than double the normal svn
>> traffic.
>
> No, we only tested with our own mechanism to make sure that KeepAlive
> would lessen the connection problem. With any mechanism, there would
> have to be some kind of decent caching mechanism in place to not flood
> the server with auth requests. I believe mod_ldap has one by default:
>
> http://httpd.apache.org/docs/2.2/mod/mod_ldap.html#ldapcacheentries
>
> Are you talking about mod_sspi? I do not know much about that module.
Sounds like it depends on whether you have added:
SSPIPerRequestAuth on
It looks like that is off by default, which means the auth request is
only done once per connection and KeepAlive should help limit that.
If this directive is on, then every HTTP request will generate the
SSPI authorization. That does seem to me like it would be a big
problem when using Serf clients and performing a checkout.
http://code.google.com/p/mod-auth-sspi/source/browse/trunk/src/mod_auth_sspi.c#68
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-11-13 21:03:36 CET