<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> Machine 1: 72 MB/sec block write, 72MB/sec block read, 29 MB/sec block<br> rewrite.<br>
 Machine 2: 36 MB/sec block write, 72MB/sec block read, 21 MB/sec block<br> rewrite.<br> gluster-AFR: 22 MB/sec block write, 24 MB/sec block read, 9 MB/sec block<br> rewrite.<br> gluster-Unify (ALU scheduler): 21 MB/sec, 20 MB/sec block read, 8.8<br>
 MB/sec block rewrite.<br> <br> Is this expected performance with gluster for a small number of nodes on<br> TCP/IP? Or am I missing some critical piece of configuration? In<br> particular, I thought that in an AFR config the client was supposed to<br>
 automatically stripe read requests across available volumes, but the<br> read performance doesn&#39;t seem to indicate that&#39;s happening, considering<br> the requests it sends to itself should be able to get close to its<br>
 normal ~70MB/sec rate.</blockquote><div><br>
Are you using write-behind in the client volume spec? write-behind
affects write performance significantly. AFR spreads different files to
be read from different subvolumes, and not parts of a file. <br>
</div><br>
</div>