The collection runs for a day because a day is what fits in the customer’s change process and the salesperson’s timeline. Then the report gets treated as a description of the workload.

A day is a sample. Whether it is a representative sample depends entirely on what the workload does on the days you did not sample.

What a short window misses

Month end. Finance systems, reporting, batch consolidation. For a large class of enterprise applications, the busiest day of the month is four to ten times the median day. If your window did not contain it, your peak numbers are not peak numbers.

Backup. The backup window is often the heaviest sustained read the storage sees all week, and it is frequently excluded from consideration because “that’s just backup”. It is not just backup. It is a workload with a duration and a deadline, and it competes.

Weekly cycles. Monday morning is not Wednesday afternoon. A window that runs Tuesday to Wednesday will tell you the calmest part of the week.

Quarter and year end. Rarely captured, occasionally the only period that actually matters for a given system.

Seasonal business. Retail in December. Utilities in a heat wave. Anything in the public sector when a deadline lands.

The minimum I now ask for

Seven days, covering at least one full weekly cycle, and positioned to include a month end if the systems in scope are financial. If somebody cannot give me seven days, I will take what I can get and put the limitation on the front page of the output rather than in a footnote.

The sentence I use: “This sizing is based on a 24-hour collection taken on a Wednesday. It does not include month-end processing, and the peak figures should be treated as a lower bound.”

Nobody has ever objected to that sentence. Several people have gone and arranged a longer collection because of it.

Averages, percentiles and peaks

Once you have a window, there are three numbers you can quote and they differ by a lot.

The average is almost useless for sizing. It describes a machine nobody experiences.

The peak is the highest sample observed. It is real, but it may be a single anomalous spike caused by something that will not recur, and sizing to it is expensive.

The 95th percentile is usually the honest basis: the level the system exceeds only five percent of the time. It ignores single freak samples while respecting sustained busy periods.

The trap is that different tools default to different ones and do not always label which. When a vendor quotes an IOPS figure at you, ask which of the three it is. The answer changes the required configuration substantially, and I have seen the same collection produce proposals that differed by a factor of two because two people quoted different statistics from the same dataset.

Sampling interval matters too

A tool that samples every five minutes and reports a peak is reporting the peak five-minute average. Inside that five minutes there may have been a thirty-second burst at four times the rate. For most capacity sizing this smoothing is fine. For anything latency-sensitive, or for a queue-depth conversation, it hides exactly the events you care about.

If burst behaviour matters to the application, a coarse sampling interval will not show it to you, and no amount of extending the window will fix that.

The habit

Write the window, the statistic and the interval on the same page as the result. Three short facts. “Seven days, 15 January to 22 January, 95th percentile, five-minute samples.”

It takes one line, it is honest, and it makes your number auditable by the next person who picks it up. That is worth more than looking certain.

Next: reading the storage figures without being led by them.