Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000

In message [off-list ref], > : "David S. Miller" w
rites:

   From: Gerrit Huizenga [off-list ref]
   Date: Fri, 06 Sep 2002 10:26:04 -0700
   
   One of our goals is to actually take the next generation of the most
   common "large system" web server and get it to scale along the lines
   of Tux or some of the other servers which are more common on the
   small machines.  For some reasons, big corporate customers want lots
   of features that are in a web server like apache and would also like
   the performance on their 8-CPU or 16-CPU machine to not suck at the
   same time.  High ideals, I know, wanting all features *and* performance
   from the same tool...  Next thing you know they'll want reliability
   or some such thing.

Why does Tux keep you from taking advantage of all the
feature of Apache?  Anything Tux doesn't handle in it's
fast path is simple fed up to Apache.

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

quoted

   One of our goals is to actually take the next generation of the most
   common "large system" web server and get it to scale along the lines
   of Tux or some of the other servers which are more common on the
   small machines.  For some reasons, big corporate customers want lots
   of features that are in a web server like apache and would also like
   the performance on their 8-CPU or 16-CPU machine to not suck at the
   same time.  High ideals, I know, wanting all features *and* performance
   from the same tool...  Next thing you know they'll want reliability
   or some such thing.

Why does Tux keep you from taking advantage of all the
feature of Apache?  Anything Tux doesn't handle in it's
fast path is simple fed up to Apache.

You have to ask the hard questions...   

Ultimately, to me at least, the server doesn't really matter, and
neither do the absolute benchmark numbers. Linux should scale under 
any reasonable workload. The point of this is to look at the Linux
kernel, not the webserver, or specweb ... they're just hammers to
beat on the kernel with.

The fact that we're doing something different from everyone else
and turning up a different set of kernel issues is a good thing, 
to my mind. You're right, we could use Tux if we wanted to ... but
that doesn't stop Apache being interesting ;-)

M.

   From: Gerrit Huizenga [off-list ref]
   Date: Fri, 06 Sep 2002 11:19:11 -0700
   
   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.

TUX can optimize dynamic content just fine.

   The last I knew was that it could pass it off to another server.

Not true.

   The problem is that performance on Apache sucks
   but people like the features.

Tux's design allows it to be a drop in acceleration method
which does not require you to relinquish Apache's feature set.

   From: "Martin J. Bligh" [off-list ref]
   Date: Fri, 06 Sep 2002 11:26:49 -0700
   
   The fact that we're doing something different from everyone else
   and turning up a different set of kernel issues is a good thing, 
   to my mind. You're right, we could use Tux if we wanted to ... but
   that doesn't stop Apache being interesting ;-)

Tux does not obviate Apache from the equation.
See my other emails.

   The fact that we're doing something different from everyone else
   and turning up a different set of kernel issues is a good thing, 
   to my mind. You're right, we could use Tux if we wanted to ... but
   that doesn't stop Apache being interesting ;-)

Tux does not obviate Apache from the equation.
See my other emails.

That's not the point ... we're getting sidetracked here. The
point is: "is this a realistic-ish stick to beat the kernel
with and expect it to behave" ... I feel the answer is yes.

The secondary point is "what are customers doing in the field?"
(not what *should* they be doing ;-)). Moreover, I think the
Apache + Tux combination has been fairly well beaten on already
by other people in the past, though I'm sure it could be done
again.

I see no reason why turning on NAPI should make the Apache setup
we have perform worse ... quite the opposite. Yes, we could use
Tux, yes we'd get better results. But that's not the point ;-)

M.

   From: "Martin J. Bligh" [off-list ref]
   Date: Fri, 06 Sep 2002 11:51:29 -0700
   
   I see no reason why turning on NAPI should make the Apache setup
   we have perform worse ... quite the opposite. Yes, we could use
   Tux, yes we'd get better results. But that's not the point ;-)

Of course.

I just don't want propaganda being spread that using Tux means you
lose any sort of web server functionality whatsoever.

On Fri, 2002-09-06 at 19:51, Martin J. Bligh wrote:

The secondary point is "what are customers doing in the field?"
(not what *should* they be doing ;-)). Moreover, I think the
Apache + Tux combination has been fairly well beaten on already
by other people in the past, though I'm sure it could be done
again.

Tux has been proven in the field. A glance at some of the interesting
porn domain names using it would show that 8)