On Tue, Jun 10, 2003 at 02:00:28PM -0500, kfogel@collab.net wrote:
> "Sander Striker" <striker@apache.org> writes:
> > While thinking about caching the parsed access file for mod_authz_svn,
Isn't there a way to get that stuff integrated more tightly with httpd's
configuration? It has all the support needed for specifying locations,
merging config options, inheritance of config, etc. It kind of sucks to have
Yet Another Config Format.
If you don't want to integrate with Apache's config, then how about using
svn_config instead? You're binding against mod_dav_svn, which means that
you've got libsvn_subr in your process space anyways. This approach would
probably work for svnserve, too.
+1 on integrating with httpd.conf
+0 on a separate .conf
> > a little light went on. We could keep the fs environment open during
> > an entire connection, instead of opening/closing it per request.
> > Typically, a svn client does most of its actions all over one connection
> > (two at most), so we can probably abuse the connection pool for this.
> > This could be a major saver.
>
> !
>
> Hmmm, I wonder, was there some reason we didn't do it that way
> originally?
Each request should be considered stateless. It is very hard to scale the
server when you start loading up the per-connection cost. Note: this only
applies in-between requests -- when a request *is* being processed, an FS
will be open, which matches the footprint of a connection-cached FS. The
trick is to figure out the concurrency here. Depending upon your load, the
connection-cache could keep 10 FS's open, while the per-request peaks at
(say) 2 FS's open at a time.
That said, it is also hard to scale up the server when it opens/closes the
FS on each request :-)
Lastly, if somebody *does* want to tackle a per-conn FS, then it needs to be
keyed by the repository path (and stop and think before you say "key it by
the UUID"). A single connection can quite legally talk to multiple
repositories on the server, so we need to account for that.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 10 23:11:32 2003