You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Paul Koning <pk...@equallogic.com> on 2005/09/12 19:21:32 UTC
Performance
I'm doing tests of CVS vs. Subversion.
The first test is to checkout a full working directory, on a rather
large repository (35,000 revisions, and the CVS working directory is
foo MB).
In CVS that takes 10 minutes. In Subversion, it takes 46 minutes.
I'm not surprised it takes a little longer, after all SVN has to write
two copies (the regular one and the clean one in .svn). But that
difference is quite surprising.
The other puzzle is that svn sits for a minute or two at the end,
without producing any output and without any significant activity that
I can see. CPU time goes up just a little (17:02 at the end of the
activity, and then 17:04 a little later). The server isn't doing
anything (the httpd thread shows 11:25 CPU time). What's going on
there?
Is it reasonable for things to take this long?
By the way, I changed /dev/random to be /dev/urandom given the earlier
comments about a possible reason for things to get stalled. (Not that
this makes any sense -- what possible use does the server have for
strong random numbers in this process???) So that definitely isn't a
consideration. Actually, I ran the test several times, before and
after that change; the timing was identical.
Subversion 1.2.3, Apache 2.0.54. The machine runs Linux 2.4.21 on a
quad processor Xeon, 1 GB memory.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 14, 2005, at 7:39 AM, Jon Bendtsen wrote:
>
> So squid can not proxy the most requested files either ?
> Or other http "accelerators" ?
Nope.
In pre-1.0 versions of svn, the client received a list of files to
fetch, and then did a million GET requests. While that situation
might have been very nice for proxy accelerators, it also made 'svn
checkout' about 5-10 times slower than it currently is. So we made
the performance tradeoff for the common case of *not* having proxy
caches.
The client and server still know how to do the old-style checkout,
they just don't use that method anymore. ('svn diff/merge' still use
that style of tree fetching, IIRC). Perhaps a feature request might
be a switch or runtime-preference in ~/.subversion/servers to use the
old-style checkout. Most people won't want that, but folks with
proxy caches might...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Jon Bendtsen <jo...@laerdal.dk>.
Den 14. sep 2005 kl. 14:12 skrev Ben Collins-Sussman:
>
> On Sep 14, 2005, at 3:18 AM, Jon Bendtsen wrote:
>
>>
>> I think .htaccess does matter, because i think the apache server
>> will see
>> alot of
>> get /svn/project/file1.txt
>> get /svn/project/file2.txt
>> get /svn/project/file3.txt
>> get /svn/project/file4.txt
>> get /svn/project/file5.txt
>> ...
>> get /svn/project/file111111.txt
>>
>> And it will probably check for the .htaccess file every time.
>>
>
>
> Nope. 'svn checkout' doesn't issue any GET requests. The whole
> tree is streamed back in a single http response.
>
> The whole .htaccess thing is circumvented and irrelevant; apache's
> main engine is out of the picture in this scenario. mod_dav_svn is
> wholly responsible for opening a bucket-brigade and streaming the
> response directly from the repository database.
So squid can not proxy the most requested files either ?
Or other http "accelerators" ?
JonB
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 14, 2005, at 3:18 AM, Jon Bendtsen wrote:
>
> I think .htaccess does matter, because i think the apache server
> will see
> alot of
> get /svn/project/file1.txt
> get /svn/project/file2.txt
> get /svn/project/file3.txt
> get /svn/project/file4.txt
> get /svn/project/file5.txt
> ...
> get /svn/project/file111111.txt
>
> And it will probably check for the .htaccess file every time.
Nope. 'svn checkout' doesn't issue any GET requests. The whole tree
is streamed back in a single http response.
The whole .htaccess thing is circumvented and irrelevant; apache's
main engine is out of the picture in this scenario. mod_dav_svn is
wholly responsible for opening a bucket-brigade and streaming the
response directly from the repository database.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Jon Bendtsen <jo...@laerdal.dk>.
Den 13. sep 2005 kl. 23:37 skrev Paul Koning:
>
>
>>>>>> "Daniel" == Daniel Rucci <ru...@warganizer.com> writes:
>>>>>>
>
> Daniel> Paul Koning wrote:
>
>>> Just a thought... I have .htaccess files enabled, would that
>>> matter?
>>>
>
> Daniel> According to apache it might:
>
> Daniel> [...] "When AllowOverride is set to allow the use of
> Daniel> .htaccess files, Apache will look in every directory for
> Daniel> .htaccess files. Thus, permitting .htaccess files causes a
> Daniel> performance hit, whether or not you actually even use them!"
> Daniel> [...]
>
> Yes, that's what I was thinking about when I wrote the note. But does
> that also affect the operations that occur while svn is in the middle
> of doing a long complex job, like a massive checkout? It sounds like
> mod_dav_svn has its own machinery that does not rely on stuff like
> .htaccess, so the performance issue mentioned in the Apache book would
> not apply.
I think .htaccess does matter, because i think the apache server will
see
alot of
get /svn/project/file1.txt
get /svn/project/file2.txt
get /svn/project/file3.txt
get /svn/project/file4.txt
get /svn/project/file5.txt
...
get /svn/project/file111111.txt
And it will probably check for the .htaccess file every time.
JonB
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Paul Koning <pk...@equallogic.com>.
>>>>> "Daniel" == Daniel Rucci <ru...@warganizer.com> writes:
Daniel> Paul Koning wrote:
>> Just a thought... I have .htaccess files enabled, would that
>> matter?
Daniel> According to apache it might:
Daniel> [...] "When AllowOverride is set to allow the use of
Daniel> .htaccess files, Apache will look in every directory for
Daniel> .htaccess files. Thus, permitting .htaccess files causes a
Daniel> performance hit, whether or not you actually even use them!"
Daniel> [...]
Yes, that's what I was thinking about when I wrote the note. But does
that also affect the operations that occur while svn is in the middle
of doing a long complex job, like a massive checkout? It sounds like
mod_dav_svn has its own machinery that does not rely on stuff like
.htaccess, so the performance issue mentioned in the Apache book would
not apply.
Then again, I may be confused.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Daniel Rucci <ru...@warganizer.com>.
Paul Koning wrote:
> Just a thought... I have .htaccess files enabled, would that matter?
According to apache it might:
[...] "When AllowOverride is set to allow the use of .htaccess files,
Apache will look in every directory for .htaccess files. Thus,
permitting .htaccess files causes a performance hit, whether or not you
actually even use them!" [...]
http://httpd.apache.org/docs/2.0/howto/htaccess.html
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Paul Koning <pk...@equallogic.com>.
Just a thought... I have .htaccess files enabled, would that matter?
That's part of the setup for Insurrection. Judging by the Apache book
I could put those rewrite rules in the httpd.conf file (and perhaps
should). But it's hard enough to get Insurrection to work without
rewriting it.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Aaron Wood <wo...@gmail.com>.
On 9/13/05, Ryan Schmidt <su...@ryandesign.com> wrote:
> > The other puzzle is that svn sits for a minute or two at the end,
> > without producing any output and without any significant activity that
> > I can see. [snip]
>
> I don't think that's related to the cvs2svn conversion issue; I don't
> think it has anything to do with how many files you're getting or how
> big they are. Indeed, I have no idea what causes it; we see this
> phenomenon often (but not always) on our company's Subversion
> repository, and it's driving my coworkers nuts. Actually I'm not sure
> if it's exactly the same as what you're seeing, because we see it
> mostly when committing, after the file data has been sent, but before
> it returns control to the prompt. And we also see it when updating a
> working copy, after all the data has been received but again before
> regaining command control. But I don't know what to do about it,
> which is why I didn't respond to that part of your question.
FWIW, we see this with CVS, too. But only on Windows (I don't see it
with either on OSX). I think it has something to do with how it
handles the filesystem.
-Aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 13, 2005, at 17:11, Paul Koning wrote:
>> Got any large files? I noticed an apparent several-minutes
>> pause while loading a dump of our repository, but it turns out
>> it was just uploading a 300-MB file.
>
> That doesn't explain the 2 minute stall at the end of the process; the
> last file is a small .h file.
>
> But yes, there are some big files. The biggest is 38 MB, and there
> are 194 files bigger than 1 MB. They are all binary files of various
> kinds, naturally.
Well, wait, you were talking about two different things. You noted
that, during the cvs2svn conversion, you saw a long delay at a
certain point:
On Sep 13, 2005, at 15:54, Paul Koning wrote:
> Oh yes, one more data point. In one of my test runs of cvs2svn, I
> watched the log entries scroll by. In phase 5, where the SVN commits
> are done that create the equivalent of the CVS history, one of the
> commits took a very long time (many minutes), long enough that I
> thought it had gotten wedged due to a bug before I finally let it run
> to completion and noticed all was well.
I responded to this, saying it might be a single large file being
committed at that point, and I still think that's a likely answer.
Not sure if many minutes is a reasonable time for a commit of a 38MB
file to take... suppose I could try it. But since that's only an
issue at the time where you add such a large file to the repository,
I'm hoping it's not something you'll run into every day, and so the
fact that it takes some time should not be a hindrance to you.
The other issue you talked about is that, at the end of a checkout,
it waits for a long time:
On Sep 12, 2005, at 21:21, Paul Koning wrote:
> The first test is to checkout a full working directory, on a rather
> large repository (35,000 revisions, and the CVS working directory is
> foo MB).
> [snip]
> The other puzzle is that svn sits for a minute or two at the end,
> without producing any output and without any significant activity that
> I can see. [snip]
I don't think that's related to the cvs2svn conversion issue; I don't
think it has anything to do with how many files you're getting or how
big they are. Indeed, I have no idea what causes it; we see this
phenomenon often (but not always) on our company's Subversion
repository, and it's driving my coworkers nuts. Actually I'm not sure
if it's exactly the same as what you're seeing, because we see it
mostly when committing, after the file data has been sent, but before
it returns control to the prompt. And we also see it when updating a
working copy, after all the data has been received but again before
regaining command control. But I don't know what to do about it,
which is why I didn't respond to that part of your question.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 13, 2005, at 15:54, Paul Koning wrote:
> Oh yes, one more data point. In one of my test runs of cvs2svn, I
> watched the log entries scroll by. In phase 5, where the SVN commits
> are done that create the equivalent of the CVS history, one of the
> commits took a very long time (many minutes), long enough that I
> thought it had gotten wedged due to a bug before I finally let it run
> to completion and noticed all was well.
>
> I don't have the revision number anymore, or other detail on what that
> hairy commit was. Is it possible that there is some really screwy
> transaction that would cause things to slow down very badly from then
> onwards?
Got any large files? I noticed an apparent several-minutes pause
while loading a dump of our repository, but it turns out it was just
uploading a 300-MB file.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Paul Koning <pk...@equallogic.com>.
>>>>> "Erik" == Erik Huelsmann <eh...@gmail.com> writes:
>> I have the module loaded, but I don't have a statement like that.
>> So it sounds like it's inactive.
Erik> Yes, inactive, but not turned off. To learn about the
Erik> difference, read
Erik> http://svn.haxx.se/users/archive-2004-11/0277.shtml
Excellent.
Now the checkout takes 30:57, with 4:12 user CPU and 1:58 kernel CPU.
Still not as good as it should be (by comparison with 10 minutes for
CVS) but a whole lot better.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Erik Huelsmann <eh...@gmail.com>.
On 9/13/05, Paul Koning <pk...@equallogic.com> wrote:> >>>>> "Christopher" == Christopher Ness <ch...@nesser.org> writes:> > Christopher> On Mon, 2005-09-12 at 17:33 -0400, Paul Koning wrote:> >> >>>>> "Christopher" == Christopher Ness <ch...@nesser.org> writes:> Christopher> What kind of authz are you using? Is the repository> Christopher> wide open for anyone or are there permissions for each> Christopher> dir?> >> readonly wide open, "basic" for read-write.> > Christopher> Basic is apache doing the authentication for a URL> Christopher> location, not subversion. In effect it is the same as> Christopher> .htaccess files you mention.> > Christopher> Authz is more advanced authentication based on> Christopher> directories within subversion and is usually a module> Christopher> for apache. The documentation on authz can be found> Christopher> here:> Christopher> http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.4.2> > Christopher> So you don't have this in your config: # our access> Christopher> control policy AuthzSVNAccessFile /path/to/access/file> > I have the module loaded, but I don't have a statement like that. So> it sounds like it's inactive.
Yes, inactive, but not turned off. To learn about the difference, readhttp://svn.haxx.se/users/archive-2004-11/0277.shtml
bye,
Erik.
Re: Performance
Posted by Paul Koning <pk...@equallogic.com>.
>>>>> "Christopher" == Christopher Ness <ch...@nesser.org> writes:
Christopher> On Mon, 2005-09-12 at 17:33 -0400, Paul Koning wrote:
>> >>>>> "Christopher" == Christopher Ness <ch...@nesser.org> writes:
Christopher> What kind of authz are you using? Is the repository
Christopher> wide open for anyone or are there permissions for each
Christopher> dir?
>> readonly wide open, "basic" for read-write.
Christopher> Basic is apache doing the authentication for a URL
Christopher> location, not subversion. In effect it is the same as
Christopher> .htaccess files you mention.
Christopher> Authz is more advanced authentication based on
Christopher> directories within subversion and is usually a module
Christopher> for apache. The documentation on authz can be found
Christopher> here:
Christopher> http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.4.2
Christopher> So you don't have this in your config: # our access
Christopher> control policy AuthzSVNAccessFile /path/to/access/file
I have the module loaded, but I don't have a statement like that. So
it sounds like it's inactive.
I reran the test with the rewrite log turned off. Same result, same
timing.
What do I do next?
Oh yes, one more data point. In one of my test runs of cvs2svn, I
watched the log entries scroll by. In phase 5, where the SVN commits
are done that create the equivalent of the CVS history, one of the
commits took a very long time (many minutes), long enough that I
thought it had gotten wedged due to a bug before I finally let it run
to completion and noticed all was well.
I don't have the revision number anymore, or other detail on what that
hairy commit was. Is it possible that there is some really screwy
transaction that would cause things to slow down very badly from then
onwards?
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Christopher Ness <ch...@nesser.org>.
On Mon, 2005-09-12 at 17:33 -0400, Paul Koning wrote:
> >>>>> "Christopher" == Christopher Ness <ch...@nesser.org> writes:
> Christopher> What kind of authz are you using? Is the repository
> Christopher> wide open for anyone or are there permissions for each
> Christopher> dir?
>
> readonly wide open, "basic" for read-write.
Basic is apache doing the authentication for a URL location, not
subversion. In effect it is the same as .htaccess files you mention.
Authz is more advanced authentication based on directories within
subversion and is usually a module for apache. The documentation on
authz can be found here:
http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.4.2
So you don't have this in your config:
# our access control policy
AuthzSVNAccessFile /path/to/access/file
You could safely disable the path checks in your setup. But leave a big
comment in case you ever do start to use Authz ACL's.
> Christopher> The book says the log sub-command is mostly hit by the
> Christopher> overhead of checking the paths for each directory. If
> Christopher> you have that many files, I'm thinking you have quite a
> Christopher> nested directory structure.
>
> Christopher> This link will show you how to disable authz and
> Christopher> explains what is going on in more detail:
> Christopher> http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.4.3
>
> Thanks, I'll study that.
>
> Christopher> ALSO: I'd like to know what type of file system you are
> Christopher> using (likely ext3). If you have time, try the
> Christopher> repository in a Reiser file system partition and post
> Christopher> your benchmark times again.
>
> ext3. But I'd rather not switch. What does Reiser have going for it
> that would help here?
There was talk on list about file systems affecting performance for FSFS
repositories.
You'd only really see a difference under heavy loads and large
repositories IMHO - which you may have and therefore could give good
benchmarks.
$ time svn {co,up,blame,log}
Actually I'm not sure if there is a standard tool set for SVN benchmarks
or if it is mostly adhoc timings as suggested above.
The thread about file systems is found here:
http://svn.haxx.se/users/archive-2005-08/1329.shtml
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
22:07:55 up 5:08, 2 users, load average: 0.68, 0.28, 0.10
Re: Performance
Posted by Paul Koning <pk...@equallogic.com>.
>>>>> "William" == William Nagel <bi...@stagelogic.com> writes:
William> On Sep 12, 2005, at 2:21 PM, Paul Koning wrote:
>> I'm doing tests of CVS vs. Subversion.
>>
>> The first test is to checkout a full working directory, on a
>> rather large repository (35,000 revisions, and the CVS working
>> directory is foo MB).
William> My brain got an NaN parse error on your working directory
William> size. ;-)
Oops. I wrote that and then didn't go back to fill in the output from
"du -s".
1.6 GB of working directory in the CVS sandbox, 3.5 GB in the SVN
sandbox.
I just noticed a possible cause... the RewriteLog was turned on (part
of an attempt to get Insurrection to work again...)
Turned it off. Started a new run... almost done and then some wise
guy shut the system down. Argh...
>>>>> "Christopher" == Christopher Ness <ch...@nesser.org> writes:
Christopher> What method was used? It looks like http:// since you
Christopher> mentioned an apache revision number.
http.
Christopher> What kind of authz are you using? Is the repository
Christopher> wide open for anyone or are there permissions for each
Christopher> dir?
readonly wide open, "basic" for read-write.
Christopher> The book says the log sub-command is mostly hit by the
Christopher> overhead of checking the paths for each directory. If
Christopher> you have that many files, I'm thinking you have quite a
Christopher> nested directory structure.
Christopher> This link will show you how to disable authz and
Christopher> explains what is going on in more detail:
Christopher> http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.4.3
Thanks, I'll study that.
Christopher> ALSO: I'd like to know what type of file system you are
Christopher> using (likely ext3). If you have time, try the
Christopher> repository in a Reiser file system partition and post
Christopher> your benchmark times again.
ext3. But I'd rather not switch. What does Reiser have going for it
that would help here?
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by Christopher Ness <ch...@nesser.org>.
On Mon, 2005-09-12 at 15:39 -0500, Ben Collins-Sussman wrote:
> On Sep 12, 2005, at 3:24 PM, William Nagel wrote:
>
> >
> > This is a fairly well-known issue. Because of design difference
> > between Subversion and CVS, checkouts can take significantly longer
> > under Subversion. Just about everything else runs faster though,
> > so it's a tradeoff that most people consider acceptable (given that
> > you're not normally going to check out a working copy very often).
> >
> >
>
> A checkout taking 4x longer than cvs is not normal.
>
> When we compared CVS vs. SVN checkouts just before svn 1.0 was
> released, we never saw svn behave worse than 2x slower. Usually it
> was more like 1.5x slower. So I think something is fishy in his
> setup...
What method was used? It looks like http:// since you mentioned an
apache revision number.
What kind of authz are you using? Is the repository wide open for
anyone or are there permissions for each dir?
The book says the log sub-command is mostly hit by the overhead of
checking the paths for each directory. If you have that many files, I'm
thinking you have quite a nested directory structure.
This link will show you how to disable authz and explains what is going
on in more detail:
http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.4.3
Of course if you _cannot_ disable authz for your repository because you
need those features, then ...
ALSO: I'd like to know what type of file system you are using (likely
ext3). If you have time, try the repository in a Reiser file system
partition and post your benchmark times again.
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
17:10:02 up 10 min, 2 users, load average: 0.03, 0.29, 0.23
Re: Performance
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 12, 2005, at 3:24 PM, William Nagel wrote:
>
> This is a fairly well-known issue. Because of design difference
> between Subversion and CVS, checkouts can take significantly longer
> under Subversion. Just about everything else runs faster though,
> so it's a tradeoff that most people consider acceptable (given that
> you're not normally going to check out a working copy very often).
>
>
A checkout taking 4x longer than cvs is not normal.
When we compared CVS vs. SVN checkouts just before svn 1.0 was
released, we never saw svn behave worse than 2x slower. Usually it
was more like 1.5x slower. So I think something is fishy in his
setup...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Performance
Posted by William Nagel <bi...@stagelogic.com>.
On Sep 12, 2005, at 2:21 PM, Paul Koning wrote:
> I'm doing tests of CVS vs. Subversion.
>
> The first test is to checkout a full working directory, on a rather
> large repository (35,000 revisions, and the CVS working directory is
> foo MB).
My brain got an NaN parse error on your working directory size. ;-)
>
> In CVS that takes 10 minutes. In Subversion, it takes 46 minutes.
> I'm not surprised it takes a little longer, after all SVN has to write
> two copies (the regular one and the clean one in .svn). But that
> difference is quite surprising.
This is a fairly well-known issue. Because of design difference
between Subversion and CVS, checkouts can take significantly longer
under Subversion. Just about everything else runs faster though, so
it's a tradeoff that most people consider acceptable (given that
you're not normally going to check out a working copy very often).
>
> The other puzzle is that svn sits for a minute or two at the end,
> without producing any output and without any significant activity that
> I can see. CPU time goes up just a little (17:02 at the end of the
> activity, and then 17:04 a little later). The server isn't doing
> anything (the httpd thread shows 11:25 CPU time). What's going on
> there?
>
> Is it reasonable for things to take this long?
Probably. Of course, I have little experience with repositories of
size "foo" so I can't say for sure. If you give a real size people
may have an easier time responding with comparisons to their own
experiences. :-)
>
> By the way, I changed /dev/random to be /dev/urandom given the earlier
> comments about a possible reason for things to get stalled. (Not that
> this makes any sense -- what possible use does the server have for
> strong random numbers in this process???) So that definitely isn't a
> consideration. Actually, I ran the test several times, before and
> after that change; the timing was identical.
I believe the random numbers are used for SSL, but I'm not positive
on that. Assuming I'm right, then it should be a non-issue if you're
not using SSL.
-Bill
>
> Subversion 1.2.3, Apache 2.0.54. The machine runs Linux 2.4.21 on a
> quad processor Xeon, 1 GB memory.
>
> paul
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org