From: Fabio Riccardi <fabio@chromium.com>
To: Zach Brown <zab@zabbo.net>
Cc: linux-kernel@vger.kernel.org, davem@redhat.com
Subject: kernel support for _user space_ web server accelerator
Date: Fri, 23 Mar 2001 12:24:16 -0800 [thread overview]
Message-ID: <3ABBB0EF.7A292060@chromium.com> (raw)
In-Reply-To: <3AB6D0A5.EC4807E3@chromium.com> <15030.54194.780246.320476@pizda.ninka.net> <3AB6D574.8C123AE9@chromium.com> <15030.54685.535763.403057@pizda.ninka.net> <3ABAC8D4.B464EB9B@chromium.com> <20010323141449.B24144@tetsuo.zabbo.net>
Ok, here it comes again,
I don't like the idea of having a web server in the kernel, I don't think it
belongs there.
Yes I'm pretty familiar with TUX, I believe that it is a foundamental piece of
achievement in web server performance study. Neverthanless I think that it is
sitting on the wrong spot.
I'm building an alternative web server that is entirely in _user space_ and
that achieves the same level of performance as TUX. Presently I can match TUX
performance within 10-20%, and I still have quite a few improvements in my
pocket.
Nevertheless I need some minimal help from the kernel, like a FAST (and
secure?) mechanism for socket forwarding and a better (non-blocking on
files) sendfile interface.
For the time being I'm using a socket delivery mechanism similar to that of
TUX and khttpd, as I stated at the beginning of this thread. I don't like the
idea of patching the kernel, I don't believe that it is a viable distribution
mechanism and I'm trying to find a better way of adding the functionality that
I require as a kernel module.
Currently the "right" kernel network interfaces are exposed to the modules only
if khttpd or ipv6 are compiled as modules. Can we change this such that a
standard binary kernel (say, the one coming with a vanilla RedHat distrubution
or similar) would expose the right stuff?
Would it make any sense to have a real system call doing this kind of stuff?
HELP! :)
TIA, ciao,
- Fabio
Zach Brown wrote:
> > Zach, have you ever noticed such a performance bottleneck in your phhttpd?
>
> yup, this is definitely something you don't want to be doing in the fast
> path :)
>
> > Any thoughts?
>
> Sorry I don't remember the start of this thread, but I'll ask anyway;
> have you looked at Ingo Molnar's Tux server? Its state of the art unix
> serving, implemented in the linux kernel:
>
> http://people.redhat.com/mingo/TUX-patches/
>
> --
> zach
next prev parent reply other threads:[~2001-03-23 20:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-20 3:38 user space web server accelerator support Fabio Riccardi
2001-03-20 3:51 ` David S. Miller
2001-03-20 3:58 ` Fabio Riccardi
2001-03-20 3:59 ` David S. Miller
2001-03-20 4:07 ` Fabio Riccardi
2001-03-20 13:08 ` Erik Mouw
2001-03-20 16:01 ` Zach Brown
2001-03-23 3:53 ` Fabio Riccardi
2001-03-23 19:14 ` Zach Brown
2001-03-23 20:24 ` Fabio Riccardi [this message]
2001-04-18 16:19 ` numbers? Ingo Molnar
2001-04-20 19:35 ` numbers? Fabio Riccardi
2001-04-20 18:42 ` numbers? Ingo Molnar
2001-04-20 21:23 ` numbers? Fabio Riccardi
2001-04-21 3:42 ` numbers? Ingo Molnar
2001-04-20 20:53 ` numbers? Alan Cox
2001-04-20 21:12 ` numbers? Fabio Riccardi
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=3ABBB0EF.7A292060@chromium.com \
--to=fabio@chromium.com \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zab@zabbo.net \
/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.