[Mulgara-general] Performance of the commit operation

[Paul Gearon]

On Feb 21, 2008, at 7:17 AM, Schenk, Andre wrote:

> Hi Paul,
>
>> By the way.... how much data have you written when you do the  
>> commit operation?
>
> I wrote a simple test which consecutively inserts
>
> "<http://www.domain.net/~jsmith/home.html" + serial + ">  
> <dc:creator> 'John Smith' into <rmi://localhost/server1#model1>;"
>
> 10 times in a single transaction. "serial" is just an integer value.  
> This takes about 100ms.

I think you'll find that the more you insert, the less time it will  
take per insertion.  There will be an asymptote, but 10 insertions is  
a long way from it.


> But the following commit takes about 500ms. This seems to be a lot  
> of time.

This is the part that is SUPPOSED to take a lot of time.  It is going  
to wait until writes have happened on a couple of dozen files, which  
means a lot of seeking until it's done.  You haven't written much, so  
there won't be any seeking within individual files, and the writes  
will all be of single blocks, but the fact that it has to happen in  
different places means you have to wait for the drive head to move,  
even though there's not a lot of work to be done once it's completed  
the move.

>> Most disk write operations return very quickly, but if the power  
>> were removed, then after the computer rebooted the data would not  
>> be found anyway,
>> since it was only in RAM and waiting for the writeback.  This makes  
>> the program more responsive, but less reliable.
>
> In the meantime I had the chance to repeat my tests with the  
> underlying ReiserFS set to data=writeback. The performance gain was  
> not more than 10%.

While I'd expect you to get something back, the code is still written  
with a barrier in it to be passed before the next stage of the commit  
can occur.  In fact, there are several such barriers.  So even though  
the filesystem driver returns immediately (subverting the requirements  
of the API) the code calling it is still having to get through these  
choke points.

It shouldn't be hard to remove these choke points, but we'd never do  
that.  If the performance for small operations becomes important, then  
we would have a memory-based layer over the top which could soak these  
up, and flush them out reliably.  You'd run the risk of losing any  
unflushed data in the event of a crash or power failure, but the data  
on disk would continue to be safe.  At the moment, there hasn't been a  
need for this, so it hasn't been looked at.

Regards,
Paul