[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

general server performance (was Re: apache svn server memory usage?)

From: Chris Hecker <checker_at_d6.com>
Date: 2003-07-01 11:26:03 CEST

>Caching doesn't help you when you have to fsync the database log files
>at every transaction commit.

Right, but even checkouts seem pokey...are they considered transactions as
far as disk syncing as well (I assume not)? Also, is there any way to
trade risk for performance, and have it not sync to disk as often, or
schedule it for the background, etc.? But even ignoring that, what
explains why the net throughput is so low?

Some quick empirical data (totally unscientific) on a fresh checkout:

4m3s "time svn co https://blah dir"
201 files (excluding all .svn/ files) (6kb median size, 63k average size
12.8mb non-.svn uncompressed file size sum
145kb sent/1.5mb received total net traffic during co
tar.gz of all non-.svn files 1.3mb (so the server->client compression is
working well)
6kb median size, 63k average size uncompressed

Taking the 1.5mb / 4m3s gives only 6.4kbps. HTTP downloads over the same
SSL connection to this server using wget acheive a steady 110kbps, so svn's
utilization is not great.

I should be clear that I'm not complaining here, I know svn is still in
development, premature optimization and all that. I'm just wondering if
there's something I've screwed up as the server admin or if this is all
stuff that code changes will be necessary to fix.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 1 11:27:16 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.