> -----Original Message-----
> From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> Sent: maandag 16 maart 2015 14:32
> To: Marc Strapetz
> Cc: Bert Huijben; dev
> Subject: Re: 1.9.x JavaHL: long initial delay when performing a log
>
> 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"
The first level of buffering (The 8 KByte I quoted, or more precisely APR_BUCKET_BUFF_SIZE) is before the compression output filter even receives the first byte.
It is quite possible further layers have their own buffering limits, but if they follow the filter rules the flush should still get through. The apr brigades add a special flush frame to trigger this behavior, and the documentation explicitly says that filters should take care to handle this properly.
I would guess that 'log -q' has a very good compression ratio. (90% same xml elements; a few author names and then revision numbers)
Bert
Received on 2015-03-16 15:22:35 CET