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? -- Thanks, Sudheer -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190607/d98ec693/attachment.html>
Hello. Seriously? You REALLY thinks, that FUSE (in user space) will be faster then kernel NFS? With best wishes. Victor 2019-06-07 7:29 GMT+03:00, Sudheer Singh <sudsingh at cs.stonybrook.edu>:> 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? > > -- > Thanks, > Sudheer >
On Thu, Jul 18, 2019, 11:06 Sudheer Singh <sudsingh at 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? >You may need to consider libgfapi instead of fuse. I have seen better performance with it then nfs.> > -- > Thanks, > Sudheer > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-users-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190719/85df5c0a/attachment.html>
It depends of your needs.The Gluster's inbuilt NFS server is no longer
recommended.I think you should try NFS Ganesha, which uses libgfapi
communication channel.If your app can use libgfappi - you can try that approach.
Best Regards,Strahil Nikolov
? ?????????, 18 ??? 2019 ?., 11:06:00 ?. ???????+3, Sudheer Singh
<sudsingh at cs.stonybrook.edu> ??????:
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?
--Thanks,Sudheer_______________________________________________
Gluster-users mailing list
Gluster-users at gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20190719/c917addf/attachment.html>
On Thu, Jul 18, 2019 at 1:06 AM Sudheer Singh <sudsingh at 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 at gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-users-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190719/2982de94/attachment.html>