Performance engineering and load testing | Anexia

For performance analysis, we describe which transactions occur, how often and how many at the same time. A uniform sequence of simple requests can only inadequately reflect real user behaviour. Peaks, longer sessions and functions of varying complexity are therefore taken into account. Data volume and distribution can also change runtime behaviour significantly.

In performance optimisation, the test setup is checked for possible limitations. An overloaded load generator must not be mistakenly interpreted as the limit of the application. For performance engineering, we observe response times, errors and resources across the components involved. Individual averages can hide slow user groups or rare bottlenecks. The investigation links load levels with targeted hypotheses about the cause. Optimisations are then reassessed under comparable conditions. In this way, load testing provides traceable statements about the tested load profile and the effective improvements. No blanket capacity commitment for any future usage is derived from it.

Scope of services for performance engineering

The agreed scope for performance analysis can include the following results: load model, test scenarios, measurement concept, bottleneck analysis and comparative results. For each key result, we define what it is for, who reviews it and in what form it is handed over. This allows development, operations and procurement to assess the same service. Vague umbrella terms in the proposal are replaced by concrete work packages.

Performance optimisation also includes coordinating the necessary interfaces with your team. We clarify access, contacts and available testing options before the relevant implementation steps. Changes to the scope are described with their impact on effort and sequence. This gives you a traceable overview of delivered results, outstanding prerequisites and additional requests.

The key technical decision

The test reflects business transactions and realistic distributions. A high number of identical requests can lead to misleading results. For load testing, we document the relevant assumptions and justify the chosen option. Key alternatives are considered against the same business requirements. This makes later adjustments easier when load, data volume or organisational responsibility changes.

A sound decision also takes maintainability and handover into account. For performance analysis, we examine which skills are available internally and what additional support is needed. Technical possibilities are thus linked to a realistic operating model. The client can see which tasks will recur after the project and which decisions remain with them.

The load generator or an unrealistic test data set can become the bottleneck and wrongly appear to be a problem with the application. We treat this point as a concrete review question in performance optimisation. A risk is linked to the affected process, its possible impact and a suitable measure. Where prerequisites are still missing, the statement remains explicitly open until the necessary investigation has taken place.

We check throughput, response time distribution, error rate, resource consumption and recovery after an overload. For performance engineering, we record the initial situation, the tested configuration and the result. Acceptance relates to the agreed scope. Open limitations are documented visibly and assigned to an owned next step. This enables your team to distinguish between proven functionality, a deliberate decision and an assumption that has not yet been confirmed.

Project example as an illustrative scenario

The following scenario is an illustrative example and not a customer reference. A customer portal needs to handle a seasonal peak in traffic. In performance engineering, the usage model would be clarified first. Do all visitors read the same content, or do they carry out different transactions? Repeated identical requests could be answered very quickly thanks to caches and give an unrealistically favourable impression.

For load testing, the test would reflect various user flows, data volumes and concurrent sessions. The load generator itself would have to be sufficiently powerful and demonstrate its actual generation rate. Response time distributions, errors and the resource consumption of the components involved would be measured. A slow target system or a growing queue would have to be investigated specifically. An optimisation would then be retested under comparable conditions. Business correctness must not be lost in the process, for example through skipped processing or incomplete results.

Acceptance of the performance analysis would document the load model used, observed limits and proven improvements. Planned results would be a traceable capacity status and prioritised technical measures. A good average would be insufficient if relevant user groups have to wait a very long time. The client would be able to see for which tested scope a statement applies and which assumptions need to be investigated again for new features or changed load profiles. Unlimited growth would not be derived from this.

Our experience and our engineering approach

We combine custom software development with the technical tasks of introduction and further development. For load testing, we bring the perspectives of application, integration and operations into a shared workflow. The business requirements remain connected to the technical decisions. You work with a defined scope of services and traceable results.

Our experience should be concretely verifiable for your initiative. That is why, in a technical discussion, we explain how we investigate the relevant risks, which work results are planned and how your team can assess them. For performance analysis, we align the roles involved with actual needs. Available references are presented with their respective project and company context; confidential customer details are not used as general advertising claims.

Effort for performance analysis

Test environment, data preparation, the variety of scenarios and necessary optimisation steps determine the effort. We therefore calculate performance engineering on the basis of a defined scope and explicitly stated prerequisites. An initial analysis step can be useful if key technical information is still missing. Work packages and acceptance criteria can then be agreed on a more reliable basis.

Load testing can be organised as a limited project, as a joint implementation with your team or with subsequent support. Rights of use, access, documentation and responsibilities are clarified in the contract. Ongoing operating hours, response times and external consumption costs are covered by separate agreements. This keeps it clear which services are provided once and which tasks recur after introduction.

Boundaries of performance engineering

A test result applies to the tested load and system model; untested growth scenarios are not guaranteed across the board. For performance optimisation, we set out this boundary in the proposal itself. Required additional services are included with their business justification and are not silently assumed. Your team can thus plan suitable internal skills and divide the overall work sensibly between the parties involved.