[Gluster-users] Replicate performance (cluster/replicate, performance/io-cache)

[Mark Mielke]

On 09/14/2009 08:27 AM, Alex Craven wrote:
> I've just started experimenting with glusterfs and am new to this list, so
> apologies if this has all been covered before! (a quick browse through the
> archives didn't reveal anything though)
>
> I'm attempting to use glusterfs to manage replication between a pair of
> geographically separated test servers (communicating over an ssh tunnel).
> I realise this isn't exactly an optimal configuration. However, I need
> fast read performance but don't particularly care about write performance,
> and it doesn't really matter if I'm reading 30-second-old data (my usage
> is mainly for webserver replication, so the data won't be changing very
> often anyway).
>
> Now, I've set up gluster as per the attached configurations. I believe all
> the appropriate performance translators are configured, notably including
> the io-cache. The read-subvolume is set to a posix storage on the local
> machine.
>
> Still, in spite of the local read-subvolume and caching, successive read
> operations on the same (tiny) file, well within the cache-timeout period
> always take a minimum time equivalent to four round trips to complete.
>    

The read subvolume only helps on read(). For every other request, such 
as open(), all of the replicas get involved. I think you are looking for 
the dr sync functionality they list on the roadmap for GlusterFS 2.2.

> Can anyone explain why this is? I understand there may be one transaction
> to validate the cache, but what else is going on here? Furthermore, is it
> possible to defer/disable this re-validation (within a timeout)
> altogether?luster.org/cgi-bin/mailman/listinfo/gluster-users
>    

Not that I know of - and I think there would be many gotchas of doing 
such a thing - however, for certain use cases, it would be kind of cool 
if they could relax the restrictions and/or move operations such as 
consistency checks and self-heal to the background to be run 
asynchronously. For example, if I am doing open(..., O_RDONLY), read(), 
close(), then I may not care about the state of other volumes, as long 
as I see a consistent snapshot that doesn't break half-way through my 
read()s...

Cheers,
mark

-- 
Mark Mielke<mark at mielke.cc>