Forum OpenACS Q&A: RH Tux 2.0

Collapse
Posted by Talli Somekh on
hey guys,
<p>
Did anyone see this article about <a
href=http://www.zdnet.com/eweek/stories/general/0,11011,2774242,00.htm
l>RH Tux 2.0 being benchmarked</a> as 2-3 times faster than apache?
I've never heard that AOLserver is that much faster. Of course, this
was done with static content, no DB calls.
<p>
Is Tux a server to keep an eye on? Anyone have any
experience/comments?
<p>
talli
Collapse
2: Response to RH Tux 2.0 (response to 1)
Posted by Petru Paler on

First, the SPECweb benchmark (which Tux was subjected to) is a mixed static/dynamic benchmark. Tux is not only a static web server (like the old khttpd) but a full-blown one (for example, the PHP 4.0.6 will have a SAPI module for Tux).

Second, yes, Tux is definately a web server to keep an eye on.

You can get more info from the Tux manual at http://www.redhat.com/support/manuals/TUX-2.0-Manual/index.html.

Collapse
3: Response to RH Tux 2.0 (response to 1)
Posted by Pascal Scheffers on
Tux's primary aim is static content, but it will handover the connection to a _user space_ webserver if it's a dynamic page. I have absolutely no idea how many (Open)ACS sites are streaming a lot of static content like images, music and movies. Those sites may benefit greatly. But I do think Tux is something for the OpenNSD (how is that comming along?) crew to look at, at first.

If I understand correctly from the kernel-traffic-digest (kt.zork.net) Tux does most of it's magic by mapping the disk-I/O buffers to the same location as the Network-I/O buffers, saving atleast one buffer-to-buffer copy on each page hit. If you read the discussions on Tux (and SPECWeb) you will find people who consider Tux a gimmick to people who never want to live without it again.

I can not backup my hypothesis with actual data, but my guess is that almost any machine capable of doing web/db has more internal I/O bandwidth than is ever going to be consumed by network I/O.

Collapse
4: Response to RH Tux 2.0 (response to 1)
Posted by Petru Paler on

Not true: Tux can generate dynamic content itself. Tux modules can create dynamic "objects" which are stored inside the kernel pagecache from where they are directly DMA'ed to the network card.

Your comment regarding internal vs. network bandwidth is true, but things change when you're trying to saturate a fast connection (think gigabit).

Collapse
5: Response to RH Tux 2.0 (response to 1)
Posted by Pascal Scheffers on
Hmm. Should have read more carefully about the modules. Still, with the risk of entering a religious debate, I do not like kernel-space things that do user-space tasks. It would seem they realize they need to keep it simple, if you look at the security page - it will only serve world-readable non-executable etc. files.

And I have no idea of how to saturate a gigabit connection, with or without Tux :)

Collapse
6: Response to RH Tux 2.0 (response to 1)
Posted by Petru Paler on

Tux modules run in their own address space (so if a module crashes, the kernel and Tux continue to work) and are unprivileged. Thus, their use is safe, while you continue to get the performance gains (in-pagecache dynamic objects, and the elimination of context switch overhead).

Collapse
7: Response to RH Tux 2.0 (response to 1)
Posted by Tom Jackson on

So wouldn't any bug in the TUX kernel code have the potential of compromizing the entire machine, or are all requests handed off to the nobody user/group. With the recent perm bug discovered in AOLserver, it is easy to see how this could be an issue.

Collapse
8: Response to RH Tux 2.0 (response to 1)
Posted by Petru Paler on

A coding error in the kernel side of Tux would (at most) allow a malicious user to crash the kernel. I doubt there is even a remote possibility to exploit a buffer overflow in kernel-level code (be it Tux or something else).

A coding error in a custom Tux module would not allow an attacker to take over the machine, crash Tux, or do other nasty things.