Slow Software: Measure the Bottleneck and Replace It

"The system is slow" is not a diagnosis. The cause can lie in the database, an interface, the infrastructure or a single program component. Only once the bottleneck has been measured can it be fixed in a targeted way.

Status: October 2026

01How software becomes slow

An application rarely becomes slow overnight. It usually happens gradually:

• Data volumes grow over the years.
• Interfaces and external services are added.
• Background processing becomes more extensive.
• More users work at the same time.

Seconds turn into minutes. For an individual user this seems bearable for a long time, but across many operations a day it adds up.

02What can be measured

"Slow" is an impression. What can be measured:

• Response time: how long an operation takes from trigger to result
• Throughput: how many operations are processed per second or hour
• Resources: CPU time, memory, disk and network access
• Waiting time: how long the application waits for the database or interfaces

For response times, the average hides the outliers. Percentiles are more meaningful: the p95 value states how long the slowest 5 percent of operations take at least. These are exactly the operations users notice.

Measurement uses profilers, which show the function in which CPU time is spent. Tracing tools such as OpenTelemetry follow an operation across several services. For databases, the execution plan (EXPLAIN) shows how a query is actually processed.

03Why measurement decides

Amdahl's law describes how much a speed-up helps overall. What matters is the share of the accelerated part in the total time.

An example: an operation takes 10 seconds. One component accounts for 8 of them. If this component is sped up to 1 second, the operation takes 3 instead of 10 seconds. If instead a component with a 1-second share becomes twice as fast, the operation takes 9.5 seconds.

This is why an improvement at an easily reached but rarely used spot achieves little. And without measuring beforehand, there is no way to show afterwards whether a change worked.

04Where time is typically lost

Database:

• queries inside loops instead of a single batched query (the so-called N+1 problem)
• missing or unsuitable indexes, visible in the execution plan
• large amounts of data transferred unfiltered and only sorted out in the application

Application:

• calculations repeated on every call although the result does not change
• algorithms whose run time grows disproportionately with the data volume
• memory consumption that rises with the data volume until the system swaps or the process fails with out-of-memory

Interfaces:

• many individual calls instead of batched transfer
• synchronous waiting for external services in the middle of an operation
• responses containing far more data than needed

Infrastructure:

• CPU, memory or storage at the limit
• background processing running during core business hours
• caches that are missing or deliver outdated data

05Rebuild or a single component

The first reaction to slow software is often: "This needs to be rebuilt." But a rebuild does not solve an unknown cause. It moves it into a new, larger project.

Measurement often shows that most of the waiting time arises in one or a few places. Then exactly this part can be replaced, behind the same interface. The rest of the application stays unchanged. In software development, this approach is called the strangler fig pattern: a system is renewed piece by piece without interrupting operations.

For the new component to behave exactly like the old one, automated tests are needed. They capture today's behaviour. Old and new code receive the same inputs, and the results are compared.

Sometimes the limit lies in the programming language itself, for example garbage collection pauses, memory errors in C or C++, or limited parallel processing. Then the component is rebuilt in another language, for example Rust, or Go where parallel processing is the limit.

06What a measurable requirement contains

"The software is slow" becomes a testable requirement once four details are fixed:

• Operation: which function or processing is too slow
• Baseline: how long it takes today
• Conditions: with which data volumes and under which conditions it is measured
• Target: which response time, throughput or memory consumption is to be reached

An example: a monthly report takes 18 seconds today. Under the same test conditions, it is to take no more than 3 seconds. After the change, it is measured again. This establishes whether the target has been met.

Seovantis rewrites the measured bottleneck, in the same or another language, with agreed behaviour and, where agreed, a measurable target value: Rewriting program components

Sources

• Gene M. Amdahl: Validity of the single processor approach to achieving large scale computing capabilities (opens in a new tab), 1967
• Martin Fowler: Strangler Fig Application (opens in a new tab)
• OpenTelemetry: documentation on tracing and metrics (opens in a new tab)
• Google: Site Reliability Engineering, chapter "Monitoring Distributed Systems (opens in a new tab)"