Slashdot Mirror
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.
What i would like to see, is some serious testing of all current unix'es, doing real world tasks... Focusing on not only their performance, but their stability, AND load bearing... ( who cares if something is fast, if as soon as a great load comes, it crawls )
Something like THIS
FreeBSD...
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?
There's a bad link in the story. "Ingo's informative post" in the initial Slashdot story is linked to slashdot.org.
Given that a benchmark as popular as this will tend to have vendors adding, uhh, "features" to make their webservers run faster for the benchmark, how did you manage to beat them anyway? Did you modify the TCP/IP stack? DoS the other servers during the test? Connect a compulsator to a large coil? Slashdot is dying to know.
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?
Tim, after Windows/IIS's outstanding performance in the Mindcraft tests, why weren't we given the opportunity to pick the brains of the Microsoft engineers? Come on. They're smart people too.
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
With the advent of Tux would linux win if the Mindcraft test ran again? Or is the Mindcraft test still slanted towards Microsoft's operating systems?
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
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
The hardware differences somewhat devalued the original SPECWeb benchmarks.
If the pointy-haired stupids see this, they just say, "Oh but look, they slugged the results by running Linux on faster kit"
If the smarter people see it, they'll be kept too busy explain-o-LARTing to the stupids how irrelevant this is to be able to get full use of it in the Great Jihad against Redmond.
... anbd if M$oft's PR Weevils see it, they'll probably whine to the DoJ about unfair competition.
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
Firstly, I'm no Linux expert or OS expert.
Is having the web server in the kernel a security hazard ? Does it increase the potential for damage if there is something like a buffer-overflow exploit in there too ? There are good reasons why the muggles and their IP-tomfoolery are normally kept out of the kernel.
Can you imagine the uproar if M$oft announced a new IIS embedded in kernel32.dll ?
Molog
So Linus, what are we doing tonight?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
WWJD -- What Would Jimi Do?
I am quite civilized, and I should be brought a beer immediately. -- Bruce Sterling
Probably because the last thing that we needed was an interview where the questions are coming from a group of really angry, biased, emotional people. The questions that would have made it would probably would not have been constructive.
I know that I would have fired off a couple of nasty questions, and the moderators are human just like the rest of us.
That and the fact that I don't think that they would have agreed.
Disclamer - Opinion of Person
Did you try to become a world famous programmer? Would you be this famous if did not release your code under GPL?
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?
Most powerful = Fastests?
Sorry, this is off topic (I got to it via an article mentioned in the story), but:
Windows User Rant (and quote here:)
This diatribe should show that immaturity is one thing the Linux community definately does NOT have a monopoly on. Why do the press of all sorts mention the rudeness of Linux advocates, yet fail to do the same for Windows advocates? This is hardly unusual. Any discussion on zd-net or elsewhere features similar mindless rants, yet they are ignored.
Perhaps the next time some 'journalist' mentions how Linux advocates act, they could merely be sent the URL and quote of something like the above to prove that it works both ways. At the same time send some of the essays written by ESR, Linus, Alan Cox, etc, etc, etc, etc, etc to show that there an equally large (if not greater) number of intelligent, rational, well-meaning Linux advocates.
And if that doesn't work, we could just use this guy's ICQ number, find out what his 'puter's IP is, and crack away>;)
Jesus was all right but his disciples were thick and ordinary. -John Lennon
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.
This is the correct link to Ingo's informative post.
It could be made so that the patent could :-)
be used inn all kinds of Open-software,
but required royalties for closed software.
Software licensed through any kind of "open source"-approved license would do for me
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?
I understand that TUX was primarily designed and coded by Red Hat. Did other Distrobutions/Vendors have there hands in parts of this project? Who and what did they contribute?
Lots of developers create websites under the assumption that higher performance can be achieved by adding more machines behind a load balancing mechanism. After all, hardware is cheap compared to the cost of creating a website. Under this assumption, the scalability of a webserver does not matter nearly as much. Given this assumption, do you still feel that there are still benefits to having kernel-space http functionaty? Even compared to the risks of extraneous kernel code?
I suppose I'm not too threatening, presently, but wait till I start Nautilus
It would seem to me this would be a very fast cache/proxy sever. Embed it in hardware and you've a very cool little product.
When someone yells "Stop" or goes limp, or taps out, the fight is over.
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
OK, the main point of your post - linux kernel modules don't obviously fit with a cross-platform app - is interesting. But where are you coming from with this "SQL servers" question? Assuming that you're talking about databases, you probably should give us some evidence or references. I've been developing database-centric web stuff for a while now, on linux and NT among other platforms, as well as talking to others doing the same, and this is the first I've heard that the microsoft database had any sort of advantage over those availible on linux (other than pretty pictures in the admin interface).
----------------
The troll (or, if he's not a troll, the guy with severe reading comprehension problems) neglected to preserve the emphasis on the word "sell" in his quote, altering the meaning somewhat.
Do you ever slap yourself on the ass and shout out "YOU CANNOTTA HAVA THE MINGO! BEGONE!"?
DontBlow.com is an absolute good.
Do you think that ultra-high-end web servers, such as TUX, will ever be able to compete with dedicated systems such as Transputer nets, or dedicated WWW OS', such as Exopc + Cheetah?
(The overhead of a full-scale OS, plus full-feature system library, plus massively-extensible WWW server -must- impose penalties on multi-purpose systems that simply don't exist for the more basic systems. And transputer networking is a LOT less heavy than that SMP quagmire.)
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 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.
Would you recommend the use of loadable kernel
modules as a mechanism for developing/improving
other services?
Beyond the use of TUX, what other features/fixes/
tunes may be necessary to move Linux into more of
the enterprise class of servers?
How long did it take to develop TUX? What about
Linux helped/hindered this development?
Is SPECweb a good benchmark for TUX? What would
you like to see in a better web benchmark?
F is an odd number...
Given that a benchmark as popular as this will tend to have vendors adding, uh, "features" to make their webservers run faster for the benchmark, how did you manage to beat them anyway? Did you modify the TCP/IP stack? DoS the other servers during the test? Connect a compulsator to a large coil? Slashdot is dying to know.
--
You are a fucking moron.
How do you feel that your name slant rhymes with mine, as I am named Bongo?
And, as a necessity to satisfy the urge inside of me, DID THE DINGO EAT YOUR BABY?
To generate high spec numbers such as this, you blast MS for running the GUI in kernel space and heres linux serving http from the kernel.
Only the State obtains its revenue by coercion. - Murray Rothbard
How does TUX handle the configuration of the server? Since it seems to be pretty much kernel level code, does it need a reboot for new configs? Or is it just read into memory using user space code?
.sig
Can TUX handle apache modules as of now?
Is this technology possible to implement on FTP, SQL, SMTP etc. servers?
uhmm... the patent question was taken, so was the threading and the portability... hmm... I guess I have no further questions, your honor.
Tux uses features of the Linux kernel. IE uses features of the Windows shell and COM framework (both of which are portable, though not easily).
Hands in my pocket
TUX is a combination of kernel-space HTTP and kernel-space caching. Would it be possible to have a user-space version of TUX that uses shared memory instead of kernel memory? The first mumblings I've heard are stability and security worries of having a kernel-space implementation. The user-space version would always be slower than the kernel space version (at least one extra memory-to-memory copy), but would the object caching by itself provide a speedup?
And out of curiosity, how generic is the TUX caching mechanism (is it more like a namespace for kernel-space shared memory)?
-spRed
.sig Karma out the wazoo, better to spend points elsewhere if this is above 2 or below 0
Other than webserving via TUX or khttpd or what-have-you, what other functions that traditionally run in user-mode do you think might be usefully moved (optionally, of course) into the kernel. One that comes to mind is Quake Arena servers (I could be way off base though!), and perhaps other services where latency is critical (is NFS in the kernel yet? I forget).
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?
The advantage of putting TUX in kernal space is that it saves a step in UNIX's typical copy, copy, copy, copy behaviour.
UNIX wastes a lot of time copying data multiple times before it ever gets to a userland process, and it takes the same hit to get it into kernal space where the network stack can get at it.
See EROS (www.eros-os.org) and the I/O Lite project (I think I/O Lite was done at Rice university, but I'm not sure.)
I/O lite was a completely copy-free I/O system for OSF-1, and EROS is a research project that demonstrates (among other things) how to do I/O correctly.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
response to B: .sig is invalid, because you're NOT A TROLL!
You're missing my point. Your
But, we'll forget I said that, since you seem to have a sense of humor, and I just happened to read one of your more inane messages. So, um, yeah, you are a troll (occasionally).
nevermind.
_________________________
_________________________
heLlo... myy naame issh Linush Thoralvades, and I pronounsch (hic) it, "vodka"!
Since the kernel will have a full HTTP stack in it could/will this functionality be extended to do things like load balancing HTTP requests? Since the kernel will have a full HTTP stack it could, in theory, do high performance cookie based stickyness... just like the big guys (F5, Arrowpoint). This would be a wonderful supplement to the Linux-VS project (TCP vs. HTTP balancing). Even nicer would be SSL session based stickyness (am I asking too much?).
I realize this could significantly bloat the size of the kernel module, but it would be a small sacrifice for saving between $50,000 - $70,000.
Last time I used an object cache with Apache was Squid. Setup wasn't too bad, you bind Squid to port 80 and it passes any requests for dynamic pages to Apache. Is tux going to follow the same kind of setup? Tux looks nice, but there aren't many people who can live without mod_php/mod_perl or mod_ssl. How is this going to work with Apache now, and in the future?
Are these results even relevant outside of benchmarks?
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.
I'm aware of that, that's one of the reasons I use Linux for...
.sig
It was more meant to soften the question and not give that "I know this better than you" look to the question...
Say, didja ever think that maybe forks also take advantage of multiple processors?
And didja ever think that user threads, where the kernel knows nothing of the threads, can't take advantage of multiple processors?
--
Infuriate left and right
What does this mean for linux userspace? it cannot cut it? Okay, let's say user space could produce a more functional web server, it would run how fast? 50% of tux? 60% of tux? That's unfortunate. Can we get some help bring the raw power of the kernel to user-space? Is glibc gonna do it? While I have your attention (two little questions): 1) how does this affect performance of the rest of the machine (ie: does TUX have low nice value? open to DoS?) 2) mod_perl ;) Thanks Ingo, for great kernel work..
I doubt that this was an original, but it was one that a friend of mine likes to use.
"However right or wrong a zealot might be, the fact is that this person is still a zealot."
The line must be drawn here. This far. No further.
For an ecommerce site, speed of page handling and cgi calls is important, but so is getting that customer through the checkout aisle. What kinds of performance gains might be seen when comparing https pages between Apache and Apache+Tux?
The line must be drawn here. This far. No further.
The Linux kernel has had threads for a very long time now. In fact, it has no other concept available to user-space for an executable task.
Threads are either alone in the VM, in which case we call the whole thing a ``process'', or there can be more threads of execution in one VM area (a so-called multithreaded process or whatever). The difference is _only_ whether there's one or more threads in that VM area.
The difference between Linux and NT is, to the programmer, that on Linux you usually use the pthreads library to create a thread (the library will call clone() which tells the kernel to create a new thread), whereas on NT you use the Win32 library call CreateThread() to tell the NT kernel to create a thread.
pthreads is fairly inefficient, which is why some people believe that threads aren't native to Linux. That is, using pthreads compared to a fork() isn't a lot faster usually, whereas on NT CreateThread() is a lot faster than CreateProcess(). What people tend to forget is, that creating a full-blown process using fork() on Linux, is still a lot faster than creating just a single thread using CreateThread() on NT, on identical hardware (measured in clock-cycles from start of call till first line in new process/thread is reached - source is article LJ some time ago).
Threads can't work much better in the Linux kernel. The pthreads _library_ could probably be improved to make thread creation faster, or you could just call clone() yourself. But this is not a kernel issue.
I think as soon as someone does something like this, it naturally comes to mind, "hmm, why do I have all that other crap on my {web, sql, ftp, email} server anyway?"
Considering that the trend of the 90s was to centralize services so that each server performed only a single function (the webserver, the fileserver, the pdc, the mailserver...), do you think that people trying to minimize maintanence will be moving toward "appliance" computers, with only a single server app and a stripped down operating system?
We've seen it before -- routers used to be real computers. Now -- when's the last time you heard of a router crashing?
Do you see server rooms in five years looking like a component stereo system?
Moderation Totals:Flamebait=1, Redundant=1, Insightful=2, Interesting=5, Overrated=2, Total=11.
Since this is comment #4 and 1-3 are all "first posts", this can't be redundant. That's one moderator on crack.
Then we have 1 other who isn't able to read, and 2 who either feel threatened by questions about Linux security or stability OR are moderating based on username.
Dimwits.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)