From: Dan Kegel <d...@alumni.caltech.edu>
Subject: Preparations for ZD's upcoming Apache/Linux benchmark
Date: 1999/06/07
Message-ID: <fa.f21iprv.c06qqo@ifi.uio.no>#1/1
X-Deja-AN: 486752568
Original-Date: Mon, 07 Jun 1999 10:32:39 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <375C0237.1190643C@alumni.caltech.edu>
To: john_tasc...@zd.com
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

Hi John,
I've been watching the Linux community's progress in 
fixing the performance problems found by Mindcraft,
and covering that progress in my page 
http://www.kegel.com/mindcraft_redux.html
If you haven't seen it yet, do take a look; I think it's
a good resource for benchmarkers.

Is there any info online about the schedule for and 
participants in the June 14th Apache/Linux benchmark
you're hosting for Mindcraft
(http://www.mindcraft.com/openbenchmark.html)?  
If so, I'd like to link to it.

Also, Juergen Schmidt's recent tests for c't magazin were
rendered partially invalid because he neglected to
configure Apache to block in accept() as required for
maximal Linux performance.  He was informed by several 
people of the error as soon as he posted his config 
files, but by then it was too late.

I'd like to prevent similar problems in the upcoming tests.  
Perhaps a mailing list should be set up for posting and 
discussing proposed configuration files before the test.
That way, remote participants can eyeball them for trouble,
and suggest improvements.

The publication embargo, by the way, might get in the way
of getting the best possible results.  Perhaps it could
be modified to allow posting of intermediate results 
as long as they did not mention absolute performance numbers
or comparisons with other servers; enough benefit would
come from posts of the sort "Performance levels off at
80 clients" or "SMP performance is no better than uniprocessor
performance".

It would add a little openness, too, to have the
folks representing the Linux side introduce themselves
to the mailing list ahead of time.  As it is, 
there's still a bit of mystery about the tests.

Cheers,
Dan Kegel
http://www.kegel.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/





From: Steve Bergman <st...@netplus.net>
Subject: Re: Preparations for ZD's upcoming Apache/Linux benchmark
Date: 1999/06/08
Message-ID: <fa.fhkl26v.1p5iarq@ifi.uio.no>#1/1
X-Deja-AN: 486934342
Original-Date: Tue, 08 Jun 1999 04:29:01 +0000
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <375C9C0D.650EB892@netplus.net>
References: <fa.fv2crov.n00gor@ifi.uio.no>
To: "linux-ker...@vger.rutgers.edu" <linux-ker...@vger.rutgers.edu>
Original-References: <E10r46H-0006Rw...@the-village.bc.nu>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

Alan Cox wrote:

> Of course nobody has addressed the problem that Apache is optimised for
> the real world not benchmarks and that its not the right server to use
> for a benching exercise with the rather poor benchmark tools used today.

There was an earlier thread that touched on Apache optimizations but was
inconclusive on one point.  Is it or is it not possible to get around
the thundering herd problem with multiple NIC's and Apache?  Isn't that
Apache's main problem in this benchmark?

Apache is as much of an OSS poster child as Linux is.  Using something
else like Zeus might win the battle but would lose the war.  What is
really frustrating here is that while the netbench results have some
reasonable real world interpretation, the webbench results are truly
meaningless in today's world.  It almost seems like a diversionary
tactic to take people's time away from making apache better, by forcing
them to work on getting better numbers in a meaningless test.  Does
anyone know of a Quad Xeon server anywhere with 4 100mb/s NIC's being
pounded by 250+ clients throwing everything they've got at it?

-Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: Preparations for ZD's upcoming Apache/Linux benchmark
Date: 1999/06/08
Message-ID: <fa.it1t66v.cicdhi@ifi.uio.no>#1/1
X-Deja-AN: 486945112
Original-Date: 8 Jun 1999 05:11:24 GMT
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <7ji8ls$gmk$1@palladium.transmeta.com>
References: <fa.fhkl26v.1p5iarq@ifi.uio.no>
To: linux-ker...@vger.rutgers.edu
Original-References: <E10r46H-0006Rw...@the-village.bc.nu> 
<375C9C0D.650EB...@netplus.net>
X-Authentication-Warning: palladium.transmeta.com: 
bin set sender to n...@transmeta.com using -f
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Transmeta Corporation, Santa Clara, CA
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

In article <375C9C0D.650EB...@netplus.net>,
Steve Bergman  <st...@netplus.net> wrote:
>
>There was an earlier thread that touched on Apache optimizations but was
>inconclusive on one point.  Is it or is it not possible to get around
>the thundering herd problem with multiple NIC's and Apache?  Isn't that
>Apache's main problem in this benchmark?

Apache's main problem is more likely to just be the fact that it isn't
meant to be a speed deamon.  The design was for other goals.  The apache
team seems to be working on performance, but the _big_ advantage in
using Apache tends to be flexibility rather than raw performance on some
not-very-real-world benchmarks. 

The thundering herd thing shoul dbe fixed by just having the listen
socket listen to SOCKADDR_ANY - which I _think_ is what apache does by
default, but I have to admit to not having looked at the code in
basically forever. 

The other option, of course, is to run two copies of apache with
different listening socket addresses.

>Apache is as much of an OSS poster child as Linux is.  Using something
>else like Zeus might win the battle but would lose the war.

Besides, it's not really what MS was interested in showcasing, and is
not really what most peoples choice would be about anyway.  So I think
we may want to make sure Zeus or similar numbers are available to
people, but also to some degree educate them on what the strengths of
Apache are. 

And I'm very interested in people doing kernel modules for static
content serving with fall-backs to Apache etc.  That is, to a large
degree, what NT seems to be doing, with IIS-only magic system calls etc.
And we can do it so much more cleanly.

>						  What is
>really frustrating here is that while the netbench results have some
>reasonable real world interpretation

Not really.  I agree that the _hardware_ setup in netbench is more
realistic (ie the network setup is at least something that in theory
could be used at a real site), the actual netbench benchmark seems to be
very unrealistic indeed.  It's just creating lots of large temporary
files without doing much else, which at least to me sounds very
contrieved. 

>			, the webbench results are truly
>meaningless in today's world.  It almost seems like a diversionary
>tactic to take people's time away from making apache better, by forcing
>them to work on getting better numbers in a meaningless test.

Agreed. 

However, the things is that web performance obviously _is_ important to
a lot of people, and it's really hard to benchmark slow connections and
lossy networks etc which is what most real-life uses are.  So webbench
is kind of a "default choice" - it's a bad benchmark of real-life
behaviour, but there isn't anything else out there. 

So it's understandable.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: Richard Gooch <rgo...@atnf.csiro.au>
Subject: Re: Preparations for ZD's upcoming Apache/Linux benchmark
Date: 1999/06/08
Message-ID: <fa.i19bb4v.i4q52r@ifi.uio.no>#1/1
X-Deja-AN: 486949388
Original-Date: Tue, 8 Jun 1999 15:23:58 +1000
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-Id: <199906080523.PAA00875@vindaloo.atnf.CSIRO.AU>
References: <fa.it1t66v.cicdhi@ifi.uio.no>
To: torva...@transmeta.com (Linus Torvalds)
Original-References: <E10r46H-0006Rw...@the-village.bc.nu> 
<375C9C0D.650EB...@netplus.net> <7ji8ls$gm...@palladium.transmeta.com>
Notfrom: spam...@atnf.csiro.au
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

Linus Torvalds writes:
> And I'm very interested in people doing kernel modules for static
> content serving with fall-backs to Apache etc.  That is, to a large
> degree, what NT seems to be doing, with IIS-only magic system calls
> etc.  And we can do it so much more cleanly.

Does that mean you'd accept a patch which did this?

What about the arguments that this would be increased kernel bloat/do
it in user space, etc?

				Regards,

					Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: Linus Torvalds <torva...@transmeta.com>
Subject: Re: Preparations for ZD's upcoming Apache/Linux benchmark
Date: 1999/06/08
Message-ID: <fa.nf596ev.1k7mkgp@ifi.uio.no>#1/1
X-Deja-AN: 487151510
Original-Date: Tue, 8 Jun 1999 10:07:01 -0700 (PDT)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.3.95.990608100106.10204A-100000@penguin.transmeta.com>
References: <fa.i19bb4v.i4q52r@ifi.uio.no>
To: Richard Gooch <rgo...@atnf.csiro.au>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu



On Tue, 8 Jun 1999, Richard Gooch wrote:
>
> Linus Torvalds writes:
> > And I'm very interested in people doing kernel modules for static
> > content serving with fall-backs to Apache etc.  That is, to a large
> > degree, what NT seems to be doing, with IIS-only magic system calls
> > etc.  And we can do it so much more cleanly.
> 
> Does that mean you'd accept a patch which did this?

I've already taken a quick look at the khttpd that Arjan van de Ven did,
and it looked very interesting. The regular kernel part of it was simply a
matter of exporting the existing "do_generic_read()" functionality,
something that I have no problem with at all (it's something that others
are looking into for the kernel NFS deamon anyway - so it's not as if this
would be a special case, even). 

> What about the arguments that this would be increased kernel bloat/do
> it in user space, etc?

I certainly feel that it should be just a kernel module, with all the hard
cases punted down to user space - doing just the static content in kernel.
The down-punting is the "hard" case, and through a quick look even that
doesn't actually look that bad.

For example, to me it looks like it would be trivial to punt it down to
user space by having the kernel module do only "peek"  operations on the
data list, and if it encounters a request it can't handle, it just pushes
the socket onto a accept-queue - so the user space side would just accept
the socket as if it came to it directly.  So you could even use a pretty
much unmodified apache (or other) web server to do all the non-static
cases - although it would probably imply that the user-level deamon would
be better off being optimized for the "uncommon" case because it never
sees the common case. 

So yes, I think this is a really solid approach. I can't guarantee that it
works, but the initial kernel httpd by Arjan is _very_ small, making me
rather optimistic that it's a good idea..

		Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/