From owner-cvs-all Thu Nov 5 22:19:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA22088 for cvs-all-outgoing; Thu, 5 Nov 1998 22:19:40 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA22082 for ; Thu, 5 Nov 1998 22:19:38 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.9.1a/8.9.1) with UUCP id XAA29591; Thu, 5 Nov 1998 23:19:27 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with ESMTP id WAA20825; Thu, 5 Nov 1998 22:15:23 -0800 (PST) Date: Thu, 5 Nov 1998 22:15:23 -0800 (PST) From: Marc Slemko To: Matthew Dillon cc: cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf options param.c src/sys/kern init_sysent.c syscalls.c syscalls.master uipc_syscalls.c src/sys/sys mbuf.h socket.h socketvar.h syscall-hide.h syscall.h syscall.mk sysproto.h src/sys/vm vm_object.c In-Reply-To: <199811060415.UAA00826@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Thu, 5 Nov 1998, Matthew Dillon wrote: > > :When I have access to a system I also plan to implement it in Apache to > :see what sort of difference it makes. > : > :While the ideal implementation won't be until Apache 2.0, it will be > :interesting to see just what impact this has with the current Apache. > > I'm sure it will make a huge difference in the benchmarks, but I doubt > you would notice much of a difference in real-life performance except > in the most extreme installations. Cpu's are cheap, physical I/O limits > are usually more important because its the first thing web servers tend > to hit. That isn't always entirely true. But yes, in this case, it is almost entirely for benchmark numbers. However, when you reach the high end, CPU can become an issue, especially on FreeBSD where you can't just pop in another CPU and get a decent improvement. At the high end, storage and networks can scale a long way (until you run into your bus limitations); those things really scale better than CPUs in many ways. It doesn't matter if you can afford 100 CPUs for a box if you can't plug them in anywhere. sendfile() certainly helped wcarchive, which is a good example of this. Zero copy technology helped IBM push numbers on their quad CPU system until they actually ran out of bandwidth on the bus with a fair amount of free CPU. Although it is true that, porn^H^H^H^Hspecweb96 is an amazingly accurate benchmark for porn sites, with the exception that instead of a small number of fast clients, porn sites have a large number of slow clients. Both the content type (ie. nearly all static content) and file size distribution are quite similar between the two. With Apache, being efficient CPUwise can be a bit more important becuase you lose some CPU to context switching. Benchmark numbers are still fun though, and can be very important to a product because being able to serve 2000 hits/sec somehow shows someone who only needs to serve 2000 hits/day that a product is viable. Should it? Naw. Does it? Sure. It would be useful to get a FreeBSD+Apache number into the specweb database, just to show it is in the same order of magnitude. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message