Ask Ingo Molnar About TUX
Ingo Molnar is the guy behind the TUX Web server, which produced those astounding SpecWeb results reported here last week. He's agreed to a Slashdot community interview. So ask away at the man who created what appears by some measures to be the world's most powerful Web server at present. Please make Ingo's job easier by first reading the LinuxToday articles (here's the first LW story, and here's the second LW story) commenting on the SpecWeb numbers and the background of how they were achieved, as well as Ingo's informative post in the initial Slashdot story, and the SpecWeb
results themselves. The moderators may have no mercy otherwise.
You killed my penguin.
Prepare to die.
God Fucking Damnit
Given that part of the explanation for Tux's impressive performance is the use of a kernel-based httpd server, how much how stable and secure do you expect it is.
BTW, this isn't a flame. I'm sure it's better than IIS/NT on both fronts--but is it better than Apache/Linux, even after factoring in the speed?
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
What is the reason for moving the http server into the kernel, I do not see any benefits to it, could you enlighten me about it.
Would you ever advocate using TUX as a real life web server?
Think of a high availability environment, where you are building a highly dynamic application such as an e-commerce system. Would you even think of using TUX in such a situation, or would you go with the far more sensible Apache + mod_backhand + (pick one of mod_perl, php, or servlets)?
The problem is, its all too easy to generate web server software that can withstand a high "hit" rate. But the pressures on web servers, and particularly web developers, lie in completely different areas: Time to market, ease of development, and configuration capability.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Are there any plans for or existing features in Tux that allow for adding custom modules such as WebDav? How about custom protocols?
This is a version 1 of the web server, and it has proven itself to be pretty nifty when it comes to serving both static webpages (through a kernel level httpd) and dynamic webpages. Do you see TuX getting more lean and faster as time wears on, past versions 2, 3,
Will there be a way to port an existing Apache configuration across to the TuX configuration? How about IIS, Netscape, Zeus, etc? Will TuX have the option of a GUI setup screen for those who don't like the command line? Will TuX have a simple installer?
This is based very much on the Linux kernel, so I presume that it couldn't be ported easily to different kernels. Hwever, are there any major optimisations dependent on the use of a x86 architecture?
What is the target purpose of TUX? From the benchmarks, it appears to be for very high traffic sites. I ask because I'm curious if that is its specific purpose, or does it serve well in other areas as well (i.e, Apache flexibility)?
This is important because it will also help indicate what Red Hat's stance will likely be in either replacing Apache with TUX or just including it in their Professional distributions.
It works with Apache but is TUX generic enough to be interfaced with another server?
Does/Will TUX provide any sort of load balancing for a cluster of heterogenous TUX servers?
You mentioned in the second Linux Today article that you intend to integrate TUX with Apache. However, Apache has always been a cross-platform server and is heavily used on *BSD and Solaris. Do you feel that this integration will undermine the portability work of the Apache team, or will it simply provide an incentive for web servers to be running Linux? If you intend to encourage people to move to Linux, can a similar idea as TUX be applied to an SQL server to make up for the speed deficit between Linux SQL servers and Microsoft SQL?
You've said before on slashdot that TUX supports a number of usability features, although not the full complement. Could TUX have been made faster at the job of serving static pages if you had ripped out every single extraneous bit? What if TUX had been small to the point of being basically unusable in the real world, but served pages faster even than it does now?
The question is, would that have been a fair benchmark?
If your answer is No, then the followup question is, how is that materially different from what you *did* do?
-konstant
Yes! We are all individuals! I'm not!
-konstant
Yes! We are all individuals! I'm not!
Ingo's informative post.
-russ
Don't piss off The Angry Economist
In the second LW article, ingo writes:
- So in our opinion TUX is a new and unique class
- of webserver, there is no prior art implementin
- such kind of 'HTTP stack' and 'abstract object
- cache' approach. It's i believe a completely
- new approach to webserving. Please read this
- comment too, which (i hope) further explains
- the in-kernel issue:
Maybe I'm paranoid, but "new and unqiue"
and "prior art" in the same sentence mean
patent filing to me.
Are there plans to see patent protection for
TUX? As I recall, the RTLinux folks got a
patent for RTLInux's prioritization stuff.
Is a patent in the works?
Regardless, TUX is an interesting idea and I hope
to try it out soon.
--chuck
I think the link it should be is here, though he answered a bunch of questions in that story. If you browse through his user-info, you'll be able to see all of the informative posts he's made recently...
What is your opinion on the current thread implementation in the Linux kernel compared to systems designed from the ground up to support threads (like BeOS, OS/2 and Windows NT)? In which way could the kernel developers make the threads work better?
War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
What do you see is the primary market for TUX? With the ability to handle such high traffic it would be suitable for busy e-commerce sites, but I'm sure there will be more than a few people who are wary about a http server in their kernel. However, the embedded market might see this as a good thing and allow for web-based configuration, monitoring, etc of embedded devices. I would think there would be more people willing to just throw the webserver in kernel to save space if nothing else, but of course this still raises the security/stability concern.
So the main question is really just where and in what applications do you see TUX in the future?
Things you think are in the Constitution, but are not.
How would TUX perform using CGI/Servlets/PHP/etc. compared to Apache or IIS? The ability to serve static pages fast is not that useful in the real world, as all the sites that get really big hits-per-second are those with dynamic content (Yahoo, Slashdot, Amazon.com, etc.)
"Evil beware: I'm armed to the teeth and packing a hampster!"
Lex orandi, lex credendi.
How will the TUX Webserver integrate with RedHat's Linux distributions? Will RedHat create a special distribution with an identical setup to yours? Will RedHat start releasing more specialized distributions, preferably ones more suited to a secure server environment but focused on performance like your setup was?
As it is RedHat seems too insecure and bloated for a streamlined server environment. Ideal would be installation options where I can say "This server will do these 3 things (i.e. DNS, Mail, HTTP) so make it suited for that and nothing else." This kind of flexibility would be a HUGE boon to the server market, giving customers a high performance machine running TUX + Apache that was secure and did the functions they needed it to.
Yea that was a long question, you can chop off last paragraph if you like. Hehe, insecure and bloated, can we say WinNT/2K?
"I want to get more into theory, because everything works in theory." -John Cash
"I want to get more into theory, because everything works in theory." -John Cash
I have a few questions about TUX's caching system. Before I go any further, I want to say that I'm incredibly impressed by the results. I've been following specWeb99 for a while and have been wondering when someone would manage to build a great dynamic cache like this one. I hope it'll get the wide acceptance it seems to deserve. .GIFs, but not .html files"), and expiration/reloading algorithms?
First, it seems that basically the entire test file set was loaded into memory ahead of time for use by TUX. How adaptable is TUX to more dynamic, limited-memory environments in terms of setting cache size limitations, selectivity (e.g. "cache all
Second, can a tux module programmer modify the basic tux commands, or do they always do the same thing? For instance, if I were adapting TUX to work with a web proxy cache, I'd want TUX_ACTION_GET_OBJECT to actually go out over the network and do a GET request if it couldn't find a requested object in the cache. You can imagine lots of other circumstances where this would come up as well.
Third, is it possible to execute more than one user-space TUX module at one time?
Fourth, when can we play with the code?
Thanks a lot!
--JRZ
I know it's a sleazy thought, but the reason why Red Hat is the most popular distro has more to do with marketing and deals than the code itself.
So my question is this - how will TUX market itself and what kind of deals are you looking at making so that it becomes more widely adopted?
I don't think we need specifics, just some of the general methods you plan to use for marketing and some probable categories of companies you are looking at making deals with.
[yeah, I know, free bheer - but it's a good question]
Will in Seattle
WWJD -- What Would Jimi Do?
I am quite civilized, and I should be brought a beer immediately. -- Bruce Sterling
TUX includes a variety of kernel and apache changes. Can you give a rough measure of how each of the changes improved the http performance? I'm interested in the amount of improvement as well as why it improved performance. Do those particular changes have negative impact on the performance of other applications?
Are you afraid that if a particularly buggy version of TUX slips out the door and trashes people's systems and loses valuable data, that a certain angry penguin will open a whole can of whoopass on you for defamation of character? Are you investing in reserves of herring and icecubes in anticipation of this event? Perhaps an adapted Ursus anti-bear suit?
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
You deserve a beer. I'll send you some. What kind do you want?
(Assuming you're not like Raster and would rather have spirits....)
There's more to it than this.
You appear to have take an "architectural" approach to designing TUX, so I have some architectural questions.
How will our favorite Apache modules, like mod_perl and php, be helped by TUX? Will my mod_perl code or php code run faster with TUX?
Have you tuned TUX for any particular benchmarks, or do you just write it as best you can and throw it in the ring? If it's tuned to some benchmarks, does that hurt its performance on other benchmarks?
Have any benchmark tests ever been particularly useful for revealing bugs/inefficiencies in your code? That is, are the benchmarks tools to you, or are they just the end product?
But rather for the /. crew: when would you see deploying TUX as a server for /.?
This is the real question: when will people for whom serving web pages is their bread and butter adopt this? Apache already has this level of trustworthiness, how long until TUX has it?
www.eFax.com are spammers
TUX appears to me to be rather specialized, eg. if you own a web server, eventually you'll use TUX; if you also serve web pages, you probably won't, just because you don't need to.
Do you see TUX as indicative of a growing realization that general purpose computing might not be perfect for everything? More specifically, do you see it as part of a movement towards more specialize hardware and software? For instance, why should a web server run the same kernel as a workstation, and why should the be built of the same parts?
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
First of all, great job. For those of us whom speed is a primary concern, integrating HTTP into the kernel is a godsend. Obviously this will be a great improvement.
That said, don't you think the hardware differences in this last test are big enough to discredit the results? The W2K machine had an Ultra2 SCSI channel, 80MB per second data transfer vs. an Ultra 160, 160 MB per second data transfer rate of the Linux machine. The test operator claimed that since the machines more memory than the total size of the files they were serving that the SCSI bus speed did not matter. Is this true? Secondly, the Linux box had a dedicated 1000MB/s ethernet adapter while the W2K machine was using a 10/100/1000 NIC. The tester claimed that since they were plugged into the same network, that the NIC's were functionally equal.
In your opinion, do the hardware differences mean anything? I'm asking because if this were the other way around(and the Windows machine won) I think the Linux community would have been up in arms about it.
No, Thursday's out. How about never - is never good for you?
Is it:
No particular flaming intended here; in either direction, this represents "benchmarketing" as opposed to anything realistic.
It may be as unrealistic to "real world" situations to use a highly tuned combo of TUX and Apache and make IIS "look sick" as it was for Mindcraft to use a heavily tuned IIS to make a poorly-tuned Apache look bad.
In which case someone building the next Slashdot might care, as they need to write finely-tuned code, whereas I, when running a lightly loaded web server at home, will have a hard time detecting differences between Roxen, Apache, Boa, and WN.
This isn't quite a flame; it truly is important for a piece of software that you want people to use to be described in an economical manner that makes it easy for people to determine its relevance.
If you're not part of the solution, you're part of the precipitate.