On Fri, Sep 21, 2012 at 3:51 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 20.09.2012 23:35, Stefan Fuhrmann wrote:
> > On Thu, Sep 20, 2012 at 9:22 PM, Branko Čibej <brane_at_wandisco.com>
> >> On 20.09.2012 13:41, stefan2_at_apache.org wrote:
> >>> +Bottlenecks to address:
> >>> +
> >>> +* frequent cancellation checks (intense OS interaction)
> >> I don't understand this part: since when do cancellation checks involve
> >> interaction with the OS? I thought the cancellation flag was an (atomic,
> >> volatile) thing that requires neither cpu-level atomic operations, nor
> >> higher-level locking.
> > It may not actually be "the OS" but the phenomenon is real.
> > check_for_error() in ra_svn/editorp.c calls apr_poll(), which in
> > turn calls select().
> > To make things worse, we buffer small output data like props
> > etc. but check for errors after each of them. So, more select()
> > calls then socket writes ...
> OK, so this is actually the server looking for abort commands from the
> client, which is a bit different than the client checking the
> cancellation flag. :)
Yup. I changed the lingo in a few places to make that distinction
> > My idea is to short-circuit the check until at least x amount
> > of data has been sent.
> I'd expect that the same select/poll that waits for the write end of the
> socket to become ready can also notice that the read end has data
> available; making the whole thing asynchronous. Blindly sending data
> after the client aborted the edit seems like the wrong way to solve
> throughput issues.
We *do* blindly send data - up to a point since outgoing traffic
is being collected in an ra_svn-internal TX buffer. So, if some
of it would "offend" the client, the remainder of that buffer will
still be sent unconditionally.
> Of course, taking a quick look at the implementation, this might involve
> rewriting all of ra_svn's network layer ...
The whole communication is already asynchronous. It is simply
a cutesy to stop sending data before we get told by the OS that
the client closed its part of the connection anyway.
Join us this October at Subversion Live
for two days of best practice SVN training, networking, live demos,
committer meet and greet, and more! Space is limited, so get signed up
Received on 2012-09-23 15:01:57 CEST