[prev in list] [next in list] [prev in thread] [next in thread]
List: gluster-users
Subject: Re: [Gluster-users] Fuse vs NFS
From: Vijay Bellur <vbellur () redhat ! com>
Date: 2019-07-20 6:42:32
Message-ID: CAHn=sVAzc3MBTcfNks=17r5kQH_ESz6kLi_7mkhzg8yPqS3TRQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Jul 18, 2019 at 1:06 AM Sudheer Singh <sudsingh@cs.stonybrook.edu>
wrote:
> Hi ,
>
> I was doing perf testing and found out fuse mount much slower than NFS
> mount. I was curious to know what community recommends, mount volumes as
> fuse or NFS?
>
Performance depends on several factors like:
1. Network latency between clients & servers
2. Caching on the client-side
3. Total number of context switches and memory copies between kernel and
userspace.
4. Workload that is being exercised on the mount point.
5. Resources on the client & servers.
It is to be noted that with FUSE, the client talks to servers directly and
in the case of NFS client, the requests reach the gluster servers through
the NFS server which acts as a gateway. Hence for most operations that
bypass the cache (client side cache or cache in NFS sever), NFS will have
one more network hop than FUSE. If the context switch and memory copy
overheads are lesser than the latency added by the additional network hop
with NFS, FUSE will be faster than NFS. Typically for workloads that
perform large sequential writes or reads (> 64 KB block size), you would
expect the performance to be better in FUSE. For writes with small record
sizes and some metadata operations that can be answered by cached content,
NFS can be faster. Also to note is that with FUSE, replication,
distribution, erasure coding etc. happen on the client. With NFS, all these
functions happen on the server. So, the hardware resources available on
client & servers also have a bearing on overall performance.
Hence, in essence, the performance that you get from gluster is not just
dependent on the access protocol but also on other factors like the ones
alluded above.
Thanks,
Vijay
--
> Thanks,
> Sudheer
> _______________________________________________
> Gluster-users mailing list
> Gluster-users@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Jul 18, 2019 at 1:06 AM Sudheer Singh <<a \
href="mailto:sudsingh@cs.stonybrook.edu">sudsingh@cs.stonybrook.edu</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi \
,<div><br></div><div>I was doing perf testing and found out fuse mount much slower \
than NFS mount. I was curious to know what community recommends, mount volumes as \
fuse or NFS?</div></div></blockquote><div><br></div><div><br></div><div>Performance \
depends on several factors like:</div><div><br></div><div>1. Network latency between \
clients & servers</div><div>2. Caching on the client-side</div><div>3. Total \
number of context switches and memory copies between kernel and \
userspace.</div><div>4. Workload that is being exercised on the mount \
point.</div><div>5. Resources on the client & \
servers.</div><div><br></div><div>It is to be noted that with FUSE, the client talks \
to servers directly and in the case of NFS client, the requests reach the gluster \
servers through the NFS server which acts as a gateway. Hence for most operations \
that bypass the cache (client side cache or cache in NFS sever), NFS will have one \
more network hop than FUSE. If the context switch and memory copy overheads are \
lesser than the latency added by the additional network hop with NFS, FUSE will be \
faster than NFS. Typically for workloads that perform large sequential writes or \
reads (> 64 KB block size), you would expect the performance to be better in FUSE. \
For writes with small record sizes and some metadata operations that can be answered \
by cached content, NFS can be faster. Also to note is that with FUSE, replication, \
distribution, erasure coding etc. happen on the client. With NFS, all these functions \
happen on the server. So, the hardware resources available on client & servers \
also have a bearing on overall performance.</div><div><br></div><div>Hence, in \
essence, the performance that you get from gluster is not just dependent on the \
access protocol but also on other factors like the ones alluded \
above.</div><div><br></div><div>Thanks,</div><div>Vijay</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div>--</div><div>Thanks,</div><div>Sudheer</div></div> \
_______________________________________________<br> Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" \
target="_blank">Gluster-users@gluster.org</a><br> <a \
href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" \
target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a></blockquote></div></div>
_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic