There are many unknown factors and randomness when a solution architect determines storage requirement for an application. However, this process should still be as scientific as it can be and here are some of the important considerations regards application I/O characteristics.
Random and Sequential
| Random I/O | Sequential I/O | |
| Description | Successive read/write operations from noncontiguous addresses – accesses that are spread across the addressable capacity of the LUN. | Successive read/write operations from contiguous addresses: one logical block address after another. In sequential I/O access, disk seek time is reduced because the read/write head moves little to access the next block. |
| Example | Messaging OLTP application | Data Backup |
Reads and Writes
Another aspect of the I/O workload is the ratio of read I/Os to write I/Os generated by application. The sum of the read and write rate is the I/O rate (number of I/O operations per second). The application’s I/O rate is one of the important factors that determine the minimum number of disks required for application. In storage systems, cache plays an important role to improve the system performance. The table below summarizes how read I/O and write I/O interact with cache.
| I/O Type | READ | WRITE |
| Random | Hard to effectively cache because of difficulty in predicting prefetch; Requires multiple fast disks for good performance | Caching is effective, resulting in a response time better than disk response time. |
| Sequential | Caching is extremely effective due to predictability of prefetch; Reads are done at cache speeds; | Caching is effective; cache is flushed quickly because entire disk stripe can be written. |
Here are some typical read versus write ratio for common business applications:
- OLTP: 67% reads and 33% writes
- DSS (decision support, aka data warehouse or business intelligence): 80%~90% reads to data tables including frequent table scans (sequential reads)
- Backup: As long as the file system is not fragmented, file-based backups are sequential
I/O Request Size
The size of I/O generated by an application may vary depending upon the type of the application. Some of the overhead to execute an I/O is fi xed. If data exists in large chunks, it is more effi cient to transmit larger blocks because a host can move data faster by using larger I/Os than smaller I/Os. The response time of each large transaction is longer than the response time for a single small transaction, but the combined service time of many smaller transactions is greater than a single transaction that contains the same amount of data.
| Application | Seek Type | I/O Request Size | Proportion of I/O as writes |
| Microsoft Exchange | Random | 32KB | Moderate to high |
| SAP/Oracle Applications | Random | ~8KB | Depends on application |
| RDBMS: Data entry/OLTP | Random | Database or file system page size | Moderate to high |
| RDBMS: Online transaction logs | Sequential | 512 byte+ | High, except for archiving process |
| RDBMS: Temp Space | Random | Database or file system page size | Very high |
| Web file server | 75% random, 25% sequential | 4KB, 8KB, 64KB | 95% read, 5% write |
| Web server log | 100% sequential | 8KB | 100% write |
| Media Streaming | 100% sequential | 64KB | 98% write; 2% read |
| OS paging | 100% sequential | 64KB | 98% write; 2% read |