Packages to install for this article:
Linux: apt-get install bonnie ++
FreeBSD: available in ports
OSX: available via MacPorts and pkgsrc

After looking in our first part of how we can measure the CPU performance of a workstation, we turn now to input/output performance, which is probably one of the most under stated performance factor for any kind of workload.
We will show it through a small user story which happened here in our team.

Some weeks ago, one of the developers, Walid, noticed to the team that while compiling his computer became unresponsive, to the point that even moving moving the mouse showed a visible latency. We have a build server for continuous integration, but as each developer compiles the project three times a day ( each during 11 minute) , it generates quite an amount of fencing. After having a look at the Gnome System Monitor applet, it seemed that the unresponsiveness peaked mostly while the workstation was starving for I/O. Typically this can happen during the linking phase of the build process, when the  linker brings all the compiled classes into a jar file.

Here grey indicates I/O waits, and blue CPU activity.

So we decided to bit the bullet and install a 120 GB Solid State Disk on this computer. After moving the home directory to a partition on the SSD, we did some benchmarks with Bonnie++. Here are the raw results:
SSD:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
bamako 8G 310 99 189941 81 75993 46 1629 100 230625 55 2536 114
Latency 71568us 85341us 1448ms 14400us 14075us 436ms
SATA -HD:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
bamako 8G 306 99 40641 32 23211 14 1581 92 65764 16 124.4 7
Latency 71429us 2357ms 1029ms 100ms 508ms 839ms
Version 1.96 ------Sequential Create------ --------Random Create--------
bamako -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 18316 52 +++++ +++ +++++ +++ 32206 76 +++++ +++ +++++ +++
Latency 14297us 1942us 2005us 2236us 308us 378us


As you can see from the benchmarks, Bonnie ++ indicates a thee fold increase in block reading time ( from 65MB to 230MB ), and a five fold increase in block writing time ( from 40MB to 189MB ). Untarring a 2 GB tar file containing the whole Eclipse workspace, took 40s on the SSD, and 3m on the Sata hard drive.
The compile time itself went down from 11 minutes to 7 minutes, and the unit tests run included from 16 to 14 minutes. Eclipse installed on the SSD partition starts noticeably faster, because the start up code is able to find much faster the shared libraries. And Eclipses bundles a lot of them.

The conclusion ? A three fold increase in disk access brings only an average improvement in compilation time, but it brought a lot in the general responsiveness of the workstation. Our developer can now keep using Eclipse while compiling.

So what happened to  all of our workstations ? See below !

About Emmanuel Kasper

Emmanuel Kasper is a System Administrator in the jims!square team and a Freelance writer, active in the NetBSD project.