> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: maandag 16 maart 2015 18:10
> To: Julian Foad
> Cc: Bert Huijben; Marc Strapetz; dev
> Subject: Re: 1.9.x JavaHL: long initial delay when performing a log
>
> Julian Foad <julianfoad_at_btopenworld.com> writes:
>
> > Flushing after the 1st, 2nd, 4th, 8th, ... log entry provides a crude
> > approximation to the desired semantics which is more like "don't delay
> > the first result more than a small fraction of a second, and don't
> > delay the next few results much more than that either". In other
> > words, the user's requirement is more about time delays. I wonder if
> > we could implement something closer to what the user really wants.
>
> apr_time_now() is not free so we don't want to call it on every
> revision, but we could call it before every extra flush. How about no
> more than one extra flush every 500ms:
Nice idea on the concept, but this patch doesn't implement that behavior
You will see the first result very fast. (No behavior change)
But then you use one algorithm to select when to check for a flush, and
another to decide whether to flush.
This might have the effect of showing a single result, and then thousands
more after all buffering layers are filled, because the code doesn't just
flush after 500 msec... But after X revisions (one algorithm) *and* 500
msec.
BTW 500 msec is about two or three the time you expect for google page of
results.... Why this arbritrary number?
How are you going to explain this behavior to users?
The current <= 1.8 behavior is that "Subversion is slow"... and it makes
them move to a DVCS (or svnserver), as accessing history via mod_dav is
(too) expensive... while this is just buffering.
After a patch like this, the users don't understand why Subversion is slow
after just the very first result.
The old patch had a back-off behavior of showing the first results fast, and
then slowing down to the old behavior of returning all results as afficient
as possible.
I don't see any of this in this behavior... Just a change that will most
likely be reverted after experiencing it in practice.
This 1 result and then nothing for some time is not user friendly towards
svn users, which already start reading... and then eventually everything
scrolls away.
It is also not how the streamy callbacks were intended. (But that is not
unlike how we currently get the data here)...
We designed things to arrive as soon as the server is done processing, and
the same level of buffering (8 Kbyte) just simply doesn't apply to all
operations. It works great for updates and operations that deliver much data
fast, or when there is not much data... but not for operations that deliver
data slowly.
Bert
Received on 2015-03-16 20:05:39 CET