Find the .NET performance fix worth funding

Buy an answer to one question

Name the feature and the decision: can the stock search meet its agreed response target on the existing infrastructure without returning incorrect availability?

Before choosing a millisecond target, count affected searches and establish what the delay interrupts: active staff work, dispatch cutoffs or customer commitments. That gives the business owner a basis for judging the value of an improvement.

Agree the search inputs, customer permissions, data sizes and busy-period demand to include. Keep unrelated screens outside this investigation. The business owner sets the acceptable wait, freshness requirements and spending limit; engineering identifies the measurements and access needed.

Approve a time-bounded investigation with a named reviewer and decision date. Its deliverable is a supported recommendation with repeatable evidence. A working fix is possible, but should not be promised before the cause is understood.

Establish a comparison the business can trust

A single fast response tells you little about the delay staff encounter during a busy shift. Capture current search latency, failures and correct-result checks across representative inputs. Include searches with many matches and users with different access scopes.

Record the deployed version, resource limits, dependency versions, data snapshot, cache state and actual request rate. Repeat the baseline to see how much it varies. That variation matters when judging whether a small improvement is credible.

Use an approved test environment with Release builds and production-like configuration. Microsoft distinguishes load testing at a specified demand from stress testing beyond normal conditions, and recommends Release rather than Debug builds. Choose the former when the question is whether this feature meets an agreed operating target. ASP.NET Core load-testing guidance

If test capacity or data differs materially from production, record the gap before interpreting the result. A useful comparison can still leave production capacity unproven.

Change the suspected cause, then repeat the experiment

Now ask which explanation the evidence supports. Use the request investigation guide for waits across application boundaries, or the EF Core query review when database access dominates. This experiment should follow the evidence to one candidate change.

For example, suppose the capture shows repeated calls for product descriptions. Test reducing those calls while keeping available quantities current. If caching is proposed, agree acceptable description staleness and how updates invalidate the cache. The optimization must preserve the business rules that made the search useful.

Keep infrastructure and workload comparable between baseline and candidate runs. Changing capacity, caching and query shape together would make the outcome harder to attribute. Measure resource use alongside response time so a faster response does not hide an unacceptable operating cost.

Make acceptance executable

Once the business targets are agreed, put them into the test. Grafana k6 thresholds turn metric limits into pass/fail results. Failed checks alone do not fail a run; a threshold on the checks metric makes correctness part of the gate. k6 thresholds and checks

This options fragment illustrates an 800 ms API target and requires every emitted stock-result check to pass:

export const options = {
  thresholds: {
    'http_req_duration{operation:stock-search}': ['p(95)<800'],
    'checks{operation:stock-search}': ['rate==1'],
  },
};

The existing harness must tag both requests and checks with operation:stock-search, and check each response against controlled expected products, quantities and permissions, including failures. It must supply the agreed workload and verify that it actually ran. This is configuration, not a complete load test; 800 ms is illustrative, not a recommended universal target.

Here, http_req_duration measures sending, waiting and receiving, excluding initial connection setup. It does not measure browser rendering or the employee's complete search task. Keep the API target separate from the user-experience measurement. k6 metric boundaries

End with an investment decision

Present baseline and candidate results together, including variation, correctness failures, resource cost and remaining gaps. Then recommend one next action:

• Release the candidate through the agreed rollout when it meets acceptance criteria, with an owner checking the production outcome
• Fund the next measurement when a material uncertainty still prevents a decision
• Stop or defer when the likely benefit does not justify the remaining cost

An inconclusive experiment can still prevent an unsupported purchase. Close it with what was learned, what remains unknown and what the next decision would cost to establish.

Example scope: the configuration was checked against k6 documentation and JavaScript syntax. No application, load test or performance benchmark was run.