What Is IOPS? Disk Performance, NVMe SSDs and fio Testing

What is IOPS and what does it measure in disk performance?

IOPS stands for Input/Output Operations Per Second. It tells you how many read and write operations a drive can complete in one second. The higher the number, the faster the drive answers small and frequent requests. Databases and WordPress sites, which read many small pieces of data, depend on it.

We wrote this guide for site and store owners and for developers who need to understand a hosting or VPS disk decision. If you manage your own VPS, you can run the commands in order. We also explain why each step exists, because most disk problems come from a wrong measurement.

We are a digital marketing and web team, not a hosting company. So the explanation rests on the fio and MySQL documentation, on interface standards and on product documents. Where we give a number, we name the source next to it. Where we have no source, we write "typical range, varies by product".

Also, the examples use only documentation IP blocks and example.com as the domain. Never paste real passwords, keys or production domains into a file you copied from a tutorial.

What is the difference between IOPS, throughput and latency?

In short, these three numbers describe the same drive from three angles. IOPS counts operations, throughput measures the data moved per second (MB/s), and latency shows how long a single operation takes. One can be high while another stays low.

For example, a highway comparison helps. Throughput is the width of the road, so it shows how much traffic fits through at once. IOPS is the number of cars that pass in an hour. Latency is the time one car needs to get from point A to point B.

• IOPS: operations per second. It matters for many small requests.
• Throughput (MB/s): data volume per second. It matters for large file copies and backups.
• Latency: the duration of one operation. It is the closest number to the wait your visitor feels.

So reading only MB/s or only IOPS can mislead you. For example, a backup job may show a high MB/s figure. The same drive can still feel slow when hundreds of small queries arrive together.

How does latency relate to IOPS?

When latency drops, a system that waits on one operation at a time completes more operations per second. The basic relation is simple: operations per second approach the number of simultaneous operations divided by the average latency. Queueing theory calls this Little's law.

For example, consider this calculation. With an average latency of 0.1 milliseconds and one operation at a time, you can complete at most 10,000 operations per second. If latency rises to 1 millisecond, the ceiling falls to 1,000. These numbers only show the logic. They are not the values of any real product.

In short, an IOPS figure is not a standalone "power rating". Vendors often measure the headline value with many simultaneous operations. Your site, however, often sends a few queries one by one. In that case, low latency helps you more than a huge IOPS number.

We also covered latency on the network side. Take a look at our article on ping, latency and RTT. That one is about server distance, while this one is about how fast the disk answers.

What is the difference between random and sequential reads and writes?

In a sequential operation, the drive reads or writes data one piece after another in a single stream. In a random operation, it asks for small pieces from different places in the file. Random access is where the gap between drive types shows most.

For instance, copying a large backup file is a sequential example. A database reading index pages from scattered locations is a random one. Most website workloads fall into the second group.

A mechanical drive has to move its read head physically. Therefore, its IOPS drop sharply under random access. The MySQL documentation says that older-generation disks can perform about 100 IOPS. On the other hand, flash-based SSDs have no moving parts, so random access is far faster.

• Sequential reads: backups, large file transfers, video streaming.
• Random reads: database queries, many small PHP and image files.
• Random writes: session files, logs, order records.

How does block size change IOPS and MB/s?

In practice, throughput is roughly IOPS multiplied by block size. The same drive shows high IOPS with small blocks and high MB/s with large blocks. So you must know the block size before you read any test result.

Here is an example calculation. 10,000 operations per second at a 4 KB block size equal about 40 MB/s. If the same drive does 500 operations per second with 1 MB blocks, you measure about 500 MB/s. The drive is identical in both tests, and only the workload has changed.

The default block size of fio is 4 KB, and the official documentation states it. Many random access tests use 4 KB too, because it represents small reads and writes. The "MB/s" figure on a marketing page, however, usually comes from a large-block sequential test.

Also, when you compare numbers from two providers, block size, queue depth and read/write mix must match. Otherwise the comparison means nothing.

What is queue depth and why does it matter?

Queue depth is the number of operations waiting at the drive at the same moment. As depth grows, an SSD can work on operations in parallel and IOPS rise. A mechanical disk gains little, because it has a single head.

A test with queue depth 1 measures only the single-request case. Sometimes that is realistic, for instance for an admin panel with one user. On a busy store, however, dozens of queries wait for the disk at once. Then a higher depth is more realistic.

Keep one point in mind: as you raise the depth, IOPS go up, but latency goes up as well. Also, what your visitor feels is latency. So a good test reports IOPS and latency percentiles together.

The interface also shapes the queue. The AHCI protocol behind SATA supports a single command queue with up to 32 commands. NVMe supports up to 64,000 queues with up to 64,000 commands each (source: the phoenixNAP comparison of NVMe and SATA).

What is the difference between HDD, SATA SSD and NVMe SSD?

First, an HDD works with mechanical platters and a read head. A SATA SSD uses flash cells behind a SATA interface. An NVMe SSD uses the same flash but connects over PCIe straight to the processor. The gap shows up in latency and parallelism, not only in speed.

The phrase "varies by product" is deliberate. Still, even two drives in the same class can differ a lot. Before you decide, read the manufacturer's data sheet and independent test results. Source: phoenixNAP comparison of NVMe and SATA.

Why does NVMe work differently from a SATA SSD?

NVMe is a protocol designed from scratch for the speed of flash memory. SATA and AHCI, by contrast, date from the era of spinning disks. NVMe talks to the processor over PCIe lanes and uses many queues in parallel.

According to phoenixNAP, NVMe can move data over four PCI Express lanes connected directly to the motherboard. The same source says latency is lower than on SSDs that connect through SATA. The theoretical bandwidth also rises above the 600 MB/s limit of SATA.

You need to separate two terms here. "SSD" is a kind of memory, while "NVMe" is the way that memory connects. So every NVMe drive is an SSD, but not every SSD is NVMe. If a hosting plan only says "SSD", it may well be SATA.

An M.2 card does not have to be NVMe either. Also, some M.2 cards run over SATA. So look for the word "NVMe" on the product page.

Does an NVMe SSD make a difference on every site?

No. NVMe helps only when the disk is the bottleneck of your site. On many content sites, slowness comes from PHP processing time, heavy plugins, large images and a missing cache rather than from the disk. Changing the drive then barely changes the result.

The chain is long when a page loads: network, web server, PHP, database and disk. So the slowest link sets the total time, and the disk is only one part of that chain.

When a cache is on, the page often comes from memory or from a ready file. So disk requests drop. For example, on a WordPress site with a full page cache, most visitors never touch the database. Therefore the requests that skip the cache feel the disk difference most.

• Low traffic and static pages: the disk type stays in the background.
• Many uncached requests such as the admin panel, search and filters: the disk starts to matter.
• Heavy database writes: the disk is the first place to look.

We explained how speed affects search in how does site speed affect SEO.

How does a database workload depend on IOPS?

First, a database splits its data into small pages and reads and writes them on disk. So the workload is random and small by nature. Every page that is not in memory means a disk read, and every transaction log record needs a write. For that reason a database is one of the workloads most sensitive to IOPS.

The InnoDB engine in MySQL exposes this as a setting. According to the official documentation, the innodb_io_capacity variable should be set close to the number of I/O operations the system can perform per second. The default value is 200. The page suggests about 100 for hard drives up to 7200 RPM, the default 200 for lower-end SSDs, and a value such as 1000 for higher-end SSDs.

However, changing this setting is not always a good idea. Also, a value that is too high can create flushing pressure the disk cannot handle. Also, on a server your provider manages, you often cannot change it at all.

More effective steps are usually these: add a missing index, find slow queries and give the buffer pool enough memory. Source: MySQL documentation on InnoDB I/O capacity.

Where do you feel disk performance on a WordPress site?

In practice, WordPress can run dozens of PHP files and database queries on each request. Without a cache, every visit rebuilds that chain from scratch. So you feel the disk most in the admin area, in a WooCommerce cart and in search results.

The admin panel does not use the page cache. Also, plugin and theme updates write many small files. On a slow disk, an update therefore takes longer. Backup plugins also read and compress files at the same time, so they can slow the rest of the site.

However, the situation is more critical in e-commerce. Stock updates, order records and session handling produce writes all the time. We covered the effect of speed on sales in e-commerce page speed and sales.

