🚀 go-pugleaf

In article <9951@spool.cs.wisc.edu> shekita@provolone.cs.wisc.edu (E Shekita) writes:
>
>On a related tangent... Supposedly Sequents make pretty good machines for 
>doing transaction processing. (In fact, I heard that 80% of their sales
>are for transaction processing.) But I wonder how many processors it
>takes to saturate their bus in such an environment. Probably not many 
>because the cache hit ratio for data and instructions is going to be very 
>low in a transaction processing system -- there's almost no locality at all.

Wellll sort of.  I am quite familar with the performance of both Informix and
Oracle on Sequent systems (yes they do sell a lot of OLTP systems) as measured
by the debit/credit benchmark (i.e. perhaps having nothing to do with "real"
performance).  Generally the systems are I/O limited, add more disks and it
goes faster.  You usually see little bus contention, but that can be
misleading.  Most benchmarks now are run with what Sequent calls "processor
affinity", which binds a set of processes (usually front and backends) to
a particular cpu.  One might think (as I did) that this would be bad, since
there is a good chance that a process that is ready to run won't even though
another cpu might be idle.  However just the oppisite is the case.  Processor
afinity offers 10-20% (if I remember correctly) greater overall performance,
even though there IS 20% more cpu idle time.  Looking at the bus one finds
that there is a much higher percentage of "useful" bus activity due to a
higher hit ratios (of code or data we don't know).  It is apperently worth
waiting for "your" cpu due to the increased likelyhood that your stuff will
still be cached.  Typically in these cases there are only 2 code segmetns
active (the front end and the back end), a very large shared data space
between backends and a significant private data space for both.

So the lesson (I guesss) is that the question asked "How many processors does
it take (in a DBMS env) to saturate the Sequent bus" is likely to simplistic
a model.  The bus typicall does not get satureated, yet improvements in cache
hit rates still make a significant difference in system performance (again
measured by debit/credit, now being obsoleted by the new TP1 standard being
developed).
	-jrg
-- 
internet   jrg@apple.com      John R. Galloway, Jr.
applelink  d3413              CEO..receptionist
human     (408) 259-2490      Galloway Research

These are my views, NOT Apple's, I am a GUEST here, not an employee!!