Date: Mon, 10 Nov 2003 17:14:23 +0300 (MSK) From: Igor Sysoev <is@rambler-co.ru> To: John-Mark Gurney <gurney_j@efn.org> Cc: Alan Cox <alc@cs.rice.edu> Subject: Re: Update: Debox sendfile modifications Message-ID: <Pine.BSF.4.21.0311101658540.20172-100000@is.park.rambler.ru> In-Reply-To: <20031109182614.GH558@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 9 Nov 2003, John-Mark Gurney wrote: > Igor Sysoev wrote this message on Sun, Nov 09, 2003 at 15:16 +0300: > > > If you made this a fd transparent operation then I would agree with > > > it. > > > > The current sendfile() implementation works with sockets only. > > Well, I agree that such sendfile() implementation is a hack. > > Nowever this implementation is very usefull in the real world - > > it allows to minimize a data copy in http and ftp servers. > > > > I just could not figure to myself where can be usefull the > > high perfomance sendfile() to a pipe. > > It's not so much of how, but optimizing for the general case, not > the specific case. I was using pipes as an example, what about for > coping one fd to another? Right now cp will try to mmap a 16meg buffer, > and use that, if it fails, it falls back to a read/write loop.. why > not do something like copyfd that does it more optimally? > > > I think that it's better to leave sendfile() as a sending to a socket > > only hack. I believe that any sendfile() generalization (e.g. sending > > data from a socket to a file) is useless. > > oh? why do you think that is useless? What about all the applications > like ftp clients, and wget/fetch/curl that do it on a regular basis? To notice some perfomance impact of using sendfile() in cp, wget, etc I need to run simultaneously hundreds of these applications. To see the perfomance impact of using sendfile() in http or ftp server I need to serve hundreds of clients. The first case is too rare while the second one is common for the busy servers. Igor Sysoev http://sysoev.ru/en/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0311101658540.20172-100000>