The other day I decided to test the performance of my SSD (solid state device) against the performance of the hard drive in my home desktop. As expected the SSD device performed much better than the hard disk. I was surprised to find that the performance of the hard disk was different as you move across the disk. A little time on Google and I found three interesting facts.
- The beginning of a hard disk is the outer part of the physical platters.
- The outside of the platters have much better performance than the middle of the platter or end of the logical disk.
- Logical partitions carve out physical space of the disk platters.
If you want information on how a hard disk works you can visit Wikipedia or HowStuffWorks.
Lets look at how my SSD performed for a read test:
The blue line is read throughput. The X-Axis is location on the disk. As you can see its a 120 GB drive. Throughput across the drive is fairly constant as you would expect.
The yellow dots represent seek times for the read operations. The majority of these data points have a low standard deviation and move linearly with the X-Axis.
Now lets look at the performance of my hard disk for the same read test:
As you can see the throughout drops off as you move toward the end of the disk (left to right on the X-Axis). The start of the disk was 90 MB/s and the end was closer to 40 MB/s which is more than a 50% decrease in performance. As the blue line drops (throughput) the seek times increase (yellow dots) in a linear pattern.
Lets briefly look at why hard disk performance is not linear across the disk:
Most disks have a constant value for areal density. Basically X number of bits can be stored in Y amount of physical space on the platter.
Most hard disks spin at a constant rate (10K or 7200 RPMs or something else).
The inside of a desktop hard disk platter (end of the logical disk) has an approximate circumference of 4.75 inches. If the hard disk is spinning at 7200 RPMs there is a total travel of 570 inches per second. Lets say 100k bits of data can be stored in single line per inch. At 570 inches * 100k you get 57000000 bits of data that can be read per second on the inner portion of a disk.
Now lets look at the outside of a desktop hard disk platter (start of the logical disk). Its has an approximate circumference of 11 inches. If the hard disk is spinning at 7200 RPMs there is a total travel of 1320 inches per second. Lets say 100k bits of data can be stored in single line per inch. At 1320 inches * 100k you get 132000000 bits of data that can be read per second on the inner portion of a disk.
Basically the outside of the platter goes over data ~2.3 times as fast as the inside of the platter. Disk manufactures wisely designed disks to fill from largest to smallest circumference to maximize disk performance.
How does this all tie into web application performance testing? Here is an example.
You are testing a platform that streams media files of demand to internet users. You run a test and find that disk queue length is high and that disk read performance is your bottleneck.
Below is the disk configuration for the FTP server. You can see that the FTP files are stored in a partition at the end of the physical disk (inside of the physical disk) where disk performance is at its worst.
When clients are downloading FTP files we can assume the ‘OS Partition’ will be active, logging will be occurring, the application run-time files will be accessed, and there will be heavy reads of the FTP partition.
This partition setup will have created a situation where the seek arm is flying back and forth between partitions. I assume most of the read/write operations will be occurring on the first and last partition maximizing the space between them on the physical disk.
Suggested fixes:
- Move FTP files to the OS partition
- Place the FTP files on a SSD device
- Hold the most frequently used FTP files in memory (potential code changes)
- Add additional FTP servers
Additional info for hard disk performance:

A full study on SSD performance can be accessed @ http://cseweb.ucsd.edu/users/swanson/papers/FAST2012BleakFlash.pdf