PHP has a gain too. Also, OPcache keeps compiled PHP code in memory and cuts file reads. You can find the details in what is OPcache.

Which disk question should you ask about a hosting plan?

First, check whether the plan says "SSD" or "NVMe". Then find out whether the disk is shared with others and whether your account has an I/O limit. On shared hosting, neighboring accounts use the same disk. So the disk type alone is not enough.

For example, some shared plans set a per-account disk I/O and IOPS limit. Because of that, when you hit the limit, the site slows down even if the drive is fast. Usually the limit appears on the plan page or in the terms of use. If it does not, it makes sense to ask the provider.

We collected the general selection criteria in how to choose web hosting. The disk question is only one item on that list.

What disk questions should you put to your hosting provider?

The questions you send should be short and measurable. Instead of "is it fast?", ask about the disk type, the sharing model and the limits. Keep the written answer, because it becomes your reference if a problem appears later.

1. What is the disk type: HDD, SATA SSD or NVMe?
2. Is there an IOPS or I/O limit on my account or virtual machine?
3. Is the storage redundant, and how does redundancy affect performance?
4. Can other customers on the same disk affect me during peak hours?
5. May I test disk performance with my own tools?
6. Are backups kept on the same disk or on separate storage?

However, the fifth question matters. Some providers treat a heavy test load as a breach of their terms. So ask for permission first and measure afterward. For backups, see our article on website backup strategy.

How do IOPS limits work on VPS and cloud disks?

On virtual servers, the disk is often carved out of the provider's shared storage. For that reason some providers tie IOPS and throughput to the plan. In other words, two disks of the same size can deliver different speeds on different plans. The limits appear in the plan documentation.

A disk that reaches its limit does not crash, but it slows down. Instead, operations wait in a queue and latency rises. You see this as slow queries and longer page times. So "disk size" and "disk speed" are separate questions.

Then there are two ways out. The first is to move to a plan with a higher limit. Alternatively, you can cut the requests that reach the disk with caching and indexes, which is often cheaper. However, if you really do exceed the limit, an upgrade becomes unavoidable.

Also, when you read the values in a provider's documentation, look for the same test conditions. If the block size is missing, for example, treat the figure with care.

How do you measure disk performance with fio?

fio is the most common tool for disk testing on Linux. You define a job: the read or write type, block size, queue depth and duration. Then it reports IOPS, bandwidth and latency percentiles. The command below measures 4 KB random reads.

fio --name=random-read --filename=/var/tmp/fio-test.bin --size=1G \
    --rw=randread --bs=4k --ioengine=libaio --iodepth=32 \
    --direct=1 --runtime=30 --time_based --group_reporting

Let us explain the parts of the command. --rw=randread selects random reads. --bs=4k sets the block size. --direct=1 skips the operating system cache, so you measure the drive itself. --time_based and --runtime=30 keep the test running for 30 seconds.

To measure sequential speed and a mixed load, you change the same pattern.

# Sequential read, large block
fio --name=seq-read --filename=/var/tmp/fio-test.bin --size=1G \
    --rw=read --bs=1M --ioengine=libaio --iodepth=8 \
    --direct=1 --runtime=30 --time_based --group_reporting

# Random mixed load, 70 percent reads
fio --name=mixed --filename=/var/tmp/fio-test.bin --size=1G \
    --rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --iodepth=16 \
    --direct=1 --runtime=30 --time_based --group_reporting

# Delete the test file
rm /var/tmp/fio-test.bin

These commands work on a file and do not write to a raw disk. However, a fio job that writes to a raw device can destroy data. So think twice before you type a device name by hand. For details, see the official fio documentation.

How do you read fio output?

In the output, look first at the IOPS= and BW= line, then at the clat line. IOPS shows the operation count, BW shows bandwidth and clat shows completion latency. The percentile table of latency is the best way to catch slow requests.

However, average latency can mislead you. The 99th or 99.9th percentile shows how slow the slowest requests are. If visitors notice a stutter on a page, these tail values are usually the cause.

