Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 12 Aug 2015 00:51:49 +0200
From: Stefan Sperling <stsp@elego.de>
To: Thorsten =?iso-8859-1?Q?Sch=F6ning?= <tschoening@am-soft.de>
Cc: users@subversion.apache.org
Subject: Re: mod_dav_svn: httpd hangs when using PerlAuthenHandler
Message-ID: <20150811225149.GJ30785@ted.stsp.name>
Mail-Followup-To: Thorsten =?iso-8859-1?Q?Sch=F6ning?=
 <tschoening@am-soft.de>,
	users@subversion.apache.org
References: <321667472.20150811235124@am-soft.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <321667472.20150811235124@am-soft.de>
User-Agent: Mutt/1.5.23 (2014-03-12)

On Tue, Aug 11, 2015 at 11:51:24PM +0200, Thorsten Sch�ning wrote:
> Hi all,
> 
> I'm serving some repos using mod_dav_svn and svnserve, but don't want
> to maintain two configuration files with user accounts. I therefore
> had a look into PerlAuthenHandler to parse the passwd file of svnserve
> on my own and use that. During some tests I encountered the problem
> that most of the checkouts didn't finish properly, instead the process
> just seemed to hang. In the logs of httpd with a high trace level I
> could see that some RequireAny status wasn't satisfied, so there
> seemed to be some problem with authorization, but the logs of my
> PerlAuthenHandler looked OK: It got called several times, authorized
> the user and succeeded as expected. svn client was often downloading
> data during the checkout as well, so it at least partly succeeded. I
> had the feeling that httpd was stuck somewhere between recognizing
> that authorization is needed and calling my PerlAuthenHandler...
> 
> After hours of testing and debugging I think I found the problem: The
> number of Perl interpreters configured for the VHOST I use. Using the
> default settings[1] the problem occurred very often, but not always,
> using a configuration of only 1 interpreter to use at any time the
> problem occurred always and configuring 10 interpreters the problem
> didn't occur ever. I don't know why this happens because the VM I've
> tested has only 2 CPUs and can't process more than two things in
> parallel at all, so the default number of Perl interpreters with 3
> should be more than enough. But for some reason it isn't...

Hi Thorsten,

I don't think the number of CPUs matters much.
In HTTPD, each incoming request is queued to a particular "worker" which
can be a thread or a process, depending on the MPM in use.

To keep serving requests you'll need sufficient worker capacity.
If all your workers are stuck in perl interpreters there's nothing
much HTTPD can do but wait for them to complete.

So if you're using Perl interpreter threads (which map 1 interpreter instance
to 1 thread) combined with a threaded MPM, you'll probably need as many perl
interpreter instances as the number of worker threads you have configured.

It seems PerlInterpMax is the most important setting in your case since
it effectively sets the high bar of your worker threads doing authentication
tasks. The default is 5. Did you already try raising that?

Also note that SVN clients will have to re-authenticate occasionally
based on MaxKeepAliveRequests and KeepAliveTimeout settings.
Perhaps raising those settings will fix your problem since your perl-based
auth handler will be invoked less often.

> So my question is:
> 
> How does SVN decide how many requests to issue in parallel?

The serf library may decide to send several requests in parallel (i.e. send
another request before the answer to the last request has been received).
As I understand, this feature is not under control of the SVN client itself.
serf processes replies from the server one-by-one as they come in and passes
them to the svn client. serf assumes the HTTPD server is multi-threaded and
capable of supporting parallel requests efficiently.