Date: Mon, 26 Mar 2012 12:26:50 -0500 (CDT) From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> To: Sven Brandenburg <sven@crashme.org> Cc: freebsd-fs@freebsd.org Subject: Re: NFSv3, ZFS, 10GE performance Message-ID: <alpine.GSO.2.01.1203261213590.22350@freddy.simplesystems.org> In-Reply-To: <4F709A2C.2080806@crashme.org> References: <4F703815.8070809@crashme.org> <alpine.GSO.2.01.1203260925010.1678@freddy.simplesystems.org> <4F709A2C.2080806@crashme.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Mar 2012, Sven Brandenburg wrote: > >> Are you only interested in single threaded read performance to a single >> client? > My first item on the list is serving one client as fast as possible, next > step is multiple client machines (maybe these are conflicting goals?). > However, I figure that I should at least be able to press the right buttons > to dial in "fast" for one client :-) It really depends on if the client will actually consume all of the data as requested or if the client application will be competing with NFS because it transfers data it will never need. An issue which is quite familiar to me is the TIFF image file format. This format stores the image data in sequential strips, yet it uses more complex data structures (which require many seek + small read) as well. In my testing, I found that excessive read-ahead hindered performance with this file format. More than 16k of read-ahead often resulted in a performance penalty over NFS. Memory mapped files can also cause a performance problem since the MMU page size is typically 4K and the program is blocked from running until the current page fault completes. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.2.01.1203261213590.22350>