[Gluster-devel] Fwd: Asking about Gluster Performance Factors
John Mark Walker
johnmark at redhat.com
Thu May 17 04:28:50 UTC 2012
See response below from Ben England. Also, note that this question should probably go in gluster-users.
----- Forwarded Message -----
From: "Ben England" <bengland at redhat.com>
To: "John Mark Walker" <johnmark at redhat.com>
Sent: Wednesday, May 16, 2012 8:23:30 AM
Subject: Re: [Gluster-devel] Asking about Gluster Performance Factors
JM, see comments marked with ben>>> below.
----- Original Message -----
From: "박은준" <ej1515.park at samsung.com>
To: gluster-devel at nongnu.org
Sent: Wednesday, May 16, 2012 5:23:12 AM
Subject: [Gluster-devel] Asking about Gluster Performance Factors
Samsung Enterprise Portal mySingle
May 16, 2012
Dear Gluster Dev Team :
I'm Ethan, Assistant engineer in Samsung electronics. Reviewing your paper, I have some questions of performance factors in gluster.
First, what does it mean the option "performance.cache-*"? Does it mean read cache? If does, what's difference between the options "prformance.cache-max-file-size" and "performance.cache-size" ?
I read your another paper("performance in a gluster system, versions 3.1.x") and it says as below on Page 12,
(Gluster Native protocol does not implement write caching, as we believe that the modest performance improvements from rite caching do not justify the risk of cache coherency issues.)
ben>>> While gluster processes do not implement write caching internally, there are at least 3 ways to improve write performance in a Gluster system.
- If you use a RAID controller with a non-volatile writeback cache, the RAID controller can buffer writes on behalf of the Gluster server and thereby reduce latency.
- XFS or any other local filesystem used within the server "bricks" can do "write-thru" caching, meaning that the writes can be aggregated and can be kept in the Linux buffer cache so that subsequent read requests can be satisfied from this cache, transparent to Gluster processes.
- there is a "write-behind" translator in the native client that will aggregate small sequential write requests at the FUSE layer into larger network-level write requests. If the smallest possible application I/O size is a requirement, sequential writes can also be efficiently aggregated by an NFS client.
Second, how much is the read throughput improved as configuring 2-way replication? we need any statistics or something like that.
("performance in a gluster system, versions 3.1.x") and it says as below on Page 12,
(However, read throughput is generally improved by replication, as reads can be delivered from either storage node)
ben>>> Yes, reads can be satisfied by either server in a replication pair. Since the gluster native client only reads one of the two replicas, read performance should be approximately the same for 2-replica file system as it would be for a 1-replica file system. The difference in performance is with writes, as you would expect.
Ethan Eunjun Park
Solution Development Team, Media Solution Center
416, Maetan 3-dong, Yeongtong-gu, Suwon-si, Gyeonggi-do 443-742, Korea
Mobile : 010-8609-9532
E-mail : ej1515.park at samsung.com
Gluster-devel mailing list
Gluster-devel at nongnu.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel