<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font size="-1"><font face="serif">well, if dbench was to give me
close to real numbers then these number look quite .. well,
disappointing<br>
quick tests on a single brick volume that fuse mountpoints
locally to show a massive disproportion<br>
raw fs / gluster fuse<br>
336.224 / 17.7982<br>
<br>
I believe the volume is a standard one, meaning it wasn't
tweaked<br>
could this be worked around somehow, tuned?<br>
<br>
but if this kind of performance should be expected then I'll
have to abandon the idea of deploying gluster<br>
<br>
thanks<br>
<br>
<br>
<br>
</font></font><br>
On 25/04/12 17:44, Jeff Darcy wrote:
<blockquote
cite="mid:20120425124434.4a2437fc@jdarcy-dt.usersys.redhat.com"
type="cite">
<pre wrap="">On Wed, 25 Apr 2012 17:20:13 +0100
lejeczek <a class="moz-txt-link-rfc2396E" href="mailto:peljasz@yahoo.co.uk"><peljasz@yahoo.co.uk></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">would a tool such as dbench be a valid bechmark for gluster?
</pre>
</blockquote>
<pre wrap="">
Dbench is a pretty good tool. As long as you use the fileio back end,
your loadfiles should work on GlusterFS just fine.
</pre>
<blockquote type="cite">
<pre wrap="">and, most importantly, is there any formula to estimate raw
fs to gluster performance ratio for different setups?
for instance:
having a replicated volume, two bricks, fuse mountpoint to
volume via non-congested 1Gbps
or even
a volume on single brick with fuse client mountpoing locally
what percentage/fraction of raw filesystem performance
should we expect from gluster? roughly?
</pre>
</blockquote>
<pre wrap="">
As I'm sure you know, deriving system or application performance from
component performance is an exercise in dealing with chaos. There's
certainly no formula for it, and even sophisticated models usually
can't overcome the fact that very small differences in how the parts
interact - e.g. latency distributions or queuing behavior - can result
in large changes to the result. *In general* your network is going to
be the main factor affecting bandwidth, and for small numbers of disks
they're going to govern latency. To know how that affects your
application, you'd have to know whether it's bandwidth- or
latency-bound, and how well it can take advantage of parallelism.
</pre>
</blockquote>
</body>
</html>