You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by se...@dimensionalrift.com on 2003/02/25 05:13:05 UTC
pitiful dav performance
I've spent most of the weekend (and now most of monday due to an
ice-storm) setting up a test server with Subversion 0.18 on it. I have
configured just about every access method, and have some problems with the
dav performance, and that has me puzzled.
Machine is:
Dual Proc P3-850 Debian Linux machine
384MB RAM
Ultra2 scsi drives (x2, 7200 rpm)
100 megabit LAN (also connected via a switch to a DSL based internet
connection (768/384))
The machine is running Debian Testing with 2.4.20 kernel, and the minimum
necessary Debian unstable packages to run Subversion 0.18 (Apache2, etc).
The machine only runs sshd, qmail with near zero traffic, apache-ssl for
squirrelmail, and apache2 for subversion. No X and no other processes.
For my testing, any non-local client is always a WindowsXP machine.
The tree I check out ends up being about 4.5 megabytes, including the .svn
directory overhead. Without the overhead, its 2megs in 326 files.
Timings:
local svnserve: 0m 10s
local file: 0m 9s
local http: 3m 33s
local https: 3m 33s
remote svnserve: 0m 11s
remote http: 3m 32s
remote https: 3m 33s
Is there some magic apache2 setting I've missed somewhere?. I've played
with turning AuthType off (as well as SSL) and they have no effect on the
performance of subversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pitiful dav performance
Posted by Philip Martin <ph...@codematters.co.uk>.
Brandon Ehle <az...@yahoo.com> writes:
> >>>There are some known ra_dav performance issues, issue 773 in
> >>>particular. The first thing to determine is whether the problem is
> >>>excessive CPU use or whether it is some sort of IO problem.
>
> >>apache2 accumulated cpu time from a clean start and svn checkout, is
> >>listed as 9 seconds. Watching with top, the active apache2 thread sits
> >>around 1.8-3.8% cpu usage (which matches the 20x speed difference I am
> >>seeing between ra_svn and ra_dav), and every now and then I catch its cpu
> >>spiking up to 10% (very rare though). Memory is pretty low, with an
> >>occasional spike up to 20MB.
>
> This is a known bug of using Apache2 with DB-4.0.14
I disagree. I'm using BDB 4.0.14 and while ra_dav is slower than
ra_svn/ra_local it's nowhere near as bad as the dropoff reported
here. I know you regularly claim that BDB 4.0.14 is in some way
broken, but it's not universally true.
Anyway, in this case use Debian/testing and db4.1_recover have been
mentioned, so I assume BDB 4.1 is in use.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pitiful dav performance
Posted by Brandon Ehle <az...@yahoo.com>.
Philip Martin wrote:
>seanc@dimensionalrift.com writes:
>
>
>
>>>There are some known ra_dav performance issues, issue 773 in
>>>particular. The first thing to determine is whether the problem is
>>>excessive CPU use or whether it is some sort of IO problem.
>>>
>>>
>>apache2 accumulated cpu time from a clean start and svn checkout, is
>>listed as 9 seconds. Watching with top, the active apache2 thread sits
>>around 1.8-3.8% cpu usage (which matches the 20x speed difference I am
>>seeing between ra_svn and ra_dav), and every now and then I catch its cpu
>>spiking up to 10% (very rare though). Memory is pretty low, with an
>>occasional spike up to 20MB.
>>
>>
>
>OK, that's not issue 773.
>
>I suppose you could try using strace to identify what Apache is doing.
>Run a checkout and use top to identify the active thread attach, then
>use something like "strace -Tp <pid>" to see how much time each system
>call takes. I'm assuming that it must be blocking in a system call as
>it's not using CPU, but I'm not an Apache expert so I may be talking
>rubbish!
>
>Which Apache MPM are you using? Can you try a different one?
>
>
>
This is a known bug of using Apache2 with DB-4.0.14
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pitiful dav performance
Posted by Philip Martin <ph...@codematters.co.uk>.
seanc@dimensionalrift.com writes:
> > There are some known ra_dav performance issues, issue 773 in
> > particular. The first thing to determine is whether the problem is
> > excessive CPU use or whether it is some sort of IO problem.
>
> apache2 accumulated cpu time from a clean start and svn checkout, is
> listed as 9 seconds. Watching with top, the active apache2 thread sits
> around 1.8-3.8% cpu usage (which matches the 20x speed difference I am
> seeing between ra_svn and ra_dav), and every now and then I catch its cpu
> spiking up to 10% (very rare though). Memory is pretty low, with an
> occasional spike up to 20MB.
OK, that's not issue 773.
I suppose you could try using strace to identify what Apache is doing.
Run a checkout and use top to identify the active thread attach, then
use something like "strace -Tp <pid>" to see how much time each system
call takes. I'm assuming that it must be blocking in a system call as
it's not using CPU, but I'm not an Apache expert so I may be talking
rubbish!
Which Apache MPM are you using? Can you try a different one?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pitiful dav performance
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
seanc@dimensionalrift.com wrote:
>>seanc@dimensionalrift.com wrote:
>>
>>
>>
>>>I would be willing to go with the ra_svn approach but it doesnt seem
>>>possible to secure it in a meaningful manner for a multi-user
>>>configuration. Perhaps if svnserve were to run exclusively on 127.0.0.1
>>>and a proxy program (say, svnproxy) could be executed via rsh or plink
>>>
>>>
>>>from my clients I could at least secure it in the same way as CVS.
>>
>>
>>uh, you can already tunnel ra_svn over ssh, just as one normally does
>>with CVS. there's no reason to run svnserve in daemon mode if you don't
>>want to.
>>
>>-garrett
>>
>>
>>
>>
>
>The database has never let me do that. I've had to run db4.1_recover any
>time the user changes on the database. I.e:
>
>As root I create /usr/local/svn and chown it to root:svnusers, and chmod
>it g+s
>As user 'foo' I run svnadmin create testdb, from /usr/local/svn
>As user 'foo' I can access the database
>Access with any other user, Permission denied: Berkeley DB error
>while opening environment for filesystem /usr/local/svn/testdb until I
>run db4.1_recover on the database as that user. chown'ing the directory
>to that user fully does not help. I have to run db recover. This
>included getting the www-data user to work so that apache could access the
>database.
>
that's a separate problem. when you run svnserve you need to be sure
that your umask is set correctly so that files you create can be
read/written by all the users who need to access the database. this
generally means making sure all the accounts are members of the same
group and making the repository owned by that group. in you don't want
to have your users set their umask to make things group writable by
default, you can work around it by using a wrapper script instead of
svnserve which sets the umask correctly and then calls svnserve. there
are several examples of how to do this in the archives, i don't have one
handy at the moment.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pitiful dav performance
Posted by se...@dimensionalrift.com.
> seanc@dimensionalrift.com wrote:
>
>>I would be willing to go with the ra_svn approach but it doesnt seem
>>possible to secure it in a meaningful manner for a multi-user
>>configuration. Perhaps if svnserve were to run exclusively on 127.0.0.1
>>and a proxy program (say, svnproxy) could be executed via rsh or plink
>>from my clients I could at least secure it in the same way as CVS.
>>
>
> uh, you can already tunnel ra_svn over ssh, just as one normally does
> with CVS. there's no reason to run svnserve in daemon mode if you don't
> want to.
>
> -garrett
>
>
The database has never let me do that. I've had to run db4.1_recover any
time the user changes on the database. I.e:
As root I create /usr/local/svn and chown it to root:svnusers, and chmod
it g+s
As user 'foo' I run svnadmin create testdb, from /usr/local/svn
As user 'foo' I can access the database
Access with any other user, Permission denied: Berkeley DB error
while opening environment for filesystem /usr/local/svn/testdb until I
run db4.1_recover on the database as that user. chown'ing the directory
to that user fully does not help. I have to run db recover. This
included getting the www-data user to work so that apache could access the
database.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pitiful dav performance
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
seanc@dimensionalrift.com wrote:
>I would be willing to go with the ra_svn approach but it doesnt seem
>possible to secure it in a meaningful manner for a multi-user
>configuration. Perhaps if svnserve were to run exclusively on 127.0.0.1
>and a proxy program (say, svnproxy) could be executed via rsh or plink
>from my clients I could at least secure it in the same way as CVS.
>
uh, you can already tunnel ra_svn over ssh, just as one normally does
with CVS. there's no reason to run svnserve in daemon mode if you don't
want to.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pitiful dav performance
Posted by se...@dimensionalrift.com.
> seanc@dimensionalrift.com writes:
>
>> Timings:
>> local svnserve: 0m 10s
>> local file: 0m 9s
>> local http: 3m 33s
>> local https: 3m 33s
>>
>> remote svnserve: 0m 11s
>> remote http: 3m 32s
>> remote https: 3m 33s
>>
>> Is there some magic apache2 setting I've missed somewhere?. I've played
>> with turning AuthType off (as well as SSL) and they have no effect on
>> the
>> performance of subversion.
>
> There are some known ra_dav performance issues, issue 773 in
> particular. The first thing to determine is whether the problem is
> excessive CPU use or whether it is some sort of IO problem.
>
> First, make sure nothing other than your subversion client is
> accessing the apache server, and then run something like
>
> $ ps aux | grep [h]ttpd
>
> before and after an ra_dav checkout. This will let you see the amount
> of CPU used by the apache processes. If apache only uses a few
> seconds of CPU then the problem is probably some sort of IO delay. If
> apache uses 3 minutes of CPU then we have some sort of scaling
> problem.
>
apache2 accumulated cpu time from a clean start and svn checkout, is
listed as 9 seconds. Watching with top, the active apache2 thread sits
around 1.8-3.8% cpu usage (which matches the 20x speed difference I am
seeing between ra_svn and ra_dav), and every now and then I catch its cpu
spiking up to 10% (very rare though). Memory is pretty low, with an
occasional spike up to 20MB.
I would be willing to go with the ra_svn approach but it doesnt seem
possible to secure it in a meaningful manner for a multi-user
configuration. Perhaps if svnserve were to run exclusively on 127.0.0.1
and a proxy program (say, svnproxy) could be executed via rsh or plink
from my clients I could at least secure it in the same way as CVS.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pitiful dav performance
Posted by Philip Martin <ph...@codematters.co.uk>.
seanc@dimensionalrift.com writes:
> Timings:
> local svnserve: 0m 10s
> local file: 0m 9s
> local http: 3m 33s
> local https: 3m 33s
>
> remote svnserve: 0m 11s
> remote http: 3m 32s
> remote https: 3m 33s
>
> Is there some magic apache2 setting I've missed somewhere?. I've played
> with turning AuthType off (as well as SSL) and they have no effect on the
> performance of subversion.
There are some known ra_dav performance issues, issue 773 in
particular. The first thing to determine is whether the problem is
excessive CPU use or whether it is some sort of IO problem.
First, make sure nothing other than your subversion client is
accessing the apache server, and then run something like
$ ps aux | grep [h]ttpd
before and after an ra_dav checkout. This will let you see the amount
of CPU used by the apache processes. If apache only uses a few
seconds of CPU then the problem is probably some sort of IO delay. If
apache uses 3 minutes of CPU then we have some sort of scaling
problem.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pitiful dav performance
Posted by Brandon Ehle <az...@yahoo.com>.
seanc@dimensionalrift.com wrote:
>I've spent most of the weekend (and now most of monday due to an
>ice-storm) setting up a test server with Subversion 0.18 on it. I have
>configured just about every access method, and have some problems with the
>dav performance, and that has me puzzled.
>
>
If you haven't seen this yet, check it out. Its a graph of ra_dav vs
ra_local & ra_svn (ra_dav is the yellow line on top of the checkout
graph). There are still plenty of performance issues to be taken care
of for ra_dav like Philip mentions.
http://www.pipedreaminteractive.com/svn/gig/elapsed.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org