Performance & Security Testing Services

Performance testing: load, stress and soak

A performance testing service is only useful if each run answers a question someone will act on. Load, stress and soak tests answer different questions, so the test strategy names which of them your release needs and what each must show. All three are run with Apache JMeter. The workload model typically comes from your analytics or your business forecast: which endpoints, in what mix, with what data, at what concurrency.

When a number misses its target, the number is not yet the finding. Bottleneck analysis follows the slow requests into the services and databases behind them — whether latency rises while throughput flattens (a saturated resource such as CPU or a connection pool), whether errors appear before slowness (a hard limit), and which queries slow down under concurrency — so that a finding can name a cause, not only a symptom.

• Load test — does the product meet its targets at the traffic you expect? The expected workload at normal and peak levels, compared with the targets you set.
• Stress test — where is the limit, and how does the system fail? Load is raised past the expected peak until errors or time-outs appear, to see whether the system degrades with clear errors and recovers by itself, or crashes and needs a restart.
• Soak test — does it stay healthy for hours? A realistic load held for several hours exposes memory leaks, connection-pool exhaustion, and tables or queues that grow until everything slows down.
• Metrics — latency, throughput and error rate. Latency is typically read as percentiles (p50, p95 and p99 rather than the average, which hides the slow tail) and broken down by endpoint, so a fast home page cannot hide a slow checkout.

Pass/fail criteria: agree thresholds before the run

A test without agreed thresholds measures, but it cannot pass or fail. Thresholds should be agreed before the first run, as numbers tied to a workload and a time window — whoever runs your load tests, ask for them. The table is an illustrative example for the checkout of a fictional shop, Bustan Market — your values come from your own traffic, journeys and commitments, not from this page.

How response time is measured matters as much as the limit. For every request, JMeter records the elapsed time from just before the request is sent to just after the last part of the response arrives; it does not include browser rendering or JavaScript. Those per-request times are summarised as percentiles — JMeter's HTML dashboard reports the 90th, 95th and 99th by default — next to throughput and error rate. Useful criteria also say which window counts (usually the steady state after ramp-up), what counts as an error (5xx responses, time-outs, and 200 responses with an error body caught by an assertion), and when a run is invalid rather than passed: the load generator itself saturated, the build changed mid-run, or the environment was not the one agreed.

Security testing: common OWASP weaknesses in web apps and APIs

The security part checks your web application and its APIs for the common weaknesses catalogued in two OWASP lists: the OWASP Top 10:2025 for web applications and the OWASP API Security Top 10 (2023 edition) for APIs. Checks run in the agreed environment; access-control checks need test accounts for each role. Both lists are references, not checklists to tick: the OWASP Web Security Testing Guide (WSTG) describes how each weakness is tested, and the Application Security Verification Standard (ASVS) states testable requirements — both useful to your team when it writes the fix and its own regression test.

Authentication, authorisation and input handling are reviewed as part of this service. They are where the two lists overlap and where automated scanners are weakest: a scanner cannot know that customer A must not read customer B's order. Some categories — such as Software Supply Chain Failures (A03:2025) and Insecure Design (A06:2025) — are only partly visible from the outside, and testing alone cannot rule them out.

Scope boundary: what this service does not claim

This is testing for common weaknesses and measured performance, with the evidence behind each finding. It is worth being precise about what it is not, so you can plan anything else you need.

• Not a certified penetration test or a compliance attestation. The report is test evidence: it does not certify compliance with a regulation or a standard. If an auditor, a regulator or a client contract requires either, plan for it separately; the findings and re-test results from this work remain useful input.
• Mobile apps: the APIs a mobile app calls are in scope and get the same checks as any other API. The app package itself — data stored on the device, platform interaction, resistance to reverse engineering and tampering, the areas the OWASP MASVS standard defines — is not part of this service as described here.
• Not a denial-of-service exercise. A stress test finds the capacity limit of your system under controlled load from a load generator; it is not a simulation of a distributed attack.
• Third-party services — payment gateways, SMS providers, national integrations — should not receive test load without their owner's permission. Whoever tests for you, make sure the scope says whether each one is replaced by a stub or called through its sandbox.
• Production: testing runs against a test or staging environment. Running anything against production is your decision; if you make it, agree the targets, rate, time window and stop conditions explicitly beforehand (see the FAQ).

