You have to ask the hard questions... Some of this is rooted in
the past when Tux was emerging as a technology rather ubiquitously
available. And, combined with the fact that most customers tend to
lag the technology curve, Apache 1.X or, in our case, IBM HTTPD was
simply a customer drop in with standard configuration support that
roughly matched that on all other platforms, e.g. AIX, Solaris, HPUX,
Linux, etc. So, doing a one off for Linux at a very heterogenous
large customer adds pain, that pain becomes cost for the customer in
terms of consulting, training, sys admin, system management, etc.
We also had some bad starts with using Tux in terms of performance
and scalability on 4-CPU and 8-CPU machines, especially when combining
with things like squid or other cacheing products from various third
parties.
Then there is the problem that 90%+ of our customers seem to have
dynamic-only web servers. Static content is limited to a couple of
banners and images that need to be tied into some kind of cacheing
content server. So, Tux's benefits for static serving turned out to
be only additional overhead because there were no static pages to be
served up.
And, honestly, I'm a kernel guy much more than an applications guy, so
I'll admit that I'm not up to speed on what Tux2 can do with dynamic
content. The last I knew was that it could pass it off to another server.
So we are focused on making the most common case for our customer situations
scale well. As you are probably aware, there are no specweb results
posted using Apache, but web crawler stats suggest that Apache is the
most common server. The problem is that performance on Apache sucks
but people like the features. Hence we are working to make Apache
suck less, and finding that part of the problem is the way it uses the
kernel. Other parts are the interface for specweb in particular which
we have done a bunch of work on with Greg Ames. And we are feeding
data back to the Apache 2.0 team which should help Apache in general.
gerrit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/