ESG Lab performs in-depth technology validation testing and assessments using the tools available through the links on this page.  ESG is pleased to provide these tools and suggestions to help you test technology solutions in your own environment.

Iometer

Iometer is a software tool that creates traffic and measures the performance capabilities of a storage solution.   It was created originally by Intel in 1996. It has since been released as an open source application. Iometer is used by technology vendors, IT organizations and ESG Lab.  ESG Lab frequently uses Iometer during technology validations.  ESG Lab Validation reports are freely available on the ESG site.  The Iometer application and documentation are freely available at this link.

ESG Lab Workloads

Iometer uses a configuration file with a file extension of “.icf” to describe I/O workloads used during performance testing. The fill icon on the top left of the user interface for IOMETER is used to load an IOMETER configuration file.  The ESG Lab Iometer workload configuration file has been developed based on more than ten years of experience developing and testing storage systems.  You can download the ESG Lab Workloads in a zip file here. In order to use the ESG Lab workloads, you must also download and install the IOMETER program.

The majority of the ESG Lab workloads are designed to mimic the behavior of real-world applications. The balance is generally referred to as “the corners.”  Using a car as an analogy, “the corners” are used to determine raw performance metrics like horsepower, torque and acceleration from zero to sixty.  Application workloads are more like a test drive which can be used to get a feel for performance in real-world conditions.

The Corners

• 1 Block seq read – This workload is used to assess the front-end capabilities of a storage system. This workload is typically serviced out of the cache within a storage controller. It stresses the CPU, front-end bus and code efficiency of the storage controller. The metric that matters the most for this workload is I/Os per second.
• 4KB random read – This workload is used to assess the back-end capabilities of a storage system. Random reads tend not to benefit from cache, so this test places the maximum stress on the disk drives within a storage system.  Most of the I/O traffic generated by interactive applications like on-line databases and e-mail systems tend to be composed of random reads. The metric that matters the most for this workload is I/Os per second.
• 4 KB random write – This workload places maximum stress on the back-end of a storage system due to the fact that disk drives and storage systems tend to write slower than they read. While many real-world applications have some random write traffic, this test should be considered a worst-case test that has little resemblance to any real-world application. The metric that matters the most for this workload is I/Os per second.
• 512 KB seq read – This is a large block sequential read test. This stresses all aspects of a storage system. Video streaming is an example of an application that is composed of sequential reads.  The metric that matters the most with this test is throughput measured in KB/sec, MB/sec or GB/sec.
• 512 KB seq write – This is a large block sequential write test which stresses all aspects of a storage system. Backup jobs and video surveillance are examples of  throughput intensive sequential write applications. The metric that matters the most with this test is throughput measured in KB/sec, MB/sec or GB/sec.

Intel Application Workloads

These workloads were originally distributed with Iometer by Intel.  They were developed in the late 1990s to mimic the behavior of real-world applications. While the workload characteristics of these applications have changed over the years (generally larger I/O requests), ESG Lab believes that these workloads continue to provide a good approximation of real-world application performance. Because these workloads have been around for almost a decade, results based on these workloads have been published by a number of vendors and third party organizations, including ESG Lab.

• 4 K OLTP – An interactive on-line database application.  Order entry and reservation systems are example of OLTP applications. Oracle and Microsoft SQL Server are examples of database applications that are used to create OLTP applications.  OLTP applications are characterized by a number of users accessing a shared system in parallel. I/Os are mostly random reads (70%).
• 8K OLTP – This is the exact same workload as described above, but with a block size of 8 KB instead of 4 KB.  Over the past decade, OLTP applications could generally be characterized as using 4 KB as a typical block size.  As of this writing, OLTP applications are trending towards 8KB.
• File Server – This workload is meant to mimic the I/O activity of a file system. Examples include a network-attached shared home or corporate directory.
• Web Server – This workload is meant to mimic the I/O activity of a web server, such as Apache.

ESG Application Workloads

• Windows Media Player – This workload mimics the behavior of Windows Media Player on a Windows 2007 server. It is composed of 32 KB sequential reads.
• Exchange data – This workload was designed to simulate the I/O activity of a Microsoft Exchange 2003 e-mail database with a file extension of .EDB.
• Exchange Logs – This workload was designed to simulate the I/O activity of a Microsoft Exchange 2003 e-mail log with a file extension of .LOG.
• Exchange attachments – This workload was designed to simulate the I/O activity of a Microsoft Exchange 2003 attachment file with an extension of .LOG.
• Backup writer – This workload mimics the behavior of a backup application. The workload prescribes 64 KB I/O requests which is the default block size used by a number of backup applications.   Best practices and tuning guidelines for a number of backup applications is tending towards 256 KB.
• Backup reader – This workload mimics the behavior of a backup application during a restore operation with a default block size of 64 KB.
• Decision support- This workload, also referred to as data mining, emulates a database application that is doing a large-scale random query with a block size of 4 KB. An end of month analysis of the effect of a coupon redemption program on same store sales is an example of a decision support application.
• OS drive – This workload was designed to mimic the I/O activity of an operating system drive. For example, the operating system traffic directed at the C: drive on a Windows server.
• OS paging – This workload is meant to emulate the paging traffic as an operating system swaps the contents of memory pages to disk.
• Video on Demand – This workload emulates the large block sequential write activity of a video on demand application.
• Web server logs – This workload, composed of 8 KB sequential writes, is meant to mimic the I/O activity associated with a web server log file.
• SQL logs – This workload, composed of 64 KB sequential writes, is meant to mimic the I/O activity associated with a Microsoft SQL server log file.
• VDI Characterization – This workload, designed to emulate a virtual desktop environment composed of heavy knowledge worker users, is composed of 80% 16KB Random writes and 20% 16KB random reads.

You can download the ESG Lab Workloads in a zip file here.