[ 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.
