Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Nov 1998 22:15:23 -0800 (PST)
From:      Marc Slemko <marcs@znep.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
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
Message-ID:  <Pine.BSF.4.03.9811052158470.11835-100000@alive.znep.com>
In-Reply-To: <199811060415.UAA00826@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.03.9811052158470.11835-100000>