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. :)
> 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.
Of course, taking a quick look at the implementation, this might involve
rewriting all of ra_svn's network layer ...
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2012-09-21 03:52:16 CEST