MODERNIZATION BENEFITS
Slow Software: Performance and Capacity Planning
Investigate slow reports, peak-time delays and user limits. Start with an operation that matters to the business.
Updated:
SHORT ANSWER
Software performance has business value when a report, order or other task can be completed sooner. Start with the delayed operation and target user load to identify the bottleneck to address.
Why it matters
In Red Hat’s second application modernization report, organizations currently modernizing report benefits in security (58%), scalability (53%) and reliability (52%).
Source: The state of application modernization, second edition · Red Hat · Published: · Accessed: Red Hat-sponsored self-report survey of 1,000 IT respondents in the US, UK and English-speaking Asia-Pacific, October–November 2023. Percentages apply to the modernizing subgroup; they establish neither causation nor outcomes from our service.
Deloitte's mobile-site study of 37 brands observed a relationship between a 0.1-second improvement in each of four speed metrics and conversion-rate increases of 8.4% in retail and 10.1% in travel.
Source: Milliseconds Make Millions · Deloitte Ireland LLP / Deloitte Digital · Published: · Accessed: Commissioned by Google; Europe and the US, mobile web, October 28–November 24, 2019. Correlation from natural speed changes, not causation or a guaranteed outcome. The numeric field represents retail.
Are you waiting for the report or the task to finish?
A slow report, lengthy import or screen that stops responding at peak times can hold up everyday work. Start by separating delays in the query, data transfer and interface.
How can slow reports and screens be addressed?
- Working with large lists: Filter and paginate records so the screen loads what the task needs.
- Tracking long operations: Run imports or report generation in the background, with progress and errors visible.
- Handling busy periods: Assess queries, resources and concurrent-user limits together to make capacity decisions concrete.
Which operation should the first performance test cover?
Choose the screen or report that causes the most waiting. Establish its data volume and peak user load, then make that operation the first part of application modernization.
If waiting comes from approvals or missing information, address the workflow first. For a software delay, test a query or screen change before considering a wider migration.
Choose a measurement that resembles your workflow
| Work that keeps people waiting | Implementation changed in the lab |
|---|---|
| Waiting for price, stock and delivery responses during an order | Java integration: sequential calls to bounded concurrency |
| Preparing customer reports | PHP: repeated scans to a single aggregation pass |
| Reading the same database records repeatedly | SQL: table scans to indexed and grouped queries |
| Filtering a long invoice list | Frontend: render the viewport instead of every row |
| Matching imported rows to a product catalog | .NET: repeated list searches to keyed access |
Change the recorded workload in each case to compare the original implementation, control arms and modernized implementation on the same time scale.
Measurement approach
Each implementation processes the same synthetic task and data. Output-equivalence checks, environment, repetitions and raw records are published with each case. We separate code changes from runtime changes: the same-bytecode Java 8 → 25 experiment remains available as a control with its small measured difference. These are not client-application measurements. Explore all measurement methods.
Evidence from the lab
200,000 orders summarized
↓ 99.4%Lower is better · Median of 10 runs
Measurement method →CPU time for the same task
↓ 99.4%Lower is better · Median of 10 runs
Measurement method →50,000 catalog import rows
↓ 99.8%Lower is better · Median of 10 runs
Measurement method →CPU time for the same task
↓ 99.8%Lower is better · Median of 10 runs
Measurement method →50,000 invoices filtered and listed
↓ 98.8%Lower is better · Median of 10 runs
Measurement method →256 orders completed
↓ 87.1%Lower is better · Median of 10 runs
Measurement method →CPU time for the same task
↓ 51.7%Lower is better · Median of 10 runs
Measurement method →5,000,000 orders summarized
↓ 99.8%Lower is better · Median of 10 runs
Measurement method →CPU time for the same task
↓ 99.8%Lower is better · Median of 10 runs
Measurement method →200,000 orders summarized
↓ 99.3%Lower is better · Median of 10 runs
Measurement method →CPU time for the same task
↓ 99.3%Lower is better · Median of 10 runs
Measurement method →In-memory report over 1 million orders
↓ 0.3%Lower is better · Median of 10 runs
Measurement method →Explore your own situation
Frequently asked questions
Is the fastest run enough for a comparison?
A single run can conceal variation between attempts. The planned protocol retains raw durations and explains the number of runs and whether a median or mean is used, rather than selecting only the best attempt.
Why show median and p95 separately?
The median helps describe a typical response, while p95 helps examine slower responses in the distribution. Error rates are also needed: showing faster responses while hiding unfinished work would distort the comparison.
How is the speed ratio shown when the old system times out?
An unknown completion time is never recorded as zero. A recorded timeout limit supports an at-least ratio, expressed as a lower bound; without that limit, no ratio is produced.
Does a faster mobile website guarantee a matching increase in sales?
No such outcome is guaranteed. The mobile-web study above describes an observed relationship for specific brands and a particular period, not a rate that transfers directly to your internal application or sales.
Does the simulation slider test every possible record count?
The slider selects loads actually recorded for the chosen experiment. Concurrent orders in the Java integration and records in a report are different units. Each point compares implementations processing the same data; it does not invent intermediate values or run a new test.