SOAP 1.1 and 1.2 calls, WSDL, faults, WS-Security, large messages and hardening checks.
Category SOAPStack Any SOAP service (JAX-WS, WCF, Axis, Spring-WS, Zeep, PHP SoapServer)Jobs 27
About this SOAP web services load test
Load tests any SOAP service (JAX-WS, WCF, Axis, Spring-WS, PHP SoapServer): the WSDL, SOAP 1.1 and 1.2 calls, WS-Security, and hardening checks such as malformed XML, unknown operations, a wrong SOAPAction or content type and a DTD in the request, plus large messages, a capacity ramp and a ten-minute soak.
It holds 27 ready-made jobs: 14 single scenarios and an enterprise test plan of 13 stages to run in order, 11 of them with pass/fail targets (SLOs). Each job is a plain request pattern you can change before running.
Scenarios include fetch the WSDL, fetch the WSDL (cache bypass), SOAP 1.1 call, SOAP 1.2 call and WS-Security UsernameToken.
How to load test SOAP web services
Open the template in BLASTA.
Set url, soapAction, namespace, operation and param to point at your own SOAP web services system, ideally a staging copy.
Pick a job and choose the rate and duration.
Start the run and watch requests per second, latency percentiles and errors live; the result is saved to your history.
A SOAP Fault is returned with HTTP 500, so a Fault counts as an error here. The baseline request: XML parse, dispatch, business logic and response serialisation.
A SOAP Fault is returned with HTTP 500, so a Fault counts as an error here. Same operation with the SOAP 1.2 envelope and content type; some stacks route the versions differently.
A SOAP Fault is returned with HTTP 500, so a Fault counts as an error here. Adds authentication in the header. Needs SOAP_USER and SOAP_PASSWORD (CLI only; the web UI does not expand environment variables). Token validation is often the slow part.
A harmless inline entity declaration. A hardened parser REFUSES documents with a DOCTYPE (400 or a Fault); a 200 here means DTDs are processed, which is an XML external entity risk.
A SOAP Fault is returned with HTTP 500, so a Fault counts as an error here. Ramps the SOAP call to find where latency climbs. XML processing is CPU heavy, so expect a lower ceiling than for JSON.
A SOAP Fault is returned with HTTP 500, so a Fault counts as an error here. Steady load that finds leaks in session state, JAXB/DOM caches and connection pools.
Enterprise test plan (13)
Run in order: smoke, baseline, load, stress, spike, soak, breakpoint and failover window, each with pass/fail targets.
Enterprise plan, step 1 of 10. One request a second for 30 seconds. Run this first, every time: it proves the address, credentials and headers are right and that the environment is up before any real load is applied. Gate: zero errors. Reference request: SOAP 1.1 call.
Step 2 of 10. About a fifth of normal traffic for 5 minutes: the uncontended latency of this request. Every later result is judged against it, so record p50 and p95. Gate: at most 0.5% errors and the default latency targets. Reference request: SOAP 1.1 call.
Step 3 of 10. Normal busy-hour traffic for 10 minutes. The rate is the reference job's rate: raise it to your measured production peak-hour rate. This is the run that proves (or breaks) your SLO. Gate: at most 1% errors, p95 and p99 inside the targets. Reference request: SOAP 1.1 call.
Step 4 of 10. Twice the average for 10 minutes: the busiest hour of the year plus headroom. Latency may rise, but must stay in SLO; if it does not, you have no headroom. Gate: at most 2% errors, latency targets doubled. Reference request: SOAP 1.1 call.
Step 5 of 10. Ramps to four times average over 10 minutes, then holds for 2. Finds where it degrades and HOW: gracefully (latency rises, errors stay low) or badly (errors, timeouts, crashes, restarts). Observation only, no gate. Reference request: SOAP 1.1 call.
Step 6 of 10. Reaches ten times average within 10 seconds and holds for 2 minutes: a campaign email, a news link, a failover. Checks autoscaling, queue limits and load shedding. Gate: at most 5% errors, because shedding load is acceptable and crashing is not. Reference request: SOAP 1.1 call.
Step 7 of 10. Run IMMEDIATELY after the spike, at average load for 5 minutes. Latency and errors must return to the baseline from step 2. If they do not, something is stuck: queues, connection pools, GC, an autoscaler cool-down. Gate: same as average load. Reference request: SOAP 1.1 call.
Step 8 of 10. One hour of steady load. Finds leaks and slow decay in memory, connections, file descriptors, disk, log volume and cache churn. Watch the resource graphs: any line that climbs and never flattens is a finding. Gate: at most 0.5% errors. Reference request: SOAP 1.1 call.
Step 9 of 10. Ramps to twenty times average over 20 minutes. Stop it when errors pass about 5%: the rate at that moment is your ceiling, and ceiling divided by peak is your capacity margin. Use a production-like environment, never production. Reference request: SOAP 1.1 call.
Step 10 of 10. Average load for 15 minutes. About 5 minutes in, cause the event you are testing: kill a pod or node, fail over the database, roll out a new version, drain a zone. Errors in the window are your real availability loss. Gate: at most 1% errors overall; read the time series for how long the dip lasted. Reference request: SOAP 1.1 call.
Twice normal for 10 minutes. XML parsing is CPU bound, so SOAP services often saturate a core long before the network. Reference request: SOAP 1.1 call.
Clients refetch the WSDL when they restart, so a rolling restart of 50 client instances is a burst of WSDL requests. Ten times normal for 90 seconds. Reference request: fetch the WSDL.
Three times normal authenticated calls for 10 minutes. Token validation is often the slow part. Reference request: WS-Security UsernameToken.
Frequently asked questions
What does the SOAP web services load test cover?
The SOAP web services template has 27 jobs: 14 single scenarios and an enterprise test plan of 13 stages (smoke, baseline, load, stress, spike, soak, breakpoint and failover window). Scenarios include fetch the WSDL, fetch the WSDL (cache bypass), SOAP 1.1 call and SOAP 1.2 call. 11 of them have pass/fail targets (SLOs), so a run can be judged against limits you set.
How do I load test SOAP web services with BLASTA?
Open the template in BLASTA and set url, soapAction, namespace, operation and param, then pick a job and start it. Results stream live: requests per second, latency percentiles and errors, and the run is kept in your history. To run from the command line, use blasta preset new soap-services with your address.
Is it safe to run the SOAP web services load test against production?
All 27 jobs in this template are read-only: they request pages or data and do not change anything. Even so, a load test can slow a live system down, so start with a low rate and prefer a staging copy. Only test systems you own or have permission to test.
Sign in
Welcome back. Sign in to run and review load tests.
Set up a target above and press Start test. Charts and numbers appear here as the test runs.
Load generator resources
CPU used by BLASTA % of capacity
RAM used by BLASTA
Requests per second
Latency p95 lower is better
Response time
Status codes
Errors
Pick a template
Ready-made jobs for common systems. Search by system, protocol or what you want to test
(wordpress, saml, redis, spike, login storm…), pick a job, and it opens on the Test page ready to run.
You are browsing as a visitor: you can read every template and job. Sign in or create an account to use them.
No templates match
Try a shorter search, or a system name such as keycloak, postgres or soap.