On 16 March 2015 at 11:00, Marc Strapetz <marc.strapetz_at_syntevo.com> wrote:
> On 16.03.2015 01:50, Bert Huijben wrote:
>> Our server reports use an apr feature that buffers +- 8 KByte data before
>> sending out the first data.
>>
>> In this specific JavaHL case you ask for just the revision numbers.
>> (Unlike the C api, JavaHL's session.getLog() appears to handle a null list
>> of revision properties as no revision properties. Not the standard set!)
>>
>> I think every revision would (encoded in our Xml protocol) cost about 70
>> bytes, so there would fit at least 100 revisions in that buffer.
On my testing against the ASF EU mirror, the buffer size seems to be
48 KB, the response is compressed, and around 3000 log entries (with
-q) or 10000 log entries (with --xml --with-no-revprops) are buffered
at a time.
I used this tracing command:
strace -tt -e trace=read svn log -q
http://svn.eu.apache.org/repos/asf/subversion/trunk --limit=10000 2>&1
> /dev/null | grep -v "EAGAIN"
- Julian
> That's it! I now ran my previous example as it was (3 times) and it took
> average 19s until the first revision was reported.
>
> With discoverPath set to true, time until first response dropped to average
> 7s.
>
> With discoverPath set back to false, but revisionProperties set to
> "svn:log", time until first response is 1.5s - 2s -- so timings like the
> command line client!
>
> Regarding your patch, it could make sense to stop doubling next_forced_flush
> at a certain limit (say 128), if the sent log records are small, i.e. if
> discoverPath=false and revisionProperties = null .
Received on 2015-03-16 14:39:00 CET