[Gluster-devel] Performance Translators' Stability and Usefulness

Gordan Bobic gordan at bobich.net
Sat Jul 4 10:52:03 UTC 2009

Shehjar Tikoo wrote:
> We can definitely vouch for a higher degree of stability of the
> releases. Otherwise, I dont think there is any performance translator we
> can call completely stable/mature because of the roadmap we have for
> constantly upgrading algorithms, functionality, etc.

I'm only talking about release versions - while there are still 
consistently trippable bugs in my use case(s) (e.g. that consistent 
failure with immediate access after mounting the AFR volume) I'm not 
going to venture into the git head. :)

>> Any particular suggestions on which performance translator combination 
>> would be good to apply for a shared root AFR over a WAN? I already 
>> have read-subvolume set to the local mirror, but any improvement is 
>> welcome when latencies soar to 100ms and b/w gets hammered down to 
>> 1-2.5 Mb/s.
> WANs are generally characterised as having a large bandwidth-delay
> product. That basically means, for good throughput, we should be
> pipelining as much data as possible over the link, so that the long
> latency overhead can be mitigated or amortised by sending larger amount
> of data for the same fixed overhead.
> That said, what particular workload is it that gives you a throughput of
> 1-2.5 Mb/s?

That's the WAN bandwidth, so it's a theoretical maximum, not the 
observed throughput.

> When you say "latencies soar to 100ms", does that mean, these are just
> unusual spikes or is that the normal latency observed?

I was talking about ping time. I've actually checked it and its more 
like 30ms (on an idle connection), but that's still 4x more than disk 
access time and 300x more than LAN ping time.

> It'd help to see your volfiles and how the performance translators are
> arranged.

I'm not using the performance translators at the moment, It's only with 
2.0.2 that I've found it stable enough for my use case without any 
translators. But since you've mentioned it, how should the performance 
translators be arranged/nested?


More information about the Gluster-devel mailing list