[bordering on OT] Re: Linux Hello World Benchmarks: +PHP,JSP,ePerl

[Blue Lang <bl...@gator.net>]

On Thu, 4 Jan 2001, Roger Espel Llima wrote:

> JR Mayberry <jr...@e-vend.net> wrote:
> > Linux does serious injustice to mod_perl. Anyone who uses Linux knows
> > how horrible it is on SMP, I think some tests showed it uses as litle as
> > 25% of the second processor..
>
> A simple benchmark with 'ab' shows the number of requests per second
> almost double when the concurrency is increased from 1 to 2.  With a
> concurrency of 4, the number of requests per second increases to
> about 3.2 times the original, which is not bad at all considering
> that these are dynamic requests with DB queries.

Eh, ab isn't really made as anything other than the most coarsely-grained
of benchmarks. Concurrency testing is useless because it will measure the
ratio of requests/second/processor, not the scalability of requests from
single to multiple processors.

IOW, you would see almost exactly that same increase in req/second on a
single processor, most likely, unless you have a really slow machine.
You'd have to tune your load to give you one req/second/processor and then
go from there for it to mean anything.

Of course the original poster's statement on linux using only 25% of a
second CPU is a fuddy and false generalization, but that's a different
story. :P

-- 
   Blue Lang, Unix Voodoo Priest
   202 Ashe Ave, Apt 3, Raleigh, NC.                          919 835 1540
	"I was born in a city of sharks and sailors!" - June of 44

Re: [bordering on OT] Re: Linux Hello World Benchmarks: +PHP,JSP,ePerl

[Roger Espel Llima <es...@iagora.net>]

On Thu, Jan 04, 2001 at 09:55:39AM -0500, Blue Lang wrote:
> Eh, ab isn't really made as anything other than the most coarsely-grained
> of benchmarks. Concurrency testing is useless because it will measure the
> ratio of requests/second/processor, not the scalability of requests from
> single to multiple processors.

Yeah, I agree 'ab' is a pretty coarse benchmark.  However, it does
in a way measure how much the various processors are helping,
because running ab with -c 1 should pretty much ensure that apache
only uses one processor at a time (except for a slight overlap while
one process does the logging and another could be reading the next
request from another processor), and similarily -c 2 should let
apache use 2 processors at one given time.  All approximately, of
course.

Anyway, on that 4way server it works that way; the requests per
second increase quickly with the concurrency up to 4, but don't
increase anymore after that.  That is serving relatively slow
dynamic pages; with static content I'd expect more rapidly
diminishing returns.

-- 
Roger Espel Llima, espel@iagora.net
http://www.iagora.com/~espel/index.html

Re: Single proc ->multi proc

[Joshua Chamas <jo...@chamas.com>]

modperl@mail.thefriend.com wrote:
> 
> I've got 4 new machines coming in around the 22nd.  I'll have physical
> access to them for two weeks before we colo them.  Probably the easiest
> way to determine mod_perl's scalability by going to multiproc on linux
> would be for me to test them.  They are dual proc machines, but I can pull
> a proc out of them for testing pretty easily durring the two weeks that we
> have them here.
> Thoughts?
> recomended scripts?
> methods?

You should check out the bench.pl I just posted that runs 
a series of benchmarks for you.  Its at:

  http://www.chamas.com/bench/hello.tar.gz

Its takes the drudgery out of benchmarking.  Run ./bench.pl -h
for online help.

--Josh

_________________________________________________________________
Joshua Chamas			        Chamas Enterprises Inc.
NodeWorks >> free web link monitoring	Huntington Beach, CA  USA 
http://www.nodeworks.com                1-714-625-4051

Single proc ->multi proc

[mo...@mail.thefriend.com]

I've got 4 new machines coming in around the 22nd.  I'll have physical
access to them for two weeks before we colo them.  Probably the easiest
way to determine mod_perl's scalability by going to multiproc on linux
would be for me to test them.  They are dual proc machines, but I can pull
a proc out of them for testing pretty easily durring the two weeks that we
have them here.
Thoughts?
recomended scripts?
methods?
As for ab being coarse,  I'm not sure I'd agree totaly with that.  It
allows a fairly good amount of control.  There is also once called
sslclient that is actually worse except it does ssl.
Scott

On Thu, 4 Jan 2001, Blue Lang wrote:
> On Thu, 4 Jan 2001, Roger Espel Llima wrote:
> > JR Mayberry <jr...@e-vend.net> wrote:
> > > Linux does serious injustice to mod_perl. Anyone who uses Linux knows
> > > how horrible it is on SMP, I think some tests showed it uses as litle as
> > > 25% of the second processor..
> > A simple benchmark with 'ab' shows the number of requests per second
> > almost double when the concurrency is increased from 1 to 2.  With a
> > concurrency of 4, the number of requests per second increases to
> > about 3.2 times the original, which is not bad at all considering
> > that these are dynamic requests with DB queries.
> Eh, ab isn't really made as anything other than the most coarsely-grained
> of benchmarks. Concurrency testing is useless because it will measure the
> ratio of requests/second/processor, not the scalability of requests from
> single to multiple processors.