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>
> wrote:
> >
> >> 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
more clear.
> > 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.
-- Stefan^2.
--
*
Join us this October at Subversion Live
2012<http://www.wandisco.com/svn-live-2012>
for two days of best practice SVN training, networking, live demos,
committer meet and greet, and more! Space is limited, so get signed up
today<http://www.wandisco.com/svn-live-2012>
!
*
Received on 2012-09-23 15:01:57 CEST