• High IOPS with high latency: the queue depth may be too large, so repeat the test with a lower depth.
• Low IOPS with low latency: the test may be limited to a single request.
• Results swing from minute to minute: the disk may be shared, or another process is loading it.

Repeat the test several times at different hours, because a single run can be a coincidence. Also, a test on a disk that serves a live site slows your visitors too. So measure in a maintenance window if you can.

How do you spot a disk bottleneck on a live server with iostat?

iostat is part of the sysstat package and shows how busy a disk is while the server runs. It only watches and creates no load, so it is safer than fio on a live system. For extended output, you use the command iostat -x 1.

iostat -x 1

Column names differ a little between sysstat versions. In general you see reads and writes per second, read and write wait times, the average queue length and the utilization percentage. If wait times climb and the queue grows, the disk is the bottleneck.

However, do not trust the utilization percentage alone. SSDs and NVMe drives work in parallel, so they can show 100 percent while spare capacity remains. Wait time and queue length are more reliable signs.

If the disk is fine, look elsewhere. Also, CPU, memory and network can slow a site just as much. To see where requests come from, you can also use our log file analyzer.

What should you do first if the disk looks slow?

Even if the disk looks slow, replacing it should not be the first step. First, cut the number of requests that reach the disk. Caching, indexes and image optimization usually give a cheaper and faster result than a bigger drive.

• Page cache: keeps the page ready, so PHP and the database do not run.
• Object cache: stores the results of frequent queries in memory. See our article on Redis and Memcached.
• HTTP cache: puts a caching layer in front of the app, and Varnish Cache does that job.
• Database index: avoids needless full table scans.
• Image size: fewer bytes mean fewer reads.

Then measure again. Without before and after values, however, you cannot know which step worked. For the page side, testing site performance with Google Lighthouse is a good start.

If you still see disk latency after these steps, moving to a faster plan makes sense.

How does RAID affect IOPS?

RAID uses several disks as one unit, and depending on the level it changes both IOPS and resilience. Because the topic deserves its own page, we give only a short note here. We cover RAID in detail in a separate article.

The overview is this: some levels raise read IOPS, while others add overhead on writes. So "it has RAID, therefore it is fast" is not a valid conclusion. If a hosting plan mentions RAID, ask whether it is there for speed or for resilience.

Also, RAID is not a backup. For example, if you delete a file by mistake, or ransomware encrypts your files, RAID does not protect you. You always need a separate backup strategy.

When should you leave disk work to your provider instead of doing it yourself?

On shared hosting, managed VPS and managed cloud plans, disk tuning is the provider's job. On these plans, running your own disk tests or touching kernel settings goes beyond your access and carries risk. Instead, it is better to open a support ticket and share your measurement.

If you run your own VPS, you can measure with fio and iostat. However, in these cases it is safer to leave the work to an expert or to your provider:

• You would need to write to a raw disk or partition that holds live data.
• You plan to change the file system, RAID or disk layout.
• No backup exists, or you never tested restoring one.
• You plan a load test on a live store at peak hours.

We do not operate hosting; we support the web and marketing side. For technical decisions, your provider's official guidance comes first. If you plan to rebuild your site, take a look at our web design service.

Which disk type fits which workload?

For example, for a small brochure site, almost any SSD is enough. For a database-heavy store, NVMe is a sensible target. The table below gives a starting direction by workload. It is a field-experience starting direction, not a guarantee.

Base the decision on results you measure on your own workload, not on headline numbers. To see which technology a site runs on, our website technology checker is useful for a first look.

What are the most common IOPS mistakes?

First, the most common mistake is to decide from a single number. Second, people often compare two tests that use different block sizes and queue depths. Third, some blame the disk when the bottleneck sits elsewhere.

• Treating the peak IOPS on a marketing page as the value your site will see.
• Reading only MB/s and never measuring random access.
• Testing with the cache on and believing you measured the disk itself.
• Running a heavy load test on the disk of a live site.
• Skipping the cache and index steps and going straight to an upgrade.

Also, do not trust a one-off measurement. Also, disk performance can vary with the hour and with neighboring load. So take at least a few measurements before you decide to change hosting. That way you also avoid the cost of a wrong upgrade.

For problems beyond the disk, our SEO consulting service can help on the technical SEO and speed side.