Date: Sat, 22 Nov 2003 00:33:40 -0800 From: Sean Chittenden <sean@chittenden.org> To: Mike Silbersack <silby@silby.com> Cc: ports-committers@freebsd.org Subject: Re: cvs commit: ports/www/thttpd/files patch-mmc.c Message-ID: <20031122083340.GA30804@perrin.nxad.com> In-Reply-To: <20031116121934.B2192@odysseus.silby.com> References: <200311141832.hAEIWnpb056798@repoman.freebsd.org> <20031115102127.GA14554@regency.nsu.ru> <20031116121934.B2192@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > BTW, is there any place/docs I can read about pros/cons > > USE_SENDFILE yields me? > > > > Thanks! > > > > ./danfe > > I can give you a quick overview: > > Pros: > > - It's slightly more efficient with system resources. > > Cons: > > - You need to tune sfbufs rather than mbufs, so it requires a bit more > skill to tune at the moment. > - Sendfile is slightly less efficient at sending small files (for now.) > - The thttpd sendfile support is rather experimental right now. > > So, given that thttpd is very efficient without sendfile support > compiled in, it's not worth worrying about using sendfile with it > yet. Once I finish importing some of the DeBox project's changes to > sendfile, then there will be substantial benefits to using sendfile. Also, if you're handling tens of thousands of connections sending different files, sendfile(2) is a HUGE win for reducing the memory footprint of the server. When sending a handful of different files, however, mmap(2) will be the winner until you move to 5.2+. Alan just committed some bits that cache sfbuf's so that there's only one sfbuf for each page of data sent. In versions prior to 5.2, there was more than one sfbuf for the same page of data read off of disk. If you have other questions about sendfile(2), bring them up on the performance@ mailing list and we can discuss them more there. HTH. -sc -- Sean Chittenden
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031122083340.GA30804>