Feeds Back Into Tuning

Back to Performance Tuning and Capacity Planning · Scheduled Cadence · Forecast vs. Actual · Cost-Aware Scaling · Service Offerings

Review findings loop back into bottleneck analysis and tuning, keeping the whole cycle current as the system evolves. This is the step that decides whether everything before it was worth doing. A review that ends in a document ends; one that ends in a bottleneck continues.

1. Four Stages, One Loop

The cycle in the illustration has no natural starting point and no end, which is the point of drawing it that way.

• Review establishes where utilisation is, what the runway is, and which resource is closest to its limit — see scheduled cadence.
• Bottleneck analysis takes the constraining resource and finds out what is consuming it, rather than assuming.
• Tuning changes one thing: a parameter, a query, a pool size, a cache.
• Measure establishes what the change actually did — see before-and-after measurement.

The measurement is also the next review's starting data, which is what closes the loop rather than merely ending the sequence.

2. Turning a Finding Into Work

Most findings die between the review and the backlog. The gap is small and entirely procedural:

• Each finding leaves the review as a ticket, written during the meeting, not afterwards.
• It carries its measurement — the graph, the number, the date. A ticket that says “database is slow” will be closed as unreproducible in six weeks.
• It carries its consequence: what runs out, and when, if nothing is done. This is what lets it compete with feature work on comparable terms.
• It has an owner and a target review — the one at which its result will be examined.

3. Tuning Invalidates the Review That Found It

A successful change moves the constraint somewhere else. The utilisation numbers, the runway figures and the forecast from the last review all describe the system as it was before.

• Re-measure after each significant change rather than waiting for the next scheduled review, if the change was large.
• Expect the bottleneck to move. The second constraint was always there, hidden behind the first.
• Re-derive the runway. A tuning change can extend it by more than a year, which changes what needs buying — and that is the result worth reporting.

4. When Tuning Is the Wrong Answer

The loop has an exit, and refusing to use it is its own failure mode. Tuning has diminishing returns and at some point capacity is simply the cheaper option.

• When the remaining inefficiency is small — the easy multiples are gone and the next change is weeks of work for a few per cent.
• When the limit is architectural. A single-writer database at its write ceiling is not a tuning problem.
• When the lead time has run out. Tuning is uncertain in both effect and duration; provisioning is not. Close to a deadline, buy the capacity and tune afterwards.
• When capacity is cheaper than the engineering time, which cost-aware scaling will tell you directly.

The useful discipline is making that comparison explicitly each time, instead of defaulting to whichever the team prefers.

5. What Keeps the Loop Turning

• The findings register. One list, carried from review to review, showing what was found, what was done, and what it achieved. Without it each review restarts from nothing.
• A standing allocation. Capacity work that competes with features case-by-case loses case-by-case. A small fixed share of each cycle is more durable than occasional escalation.
• Reported results. “This change deferred a hardware purchase by eighteen months” is what buys the next allocation.
• Closing items honestly. Findings that were considered and deliberately not acted on should be closed with that reason, not left to accumulate until the list is ignored.

6. The System Keeps Changing Underneath

Every tuning decision rests on a workload profile, and the profile moves: new features, new clients, a changed data distribution, a dependency upgrade. A setting that was correct two years ago is not automatically correct now, and nothing in the system will announce that it has stopped being.

This is the real reason the cycle has no end. It is not that the work was done badly the first time — it is that the thing being tuned does not hold still.

How We Approach It

1. Write each finding as a ticket during the review, with its measurement, its consequence, an owner and a target date.
2. Take the constraining resource into bottleneck analysis rather than tuning what is familiar.
3. Change one thing and measure it, so the effect is attributable.
4. Re-derive utilisation and runway after significant changes, because the previous figures no longer describe the system.
5. Compare tuning against capacity explicitly each time, and take the exit when it is the right one.
6. Keep one findings register and report what the cycle achieved.

What You Get

• Review findings that leave the meeting as owned, measured, dated work.
• A findings register carried between reviews, with outcomes recorded.
• Re-measurement after each change, so the next review starts from current data.
• An explicit tune-or-provision comparison rather than a default.
• A record of what the cycle has saved, which is what keeps it funded.

The question worth asking: of the findings in the last capacity review, how many became work, and how many are still in the document?