Stupid question, but it's Saturday and I'm on a Windows system (don't ask...).
What do people think about something like SPECWeb99 - dynamic content, CGIs,
etc? I know the biggest complaint about 96 is that it's completely static
content which a completely tweaked setup will keep completely in memory, among
other "optimisations" I've heard of.
If not SPECweb, then is there another benchmark that you can all agree with?
Preferably something that can be used to show scalability of an operating system
and hardware combination - not only in terms of CPUs and memory, but also number
of users/requests/transactions/whatever. I am also interested (not that many
people are) in what happens when the system is pushed over the edge - again,
something like the House web server when the Lewinsky paper was released. It's
important for people to know that their system will continue to run and hopefully
well even when it's completely overrun. Ideas?
- Pete
"David S. Miller" wrote:
> Date: Fri, 21 Jan 2000 23:18:51 +0000 (GMT)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>
> > When I run SPECWeb96 tests here, I see both a large number of running
> > process and a huge number of context switches.
>
> Running 2.2.x I imagine as well, right?
>
> Specweb96 is about as relevant to real world web performance as the colour
> of car you own. And in this case massively so. Run your test with thttpd.
> Your run queue length will be _one_. Always one, never more and under load
> never less. Its an architectural issue in your web server.
>
> Only partly true Alan, only 2.3.x has the "dumb wakeups" issue with
> TCP accept fixed (2.2.x will cause ~3 wakeups for each new connection
> when only 1 should be made). That plays a big factor as well,
> remember the same exact thread about all of this "run queue
> scalability" bogosity we had nearly a year ago?
>
> So to the original specweb96 tester, divide your context switch number
> by 3, does it look more sane now? :-)
>
> However Alan is right, web server architecture has a lot to do with
> bad "benchmark" performance.
>
> Later,
> David S. Miller
> davem@redhat.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:27 EST