Which kind of “slow” do we mean?
A search takes too long. An export blocks everyone’s work. An application gets sluggish in the afternoon and is fine in the morning. These observations describe different problems. We start with the operation that actually costs the people at the screen their time.
We also note the conditions under which it happens: amount of data, concurrent use, the process affected. The target belongs there too. How fast does this operation need to be for the work to carry on properly?
Bring the stopwatch to the meeting.
We follow a request’s path through the system. How much time is spent in the application, how much on data access, how much waiting for another service? A small, well-placed measuring point can be more useful than a big assumption.
We look at the slow cases as well. A pleasant average doesn’t help much if some users regularly have to wait. Measurements need context; without comparable conditions, two numbers soon tell two different stories.
One change, one verifiable effect.
Once the bottleneck is tangible, we make as targeted a change as possible and repeat the same process. Did it get faster? Is the result still correct? What happens under the load that really occurs in production?
A cache, for example, can save waiting time but raises questions about freshness and memory use. More parallelism can speed up a process and overload a dependency at the same time. Weighing that up is part of the solution.
Fast enough is a useful target.
We want to know whether the improvement reaches the user and holds up in production. Once the agreed target is met, the next problem may matter more than another decimal place.
So a simple description is a good way to start: “This operation takes too long under these conditions.” That is already far more useful than “We probably need a new architecture.”
Sound familiar?
Tell us about it