On 30.09.2010 04:28, Ramkumar Ramachandra wrote:
Hi Stefan,
Stefan Fuhrmann writes:
My measurements seem to support what Philip wrote:
The expensive part is run on the server. Even with my
optimized server, the svnrdump CPU usage is less than
the time taken by the server. Some numbers (hot file
cache):
svnadmin dump
1.7 trunk 70s real 66s user 4s system
perf-branch 30s real 28s user 2s system
1.7 trunk svnrdump
ra-local 88s real 81s user 7s system
svn: (1.7 trunk) 99s real 6s user 4s system
svn: (perf-branch, cold) 72s real 5s user 6s system
svn: (perf-branch, hot) 17s real 5s user 5s system
Thus, svnrdump is slower only for ra-local where it is
of no particular use in the first place. To really speed
things up, the caching infrastructure from the performance
branch should be merged into /trunk.
Wow, that looks awesome. Yeah, Daniel suggested that I run svnrdump
against your perf branch yesterday, but I wasn't able to get your
branch to build:
subversion/libsvn_subr/svn_file_handle_cache.c:890: error:
'svn_file_handle_cache_t' has no member named 'mutex'
You obviously don't have APR threads enabled.
Thanks for finding this. Fixed in r1003430.
What exactly are the changes that "hot" introduces- can you point me
to the specific revision numbers that we intend to merge?
The server caches almost everything. So, the
first ("cold") run demonstrates the worst-case,
the second run ("hot") the best case. Real
world performance depends on server memory
and load.
For the merge part: please review the "integrate-membuffer"
branch (only 3 patches). You may also review and
merge any of the patches listed in /branches/performance/STATUS.
@Stefan: Thoughts on hacking APR hashtables directly?
Are you sure?! Which operation is the most expensive one
and how often is it called? Who calls it and why?
My bad. I got muddled up when using ra_local: when I saw lots of MD5
functions, I assumed it had to do something with the hashtable since
the checksum was caculated by server-side. The profiler profiled both
server-side and client-side. Over svn://, I got a much cleaner
output. The new results indicate:
1. Server-client IO is the major bottleneck, as Philip and you pointed
out.
2. On the client side, the major bottlneck is the IO during textdelta
application. David (CC'ed now) and I are trying some experiments
with a single temporary file. Thoughts?
For the MD5 stuff, try r986459 (performance branch).
It should eliminate 1 of the 3 MD5 calculations.
As for the temp files, there are some improvements
listed in /branches/performance/STATUS. These would
also reduce your "system" CPU time.
-- Stefan^2.
