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/