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.
Received on 2010-10-01 10:51:43 CEST