Thursday, 12 March 2009

TPC-C - The Benchmarketing Hall of Fame/Shame

Benchmarking and vendor benchmarking specifically is a dirty word in IT - only the naive take the benchmarks at face value and more wise will know that if you want to know the performance levels of the proposed configuration, you have to do it yourself exactly with the configuration you're planning to put in production. Otherwise you'll be committing yourself to a purchase strictly based on the ability of vendor X to muscle and beat a certain benchmark into submission by most likely throwing unrealistic amounts of hardware at the problem and doing some very questionable tuning. I do not want to pick on IBM as if it is the only vendor doing this sort of activity as many companies engage in "creative benchmarking", but IBM in my opinion has perfected this art. IBM always treated TPC-C benchmark as its oyster almost perfecting the art of squeezing the good benchmark results, not so much curtesy of the stellar performance of IBM products, but rather deep pocketed ability to throw ungodly amounts of resources to get the top benchmark. Now, TPC-C in itself has long been questioned as a good benchmark, with many experts stating that does not really reflect the real world workload (even IBM nodded in agreement) and most smarter observers are now paying more attention to TPC-H instead as being more realistic, but that is besides the point. I recently had a good laugh looking the #1 TPC-C benchmark result not surprisingly being held by IBM p595:

http://www.tpc.org/tpcc/results/tpcc_perf_results.asp

On the surface it is all looking nice with IBM scoring amazing 6,085,166 tpmC while costing very respectable 2.81 USD/tpmC, but if you even scratch the surface by looking at the disclosure reports revealing the internals of this setup, you are set to be amazed by the sheer absurdity of this configuration:

http://www.tpc.org/results/individual_results/IBM/IBM_595_20080610_ES.pdf
http://www.tpc.org/results/FDR/TPCC/IBM_595_20080610_fdr.pdf

First number that should immediately jump at you is the rather enormous cost of this config - mind boggling 17 million dollars! And that is after 20 million dollar IBM discount!!! The storage subsystem configuration is especially ridiculous in its unbounded hugeness - IBM employs 746TB of storage for this setup using a grand total of 11,000 disks! And it is not that IBM needs even a half of the 746TB for the database storage requirements, only one fifth of that amount is actually needed - 171TB to be exact. In other words is striping the hell out of the available storage to squeeze every iota of all physically possible storage performance irrespective of how unrealistic it is to the real world - I can tell you for sure that no one in the real world will sacrifice that much capacity over performance improvement - the setup is totally and utterly unrealistic. If you're really planning to use this IBM benchmark as a foundation for an education decision on the real world performance of a potential configuration, well you need to use more common sense to put it mildly.

And again I'm not just picking on IBM specifically, TPC-C benchmark is a hall of fame for "benchmarketing" by other well known captains of industry with HP, Fujitsu and NEC being in the top 10 and challenging IBM with their equally ridiculously out-of-this-world configurations that have very little application to the real world configurations and workloads. If there is one message you would like to take out of all this, it is that do your own benchmarking with configuration and the workloads you're actually planning to use and do not rely on the benchmarketing pushed by the vendors to create illusions of the world beating performance. As your parents probably would have said "use your own head".

Dilbert.com

Sunday, 8 March 2009

Solaris vs. Linux in the Data Center - Maturity vs. Gloss

If you've been around the Unix discussion groups, most likely you have run into countless arguments on the merits of Solaris vs. Linux and which one is better for a particular task or which one is technically superior. The scenario is quite typical where Solaris proponents claim superiority on the technical grounds while referring to Dtrace/ZFS and Linux fans claim that Linux is more ubiquitous, more polished and easier to use. I would agree with both sides - Solaris is an undisputed winner on the technical grounds with more advanced technology packed into it and Linux more of a consumer friendly type. If we go to the world of car analogies, I would liken Linux to a small pickup truck that has a nice stereo and a pretty paint job, Solaris on the other hand is more like giant Caterpillar earth moving truck - it doesn't have the prettiest paint job in the world and it may not have the stereo, but it is brutally efficient at what it was designed to do - moving dirt, moving lots of it and doing it in the most efficient manner. Predictably Linux fans quip that Dtrace, ZFS, high scalability, etc. of Solaris is something they can live without by compromising on old-school LVM/RAID, SystemTrap (poor mans imitation of Dtrace) and scaling horizontally on small PC-type servers. Its all good and true, but compromise is a compromise and all it is saying is that Linux is still second best technically - the level of technology is still on there on the same level with Solaris. But even if you ask me if I would choose Solaris over Linux even when we pretend that ZFS and Dtrace don't exist, I will still say that Solaris is better fit as a serious data center type OS - Solaris still has better tool chains for managing your systems on the daily basis. Solaris LiveUpgrade is a prime example of that - this feature alone would steer me to Solaris and no amount of Linux prettiness would compensate for it. If you're not familiar with Solaris LiveUpgrade - it is essentially a mean of easily creating and maintaining multiple boot environments under Solaris, which while sounding rather simplistic permits tremendous savings in terms of downtime when performing upgrades and patching. Which in essence all OS upgrades regardless how significant and lengthy can be reduced just to the time it requires to reboot the machine - you just create an alternate boot environment which is an identical copy of your current OS and then patch it or upgrade it while the system is running like nothing special is going on! Then you activate the new boot environment and reboot. You system comes up and voilĂ  - you're running an upgraded/patched OS! The only disruption you would see is a reboot. No huge change windows required to prepare the system for a potentially risky change and no taking the system out of service to install countless patches and updates that take what seems like forever. And the best part is you can easily return to the previous pre-patch/pre-upgrade state, again with a simple reboot. Needless to say that LiveUpgrade adds a lot to my peace of mind when going through upgrades with Solaris, which is something I can't say about Linux where all you have is much less prettier option of rolling back to a mirror that must be split off before the patching/upgrade. So as I said, even forgetting the latest wizbang technology of Solaris 10 and OpenSolaris, all the Linux gloss is just not enough to overcome the industrial strength features of Solaris that made it the OS of choice in the Unix data center.