Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-users@xml.apache.org
Date: Wed, 24 Oct 2001 08:34:03 +1000
Subject: Re: Fastest Platform (softwarewise)?
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v472)
From: Phil Blake <phil@tcp.net.au>
To: cocoon-users@xml.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3BD56DE4.9A42D60E@apache.org>
Message-Id: <0FE89078-C806-11D5-A49E-003065A85E10@tcp.net.au>

>> Bang for buck, a G4 running OSX wins hands down. However, believe it or
>> not, the dual PIII comes in second (AIX don't come close... too
>> expensive for real consideration and Windows is not a server operating
>> system in practice, only in marketing).
>
> That's interesting, I didn't think OSX would come out on top--maybe 
> second
> though.  As to AIX, and this goes for Solaris as well, they are very
> expensive--so bang for the buck goes down.  How about raw performance
> though?  Which comes out on top?

OSX does just over AIX (but this is not really fair as OSX is running on 
a year old G4 whereas AIX is on a 10 year old J50). The J50 is mainly 
our database machine and it's far better at that than web serving.

>
>> The Dual PIII was about 10% more than the G4 (after adding SCSI) and
>> about 70-80% the performance.
>
> So for 10% more cost you gain 70-80% more speed.  That is a reasonable
> tradeoff.  What kinds of tests did you run?  How does each one scale
> (as you add more clients).  How many simultaneous connections can each
> platform handle before you reach saturation?

A series of load tests showed the PIII delivered between 70-80% of the 
total requests delivered from OSX in the same time.

There are a couple of sites served by the test machines, static and 
dynamic with connections to an Object database and a SQL database. The 
tests were 'typical usage' tests with a script making requests for 
documents in a similar way the people using the site only much faster. :)

They included database searches, updates and deletes so that time was 
considered separately.

The script allows us to 'simulate' the number of users and our testing 
was with 50 concurrent users. I've found that 50 concurrent/simultaneous 
users equates to about 150-200 real users - which is well above what we 
are expecting.

>> Although theory has it that a G4 500MHz has about the same performance
>> as a PIII 1.5GHz (ie triple the performance), I've found that it's
>> really more like double the performance, not triple.
>
> Careful there.  Clockrate != performance.  When all things are equal
> (i.e. chip architecture, design, etc.), then clockrate is effective
> to determine relative performance increases.  However, the G4 and the
> PIII have very different architectures.  This is true of the PIII and
> the P4, and the P4 and the K7.  In that case 1.5GHz in all three
> processors would have very different performance results.  As far as
> I know, the G4 is not capable of the high clockrates, so it makes up
> for it with an efficient pipeline.  The pentium series was designed
> for high clockrates.

Yeah, absolutely. Clock speed certainly has nothing to do with 
performance. I learnt that very quickly with an RS6000 - the 
architecture is so bloody good that it manages to get a heap more done 
than a Mac (same processor, memory, disc, etc). Certainly chip 
architecture, and even more importantly machine architecture, plays the 
biggest role in getting the job done. Lastly, software design can suck 
out any performance that the hardware can give you.

Run linux on a top model GenericPC or a top model Netfinity. All things 
being equal (cpu, memory, dics, etc) the Netfinity will outperform the 
Generic. Why? It's been built well. But run windows on them both... no 
perceivable difference. Why? Poorly written software will turn even the 
best hardware into a dog.

Regardless, it looks like I missed the point of the question in the 
first place, so I think i'll leave it here. :)

Thanks. Have fun,

Phil


---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>