Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: Microsoft destroys TPC-C records!

Re: Microsoft destroys TPC-C records!

From: <jahorsch_at_my-deja.com>
Date: Wed, 23 Feb 2000 17:39:31 GMT
Message-ID: <89160i$4em$1@nnrp1.deja.com>

> Explain that to Sequent. They been doing it since the i386 days.
> With the old Dynix series. They now do it with the latest Intel stuff
> and been doing it in-between too, so it wasn't a one off. I
> personally worked on a 24 CPU box back in 1989, running benchmarks. On
> UNIX, of course. And ORACLE. And it scaled very well, thank you.

Back in the old days there wasn’t as much of a lag to hit memory. Now with the multipliers reaching 6x and 7x waiting for the bus really slows you down. Right now the biggest design problem is in the bus design. Sure I am starting to talk over my head and I have never used a machine over 8 processors. I try and follow hardware and keep a close eye on published TPC-C benchmarks. I think I am right in saying that using a switched bus between multiple 2 or 4 ways is the way the industry is going to not make that the bottleneck. Sure you can slap 32 - 64 processors at something but unless they can do work what good is it. At what point does scalability fall flat. Graph throughput over processors and see what happens. I do not know much about Sequent but I imagine their bus must have something to make it fly as well. That is proprietary while the profusion is available from many vendors.

> So did I. Try to look at most of the TPC-n benchmarks that ORACLE
> has published over the last 10 years. They have mostly been on x86
> boxes with oodles of CPUs, running UNIX.

The top sequent score was 93,900 for 64 405Mhz processors on Oracle 8 for over $12 million. 8 processors with SQL 2000/ Windows 2000 at a slightly higher clock and multiplier give over 48K at 550Mhz for less than $1 million. I think that 32 processors with a better bus could kill that number. That number indicates to me either Oracle does not scale well , TPC-C is a bad benchmark ,or that Sequent has a bottleneck in their bus. I think the last one is the correct answer.

> Beg to disagree. It DOES scale well. Maybe not with NT or MS s/w,
> but it DEFINITELY scales well with UNIX, and has done so for the
> last umpteen years. Don't believe everything that Intel/MS put out
> to explain NT's and SServer's failure to scale well on Intel or
> Linux's "shortcomings".

Define scales well? What is throughput for 4 processors ? 8? 16? 32? 64? I bet after 16 the line ramps up rather slowly. You obvious hate MS in a big way. I am just trying to state that SQL Server and NT are not a bad solution. I am trying to influence people that make decision in the world to not just consider Informix or Oracle because SQL Server/NT cannot scale or is not reliable enough. People out there do not even think about SQL Server for a solution when it would be a great candidate. Have you not ever had to call for Oracle support through their fun Tar process and get some moron on the other end that doesn’t know their head from their *ss? I have encountered many Oracle bugs in the engine and especially in their tools. I have seen Informix and Oracle go down in a blaze of glory. Nothing is perfect and defining a stable environment has everything to do with proper procedure and architecture.

> You got it all wrong. It's not the hardware platform that is limited.
> It's NT. A fact well recognized by MS many times. You are just not
> listening. Or have you forgotten that with NT V3 MS admitted quite
> clearly that it didn't scale AT ALL on x86? Hence the release of NT 4.
> At that time, UNIX/ORACLE was scaling quite well on just about
&#61656; anything, including x86.

As I said before NT is still not as mature as UNIX and has a way sto go. I still think that you cannot rule SQL Server out of an Enterprise solution. 2000 scales quite well with the proper chipsets.

> Here I disagree again. If implemented PROPERLY, NT costs
> about the same as any other UNIX solution. The problem
> is that nowadays any kid straight out of his mother's milk claims
> to be an implementer, boots the system and makes it "whirr"
&#61656; and managers go "wow!" and call him a genius and claim all sorts of
> TCO savings. Then the consultants come in to fix the crap that was
> "implemented". But of course that is not added up to TCO. Installing
> an OS is NOT the same as implementing a solution, I'm afraid...

I think MS is cheaper in OS and DBMS. If you already have an Enterprise agreement with MS then SQL Server is practically free. I agree that proper implementation is a big issue. I have seen the good the bad and the ugly as has anyone who has been in the industry for 5+ years. If the playing field is level as far as architects/ dbas/ and developers go and a methodology that removes "dynamic" requirements I think MS is hard to beat. Even if you choose a 2 tier architecture with say PB as the front end you will still save money due to less DBA work, Cheaper OS/DBMS, Cheaper hardware, and less sysadmin work.

> So, the TCO for implementing a solution that requires SPECIFIC
> application coding for distributed DCOM is cheaper? How is that
> achieved? By adding the price of the licences for SS and NT? So easy,
> isn't it? Who pays the fellas who WROTE the EXTRA custom code to
> make the darn thing work? Was their cost added too?

Did I say N-Tier? Everything comes with a cost. If you use Tuxedo/Corba/DCOM they all have their issues. Just make the playing field level and it still will be cheaper.

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Wed Feb 23 2000 - 11:39:31 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US