How an engagement runs

The work follows the same six stages as every Mutqan Soft engagement, adapted to performance and security. A stage is not closed until its output exists.

The engineer who runs the tests writes the findings and verifies the fixes, so nothing is lost between the person who found a problem and the person who confirms it is gone.

What you receive

Findings land in the tracker your team already uses, and test documentation and reports are in Arabic or English — whichever your team works in. The table shows the shape of a performance finding, on the same fictional checkout as above.

• Latency, throughput and error-rate metrics — typically as percentiles per endpoint and per run. Whoever measures for you, ask for each number together with the workload and environment it was measured under; without them it cannot be compared next time.
• Findings ranked by severity, each with reproduction steps, environment and evidence (request, response, timings or a recording). A critical finding is reported immediately, not held for the final report.
• Fix recommendations: what to change and where — an index, a pool size, a missing ownership check, a header.
• A re-measurement after the fixes (typically with the same workload, so the comparison is honest), and every fix re-tested.
• Execution logs and a written release decision: what was tested, what remains open, and which risks are accepted.

What we need from you

Product, stack and release date are enough to start the conversation. To run the tests, these need to be in place:

• An environment: a test or staging environment as close to production in size and configuration as possible; where it differs, the difference is written into the report so the numbers are read correctly. And a build that does not change during a run.
• Traffic and dates: the expected peak in users or requests per second, the main journeys, the release date and any seasonal peaks — or the analytics to derive them from.
• Test data at volume: synthetic accounts (at least two per role, for the access-control checks) and a database filled to a realistic size — not copies of real customer records.
• Access: the API contract (OpenAPI or a Postman collection), test accounts, and read access to monitoring, logs or database metrics during the runs. Repository access helps root-cause analysis but is not required.
• Clear authorisation: with any provider, it is worth writing down which hosts and endpoints are in scope for load and security tests and when they may run, and checking whether a WAF or rate limiter needs the load generators allow-listed.
• A contact: one technical person who can read logs, restart a service and stop a run if something unexpected happens.

When to run performance and security testing

• Before a launch or a major release — before thousands of users measure the performance themselves on launch day.
• Before a seasonal peak: government digital services before their seasonal peak load, e-commerce before its sale seasons — with the workload set to the expected peak, not to an ordinary day.
• After an architecture change: a new database or caching layer, a move to another cloud or region, a new API gateway or message queue — ideally re-measured with the same workload as before the change, so the comparison is honest.
• After a change to authentication or permissions: a new SSO provider, a new token scheme, new roles or tenants — with the access-control and session checks run again.
• When an API is opened to partners or to a mobile app — it becomes reachable by clients you do not control.
• When production is already slow — the slowdown is reproduced under controlled load in a test environment and the bottleneck found before the next peak.

Frequently asked questions

References

• Apache JMeter User's ManualApache Software FoundationHow to build, parameterise and run load tests with JMeter, and how to read its listeners and reports.
• OWASP Top 10:2025OWASP Foundation · 2025The ten most critical web application security risks, with how to test for and prevent each.
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023The ten most common API weaknesses: broken object-level authorization, broken authentication, unrestricted resource consumption and more.
• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• OWASP Application Security Verification Standard (ASVS)OWASP FoundationA checklist of verifiable security requirements for web applications, grouped in three assurance levels.
• OWASP Mobile Application Security Verification Standard (MASVS)OWASP FoundationOWASP's security requirements for mobile apps, grouped into control areas such as storage, cryptography, authentication, network and platform interaction.