Slashdot Mirror
The Speed Demon That Is Tux 2.0
gergi writes: "Running at the kernel level, Redhat's Tux 2.0 blew away Apache and IIS in webserving content according to this benchmark! Given the never-ending security flaws found in other webservers, has a major turning point in web server design come about?"
What I really want to know is how well it compares to X-15 (free reg. required), which trounced the original TUX, *despite* running in user mode. X-15 is also open source, and from the guys who make the ChromeLinux web server that was mentioned in the Apache section a while back.
Tux beats apache. Big deal. Apache is slow. Everyone knows that. I want to see Tux take on the current Linux web-server champ.
In consequence, all that this benchmark proves is that proprietary software is pathetic, that over-burdened designs are poor, and that small, specialised tools are by far the most powerful.
Congratulations! Most of the UNIX world came to the same conclusion, over 20 years ago. Hence all the small (but powerful) utilities, rather than one single humungous blob.
What's needed is less arrogance, and more understanding that Small Is Beautiful (And Bloody Fast). A specialised server-side script server, that can do nothing else but handle server-side scripts, would be a good place to start. Essentially, it would be a "shell" for web clients, which could access a handler for PHP, a handler for Zope, another for CGI, etc.
Nothing would be "built-in", and nothing would be loaded unless it was being used. Small apps are fast apps. Less to load, less to page, less to copy in the event of a fork().
The problem with Apache is that there's too much of it. It's a brilliant piece of engineering, but that is precicely the problem. A multi-threaded, multi-purpose, multi-colour device is a marvellous device. It's the Swiss Army Knife of web servers. But, like a Swiss Army Knife, you generally don't use it for cutting steak, eating a hamburger, or mowing the lawn. You use specialist tools for specialist tasks.
This is something that is too easily forgotten. The Osprey is a classic example of why such approaches are doomed. Whatever turf it's on, it's always going to be the turf of the other guy. And that means it's always going to be inferior. Yes, overall, it can beat the pants off anything. Aircraft (with the sole exception of the Hawker Sidley Harrier) cannot fly vertically. Thus, in situations where vertical flight is necessary, the Osprey cannot be matched by (almost) any conventional aircraft.
Likewise, the Apache web server can compete in more arenas than ANY other web server in existance. But the price for this flexibility is that it will NEVER seriously compete with any specialised web server, of any kind. It can't.
Now, the question is: Is this a price you are willing to pay?
If the answer is yes, then Tux 2.0's performance can go rot in /dev/hell. If the flexibility is of overriding priority, then the speed penalty is of no consequence.
If the answer is no, then you need to get a specialist web server for each type of transaction you wish to perform, PLUS a transaction server which can fire up the necessary tool and hand over the transaction to process.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
TUX can serve dynamic content VERY fast, even running CGIs. Because of the overhead of dynamic linking, we recommend that CGIs running under TUX be linked statically for maximum performance. (This is, of course, not an issue for TUX modules, since they are loaded at server start time, not at each invocation.)
While TUX does have a fast path that can serve up static content without ever reaching user space, there is an option to send all requests through user space that only costs a few percent of performance even in the worst case. This can allow all sorts of interesting fine-grained control.
-- "Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"
Not only that, but IIS (with SWC) also beat Tux 2.0 on nearly identical hardware. The question is whether or not the difference in hard drives was enough to account for the difference in performance. My hunch is that it is, but that's just a hunch. Either way, it's obvious that MS have been shocked into action by the performance of Tux, and have come up with something comparable. I'd like to see a real comparisson of Tux, IIS/SWC and X15 on identical hardware.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Is running in the kernel necessarily safe? No, probably not. However, the Linux kernel is intrinsically safer than the NT kernel. Add the patched CAP functions to the kernel, and limit what the web server has access to. Besides which, if your data is that important to your company, you shouldn't be hosting anything on your web server BUT your web server pages. There shouldn't be any other logins or user accounts, the server should be in a extranet, and the only access allowed from it to other boxes should be from it to your backend database servers or such. Those connnections should be limited to some dumbed-down user equivalent in the DB. So if the machien gets hacked, the hacker can see all the web pages that he would have been able to see through the web server anyway, and can connect to your database to see data that he would have been able to see anyway.
Even in NT, this should be the case. Your web server being hacked, while problematic, should not be cause to call in the National Guard while S'Kiddies make havoc on your network. There's nothing wrong with Kernel-space applications when the box is set up correctly to account for the possibility of it being hacked.
In addition, Apache itself is marginally attackable by hackers anymore. Most hack attempts come through poorly configures applications on the backside that yield access to the server.
This space for rent. Call 1-800-STEAK4U
This space for rent. Call 1-800-STEAK4U
The main kernel improvements from Tux have been merged into the mainline kernel, so there really isn't anything interesting that Tux can do which can't be done in user space. I agree that running a web server in the kernel is a risk. Moving that to user space and running as a regular user should be the next step. There has been much yakking on linux-kernel about a user space web server that outperforms Tux.
X15, an experimental user-space server written to "compete" with Tux is faster:
h tml#3
http://kt.zork.net/kernel-traffic/kt20010507_117.
Frankly, from a security perspective, having a public-facing daemon running in kernel space is utterly frightening.
Apache is meant to have configurability over performance, and does dynamic content. However, I'm sure we'll see better performance from *nix based Web servers over time. Paul
http://www.pauldrobertson.com
Why? Apache's currently the market leader... 60% share, or something like that, so of course we're best served by them comparing it to the most widely used server...
For those who aren't aware what Tux is, it's a cute penguin--the linux mascot. The real news is that it can now swim faster than a military aircraft can fly.
Celebrate the finer things in life
So is Tux 2.0 really any more secure than other web servers, or is it just that since it doesn't amount to a noticable percentage of servers, crackers haven't been trying to break it?
Is there anything fundamental about the design of Tux that should make us feel secure?
Hi Spoing, the story doesn't position Tux as a competitor to Apache. In fact, we went out of our way to test the combination of Apache and Tux working together, as well as Tux and Apache (and IIS) on their own. We point out how well Tux and Apache work together and recommend that combination.
You may have come to your conclusion only on the basis of the title of the Web article, which is different than the print version. I think the print title is better, which is Tux: Built for Speed.
Also, I think that painting all stories from all Ziff-Davis publications with the same brush is too broad a generalization. The company produces content aimed at everything from home users and gamers to IT managers at companies that spend millions of dollars a year on technology (the later is eWEEK's market). You're more likely to find stories you like by following the work of particular authors or publications than the activities of an entire publisher.
Regards,
Tim Dyck
West Coast Technical Director
eWEEK Labs
I would add that speed is a selection criterion for only a very small number of sites. Most corporate web servers I've worked on are served by anywhere from xDSL-class to T3 class speeds. Apache on a high-end Lintel box would keep that pipe full without being overloaded. (depending on the complexity of what's being served, of course! A lot of servlets that do 9-table joins in a Sybase database, all on the same box as the web server is quite different from serving only static HTML) So would IIS and Tux, since they both perform better. For that small number of sites (of the slashdot size, perhaps? ;-) that have pipes big enough to keep several server farms busy, ten percent less CPU demand can be big $$$ savings.
"Optimization" sounds like it is a single thing, but my "optimal" might be very diffeetn from yours. It is, as always, a cost/benefit question.
Why is running Tux inside the kernel so great? IIS has had a kernel module since IIS 1.0. And Microsoft got hell when it moved NT's graphics code into the kernel in NT 4.0.
;-)
This reminds me of a joke my CS professor made about operating system research: the "endo-kernel". Microkernel researchers try to move OS features from the kernel to userspace processes for extra protection and modularity. Other researchers (such as UW's SPIN OS and now Tux) move application "modules" from userspace into the kernel to boost performance. So now the "endo-kerenl" OS will be upside-down: OS running in userspace processes for protection, but applications running in kernel space for performance!
cpeterso
Capacity for servers is generally bounded by dynamic processing workload and network bandwidth, not suffling bytes from the drive to the network card. If it is, you're pushing way too hard for a live server.
Take slash, for example. If apache was 10 times faster, they would still need exactly as many server as they have now.
Only a site that serves ONLY static pages will benefit, but then for static pages even the slowest web servers can saturate all but the fastest network connections.
Tux is a static web server, whereas Apache and IIS are both full-blown dynamic web servers.
Where is everybody getting that Tux 2.0 is a static webserver? Here's the quote direct from Redhat's page:
TUX is a kernel-based, threaded, extremely high performance HTTP server. It is able to efficiently and safely serve both static and dynamic data.
ZD's test was a mix of 60% static and 40% dynamic. So...???
What's your damage, Heather?
Exactly how is Linux kernel mode any safer than NT kernel mode? Once I'm in kernel mode I can do absolutely anything, regardless of the CAP functions - just hack up the kernel memory space and make all sorts of function calls around them. Code running in a processor's priviledged mode is (by definition) trusted code.
Personally, I'd be suggesting that the NT kernel space may be marginally more effective given that the kernel can be paged in and out which makes writing kernel buffer overrun stuff slightly more error prone (BSOD).
It comes down to the fact that if someone can run arbitrary code in kernel mode, they can relatively easily (at a minimum) switch out of protected mode, format all your hard drives, erase any tapes that may be in the machine (via BIOS calls) and basically render your machine worthless. This is WITHOUT calling any kernel functions!!
Of course, if you want to be more subtle, just rewrite the syscall interface table to some hooks that subvert the security of the system and let it appear to continue running normally while allowing you access to stuff you shouldn't (like passwords of users that logon to the site and other fun things).
Fear: When you see B8 00 4C CD 21 and know what it means
Posted yesterday, yet another IIS sploit, I will ignore details and skip to the funniest section of the notice:
Funny:
Some people might wonder why this advisory does not contain the typical eEye
humor like most of our other advisories. Basically, the reason is that this
is our 4th remote SYSTEM level IIS vulnerability and well...we've run out of
jokes.
How we know is more important than what we know.
Nothing like a real world test
You're committing the age-old fallacy of assuming that all of us slashdotters are of one and the same ideology.
Have you found any of the same posters that criticized IIS and ALSO praised TUX? If so, then you have a valid response. If not (which I'm assuming), then SHUT the HELL UP!
I've said it before and I'll say it again. Slashdot readers are not of one common philosophy. We're a community of various people with various beliefs, who live in various countries, who use various software, etc. STOP assuming that we're all one and the same!
If Joe Linux complains about IIS, fine. If Mary Linux praises TUX, that's fine. It's NOT hypocrisy when different people give their opinions on different subjects! .V / _` (_-<_-<
.\_/\_/\__,_/__/__/
__ __ ____ _ ______
\ V
make world, not war
Hypocrisy: Duplicitous behavior.
(Much respect.)
---
Given the never-ending security flaws found in other webservers, has a major turning point in web server design come about?
Let's see... I can make Apache or IIS run as a specific user whose access I can (largely) control, or I can run my web server in kernel space....
This is going to end "security flaws"?
I'm not so sure putting the web server (ie, more code) in the kernel is a good route to better security; it increases the trusted codebase. Perhaps the simplicity of the server makes up for this, but that's because it's simple, not because it's in the kernel.
Kernel-space web servers are a good idea for people who need super high-volume serving of static content. Those people hopefully also have the resources to maintain something as potentially dangerous as that. It's good for benchmarks, too.
But most people do not need this kind of speed; serving up static content, I'm sure a T1 would max out before a modest desktop machine would max out its CPU running apache. What people do need is safe software which needs little maintenance -- experience has shown that many users do not stay up-to-date on patches. Therefore, I say that moving to yet lower levels than userspace C (ie, the kernel) is a bad idea, in fact, we should be moving to higher level languages where more safety properties are guaranteed. Presumably, while this might lead to slower web servers (I don't think it would be more than a few percent), it would also lead to fewer bugs and lower maintenance costs. That's the real cost of software, after all!
Statement: Hey, everybody, IIS is blazing fast because it runs in Kernal space!
Response: That's stupid! It'll crash the server! It'll compromise security! Statement: Hey, everybody, TUX is blazing fast because it runs in Kernal space!
Response: Wooohooo! This is a major turning point in web servers! Yay Linux!
Vintage computer games and RPG books available. Email me if you're interested.
I think a comparison between TUX, Zeus, AOLServer, Apache, etc. might have given more useful results.
I am honestly sick of Ziff, though. They are the Mickey-D's of the computer press, and while they have thier place, and offer up the occasional useful story, I would really like to carve out a Ziff-free, or at a minimum a Ziff-limited one.
Plea: Could the great and all-powerful Slash web meisters add a check box for blocking Ziff stories?
Thanks for listening!
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
It might just be me, but I'm a *little* wary of the security implications of something running right in the kernel of the operating system. I smell security breach *somewhere* lurking in this product.
But, it is always nice to see progress, and I'm glad that part of the credit is given to the kernel developers and their speed improvements in the 2.4 kernel over the 2.2 kernel.
--You will rephrase your request for me to go to hell. Goto statements are not acceptable programming constructs
You can't lump Tux in with general Web servers, since it's rather limited as to what it can do - remember, it's only for STATIC pages. You still need an additional Web server for CGI programs or any sort of dynamic site or one that relies on modules like PHP.
Used correctly, and in conjunction with Apache (or another server) Tux is an *extremely* welcome addition to the stable. Props to the people involved on this.
Arrggg!
Why can't people read? Tux can handle dynamic content. If it couldn't, it wouldn't be able to run the SpecWeb benchmarks. The reason why Tux is fast is *not* because it supposedly cannot run dynamic content. It can. The reason that it is fast is because it runs in the kernel and is highly optimized.
Those of you who think that Tux can only handle static pages are thinking of khttpd.
Do your bloody research! At least read the story linked to.