> A good friend of mine used to say that many performance problems > really are expectation problems. > > The strengths of zSeries are not in single-engine clock speed but in > massive throughput. It is not trivial to design a benchmark that > demonstrates it. Instead of doing end-to-end benchmarks I prefer to > look at instrumentation and explain why you see some behaviour. That > will help understand how to remove that bottleneck and get single-task > throughput to the level that works for you.
Realize that RELIABLE single-thread performance is a key strength of a mainframe. When a job can be subdivided to allow a lot of parallel processes then you have a choice and can look at a Beowulf cluster-- but the workloads suitable for such subdivision are, to my limited knowledge, not common. Some jobs (like balancing a B-Tree or performing the Merge phase of a sort) are inherently single thread and are NOT things you want to take a chance of doing wrong. These can't really be subdivided, after all, and are the workloads that separate the mainframes from the wannabes. Throw in some CPU faults and the mainframe comes out ahead, doesn't it? The other strengths of a mainframe-- being I/O connectivity and bandwidth (which, come to think of it, qualifies as "scalability") have been impacted (IMHO, though I've no personal experience but wish I did) by the growth of SAN and NAS appliances. > One of the strong points is virtualization and the hardware support to > allow for fast and frequent context switches. Quite often the real > test is to see how many other things you can do at the same time > without slowing down things. Obviously you're missing most of the > virtualization capabilities when you run Linux on zSeries without > z/VM. One of the things you miss is the instrumentation. I was told some time ago that you don't want to migrate a heavy CPU user to a z/VM instance... though, I suspect, an I/O bound environment would be just peachy. IOW, I suspect that having a bunch of instances running [EMAIL PROTECTED] would not be any better than having a single instance running it. That being said, some things are best benchmarked in battle; Tank testing of a 12-meter racing sailboat only goes so far before you just have to build the real thing and try it out... and haul along a bunch of craftsmen to fine-tune the boat. Workloads vary, so the best answer is to test them to see if they can fit... and vice versa. If everyone could buy and fit a suit off the rack there'd be no need for tailors. (sighs) All right, I got my weekly need to act as a Stand-Up Philosopher out of my system. Sorry it was here, folks. -------------------- John R. Campbell, Speaker to Machines (GNUrd) (813) 356-5322 (t/l 697) Adsumo ergo raptus sum MacOS X: Because making Unix user-friendly was easier than debugging Windows. Red Hat Certified Engineer (#803004680310286) ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
