From: Alex Vorona <voron@amhost.net>
To: linux-kernel@vger.kernel.org
Subject: Re[2]: sendfile to nonblocking socket
Date: Tue, 24 Apr 2007 14:33:48 +0400 [thread overview]
Message-ID: <1211570752.20070424143348@amhost.net> (raw)
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKIEDFDEAC.davids@webmaster.com>
Hello David,
Tuesday, April 24, 2007, 1:19:49 PM, you wrote:
>> sendfile function is not just a more efficient version of a read
>> followed by a write. It reads from one fd and write to another at tha
>> same time. Please try to read 2G, and then write 2G - and how much
>> memory you will be need and how much time you will loose while reading
>> 2G from disk, but not writing them to socket.
DS> You are correct. What I meant to say was that it's just a
DS> more efficient version of 'mmap'ing a file and then 'write'ing
DS> from the 'mmap'. The 'write' to a non-blocking socket can still
DS> 'block' on disk I/O.
How can I avoid that blocking? Or maybe another question - how can I
deliver data from disk to network with minimal copy operations, etc.
>> If you know more
>> efficient method to transfer file from disk to network - please advise.
>> Now all I want is really non-blocking sendfile. Currently sendfile is
>> non-blocking on network, but not on disk i/o. And when I have network
>> faster than disk - I get block.
DS> There are many different techniques and which is correct
DS> depends on what direction you want to go.
_very_ fast frontend web-server :) using as much kernel features as possible
DS> POSIX asynchronous I/O is one possibility.
aio does not support direct transfer file->socket. Using some hints,
like aio reading into shared memory and then sendfile from shared
memory, like lighttpd does, is not what I want. My tests showing
that aio-sendfile realization in lighttpd is slower than sendfile.
I think, sendfile uses less copy operations(maybe even zerocopy), than current aio
realizations in kernel.
DS> Threads plus epoll is another.
20k threads and maybe more is too much :). Look at http://nginx.net/
senction "Architecture and scalability" for example.
DS> It really depends upon how much performance you need
all, that hardware can take and hold :)
--
Best regards,
Alex mailto:voron@amhost.net
next prev parent reply other threads:[~2007-04-24 11:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-23 21:13 sendfile to nonblocking socket voron
2007-04-23 21:59 ` David Miller
2007-04-24 4:42 ` Alex Vorona
2007-04-23 22:52 ` David Schwartz
2007-04-24 4:54 ` Alex Vorona
2007-04-24 9:19 ` David Schwartz
2007-04-24 10:33 ` Alex Vorona [this message]
2007-04-24 12:48 ` Re[2]: " Eric Dumazet
2007-04-24 19:19 ` David Schwartz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1211570752.20070424143348@amhost.net \
--to=voron@amhost.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.