[ can you please reply as text, not HTML? thanks. ]
Edward Ned Harvey wrote on Wed, 30 Jun 2010 at 19:01 -0000:
> . If I export all the different rev's of that file (parent dir, no
> subdirs) then some rev's are repeatably less than 11sec to export, while
> other revs are repeatably 15min.
>
> . During all of the above exports, I am the only user using the
> system. On the server, I see precisely one svnserve jump up to 100% cpu
> utilization for the duration of the export.
>
> I can't imagine any reason for such an enormous difference. I'm not sure
> what I should look at next. I'll have to just start reading and reading and
> reading code & documentation to get an idea precisely what other
> possibilities may be going on.
>
> Any ideas or suggestions?
>
1. my first thought:
http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas
Briefly: if a file has N revisions, we don't always store r{M} as delta
against r{M-1}; sometimes against r{M/2}.
2. run svnserve under a profiler and see where it spends its time?
> This thread is no longer development related, unless this is a bug. We're
> running svn 1.5.7 via svnserve, built from source on centos 5.1 x86_64. If
> anyone cares, I'll happily move to the users list.
You may want to try 1.6/1.7 too. (not in production; just to see if the
issues are still there)
> But for the sake of continuing discussion which is engaging, here's
> how I built the one with compression disabled:
>
> In zlib_encode() there is an if() statement, to see if len <
> MIN_COMPRESS_SIZE, in which case, compression will not be done. I simply
> commented out the if() {} else {} statement, to make zlib_encode()
> unconditionally behave as if len < MIN_COMPRESS_SIZE. That is: No
> compression.
>
Yes, this should prevent server->client deltas (only) from using
compression.
Received on 2010-06-30 18:24:18 CEST