A server upgrade needs a proven bottleneck

A slow portal makes a larger machine a conceivable solution. Whether the added capacity improves the affected workflow depends on what it is waiting for. A capacity decision therefore needs a link to the observed bottleneck.

Test two explanations for the same wait

The following comparison is entirely hypothetical. It contains no findings from a customer project and no measured performance gain.

Both causes can occur together. The application, network or an external service can also contribute waiting time. A single CPU reading does not explain the entire workflow.

Name the purpose of a change

If the specific flow reveals unnecessary small data calls, we would first investigate their structure. More processor power does not automatically remove either the call count or the overhead of each data path. A focused comparison can show whether fewer round trips help this task.

This does not justify a general recommendation to leave the machine unchanged. When capacity shortage is evidenced, more capacity can be useful, for example if the required work volume exceeds available resources. The decision should state which limit it changes and how the benefit would be recognised.

For a comparison, the task, permitted data and expected result must remain equivalent. Fewer fields, a populated cache or lower concurrent load might otherwise explain the difference. A faster response with missing records would not be an equivalent result.

The question for a proposed change is therefore: which observed cause should it affect, and how will that specific effect be tested? This applies to a new server as much as to a change in data access.

Sources

• Microsoft — Chatty I/O antipattern

• Microsoft — Architecture strategies for defining performance targets