JMeter doesn’t just send requests; it emulates users interacting with your SOAP services, revealing bottlenecks before they impact real customers.
Let’s see JMeter in action, simulating traffic to a fictional weather API.
# JMeter Test Plan: Weather API Load Test
# Thread Group: 100 users, Ramp-up 60s, Loop Forever
# HTTP Request:
# Protocol: http
# Server Name or IP: api.weather.example.com
# Port Number: 8080
# Method: POST
# Path: /weatherService
# SOAP/XML Data:
# <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wea="http://weather.example.com/schemas">
# <soapenv:Header/>
# <soapenv:Body>
# <wea:GetWeatherByCity>
# <wea:CityName>${city}</wea:CityName>
# </wea:GetWeatherByCity>
# </soapenv:Body>
# </soapenv:Envelope>
# User Defined Variables:
# city: London
# city: Paris
# city: Tokyo
# city: New York
# city: Sydney
# Listener: View Results Tree
# Listener: Aggregate Report
This plan simulates 100 users, gradually increasing over a minute, hitting our weather API. Each user sends a SOAP request to get weather data for a city, cycling through London, Paris, Tokyo, New York, and Sydney. The View Results Tree shows individual requests and responses, while Aggregate Report gives us high-level metrics like average response time, throughput, and error rate.
The core problem JMeter solves is understanding how your SOAP services perform under concurrent load. A service might respond instantly to a single request, but choke when 100 users hit it simultaneously. JMeter lets you discover this breaking point.
Internally, JMeter’s Thread Group is the engine. Each virtual user is a thread, executing the samplers (like the HTTP Request) defined in the test plan. These threads are managed for ramp-up, duration, and iteration. The HTTP Request sampler is configured to send POST requests with a specific SOAPAction header (often omitted by JMeter if the XML envelope implies it, but good practice to include if the WSDL specifies it) and the actual SOAP XML payload. Variables like ${city} allow for parameterization, making tests more realistic by simulating different user inputs.
The Aggregate Report is crucial for analysis. It summarizes results across all threads, showing:
- Average: The mean response time for requests.
- Median: The 50th percentile response time.
- 90% Line: 90% of requests completed within this time.
- 95% Line: 95% of requests completed within this time.
- 99% Line: 99% of requests completed within this time.
- Min: The fastest response time.
- Max: The slowest response time.
- Error %: Percentage of requests that failed.
- Throughput: Number of requests per second/minute.
- Received KB/sec: Data received.
- Sent KB/sec: Data sent.
You can adjust the Thread Group settings (number of threads, ramp-up period, loop count) to mimic different user behaviors and load profiles. For instance, a shorter ramp-up with more threads simulates a sudden surge in traffic.
When testing SOAP, you’ll often use a HTTP Header Manager to explicitly set Content-Type to text/xml;charset=UTF-8 and SOAPAction if required by the WSDL. The SOAP/XML Data field within the HTTP Request sampler is where your actual SOAP message XML goes. JMeter’s support for Property functions (like ${__threadNum}, ${__time(yyyyMMddHHmmss)}) and CSV Data Set Config elements are invaluable for generating dynamic and varied request payloads, moving beyond simple static values.
The most common pitfall when load testing SOAP services with JMeter is failing to properly configure the HTTP Request sampler’s body data. Many beginners copy-paste the XML directly without realizing that dynamic elements, like unique identifiers or session tokens, need to be parameterized. Using a CSV Data Set Config to feed varying data into the SOAP envelope, or employing JMeter’s built-in functions, is essential for realistic simulations. The SOAPAction header, while sometimes inferred, is often a critical part of the request that must be explicitly defined, typically via the HTTP Header Manager.
Once you’ve mastered basic load testing, explore how to distribute your JMeter tests across multiple machines to simulate even larger user loads.