So I'm jumping into issue 773, which is all about making mod_dav use
pools efficiently. The theory is that at the moment, when it responds
to a depth-1 PROPFIND, it uses a single pool to walk over all the
children. If a directory contains 1000 children, then this causes the
httpd process to use hundreds of megs of memory. Poof, suddenly
nobody can checkout the large directory.
But I'm just not seeing this happen. I'm doing some testing using svn
HEAD (r6090, 0.23+) and httpd-2.1 HEAD.
I create a repository with a single /trunk directory containing 1000
files. When I do an 'svn co http://localhost/...', my httpd process
only grows to 23M, not 500M as the issue might suggest. The *real*
problem seems to be the non-streamy 207 response; neon times out
waiting for 2-3 minutes unless you increase the timeout.
(There's still issue #1293, where Frank Hodum claims that his svn
client slowly leaks during large checkouts. I've noticed this too;
when checking out 1000 files, my svn client slowly grew from 5M->11M,
seemingly without bound. But it was very slow, and not
earth-shattering either. And this is a separate bug in the svn client
anyway.)
So I'm bit skeptical at the moment. It doesn't seem that mod_dav's
memory usage is a 3-alarm fire anymore. In retrospect, almost every
complaint I've heard over the last few months is that "neon times out"
when waiting for a large directory to arrive.
I'm not sure it's worth spending a few days changing mod_dav pool
usage, just to bring httpd from 22M down to 10M, or whatever.
Subversion users certainly won't notice the difference. Instead, it
seems like I should be tackling the streaminess problem; *that* would
be noticeable by everyone.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 29 21:55:00 2003