On Fri, Sep 21, 2012 at 3:51 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 20.09.2012 23:35, Stefan Fuhrmann wrote: > > On Thu, Sep 20, 2012 at 9:22 PM, Branko Čibej <br...@wandisco.com> > wrote: > > > >> On 20.09.2012 13:41, stef...@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> ! *
