Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

The level of scalability

If an application has outgrown particular class of servers it is important to have the capability to move it to the next class without changing OS or hardware vendor.  It should not lead to the proliferation of Unix flavors for the reasons mentioned above. 

The ability to access huge amount of RAM (say 64G or more) is often as important in large enterprise environments as raw speed of CPU or number of CPU or  transactional benchmarks.  One of the attractive feature of SUN servers is that they typically configured with more memory then competitors even if hardware capabilities are the same.  And servers based on architectures that are unable to support large amount of RAM (all old X86 servers) typically perform slower on large enterprise applications (like databases, SAP/R3, Tivoli, etc)  then "large RAM friendly" architectures.

Solaris 10 6/06 includes the new ZFS file system. Among the most interesting features of ZFS that increase scalability are:

• Integration of file system and volume manager into a single subsystem with a single management syntax
  
• 64-bit checksums for increased data integrity
  
• Copy-on-write to minimize recovery times after failures
• 128-bit addressing
  

ZFS definitely belongs to the new generation of file systems, and as such is preferable to old good UFS. It's too early to judge it as we need at least a year for the dust settled, but if successful, it will give Sun a high-performance journalled  file system with addressing capabilities beyond available in linux. 

Another feature of Solaris that increases scalability is Dtrace.  In his May 15, 2007  Intel blog entry Why Linux people lust after DTrace David Stewart noted:

Back in 2002, I was managing the team that worked with Oracle on the engineering side.  This was when they were transitioning from developing the database on Solaris to Linux, and we were helping them with this transition.  Of the various requests their devs made, one of the first was “when can we get DTrace on Linux?” 

I was a bit confused, since I had never heard of DTrace! 

Fast forward to 2007, and I sat listening to Bryan Cantrill, the inventor of DTrace show some examples of the power of this little tool which comes with Solaris. 

> The kernel has been instrumented with probes which cause no impact if they are not activated, but which allow the DTrace command to program them to fire.

> The command can be used to count probe firings as events and display these counts as histograms for example.

> Besides the kernel, one of the speakers I heard had instrumented the javascript runtime engine to enable DTrace usage, so you can identify where your time is going in a web site.

> It has absolutely no GUI.  Someone experienced in the art can simply write DTrace scripts on the fly and get amazing results. 

The recent example they used was Twitter.  Remember my recent comments about this new micro-blogging application?  Well it turns out that the gang at Twitter implemented their system using Ruby on Rails, the new and sexy rapid website programming system.  After the article in the New York Times, Twitter has grown in popularity to be the biggest application of Ruby on Rails.  And of course, they were having performance problems. 

Fortunately for Twitter, they implemented it on Solaris, and thus DTrace to the rescue.  Within a few hours, they had identified an issue with how often deep stack back traces were being taken, they get a fix from the Ruby guys and had a 30% performance boost.  Pretty snaz, yeah? 

No wonder I saw DTrace listed as one of the top 10 reasons Solaris is better than Linux.

Created Jan 2, 2005.  Last modified: February 28, 2008