Introduction
The document This Guide describes how the OnDemand Agents work for Apica LoadTest (ALT), and what tips to think about to not overload them.
...
| Info |
|---|
The typical subscription for an ALT customer is “OnDemand”. |
Locations
When you set up a loadtestload test, you choose from a set of locations, from where you want to run your loadtestload test:
...
Each location has a number of available OnDemand Agents.
...
Location | Available agents |
Australia - Sydney | 10 |
Brazil - Sao Paolo | 10 |
Canada - Montreal | 10 |
Germany - Frankfurt | 10 |
France - Paris | 50 |
Ireland - Dublin | 10 |
India - Mumbai | 10 |
Japan - Tokyo | 40 |
South Korea - Seoul | 10 |
Sweden - Stockholm | 50 |
Singapore | 10 |
UK - London | 10 |
USA - Ohio | 250 |
USA - Oregon | 250 |
USA - San Francisco | 250 |
USA - Washington DC | 250 |
Total Agents | 1220 |
How
...
Customer Jobs are
...
Allocated
Each OnDemand Agent has a limit of 500-1000 1,000 Virtual Users, depending on the location and contract.
When a customer runs a loadtest load test job, one or more agents are:
Reserved for that customer only
For each location
For the duration of the job
For a maximum of 500 Virtual Users (VU) per Agent
The allocation takes place before the jobs start.
These agents are not available for any other customers or jobs for the duration of the test.
Example:
A customer wants to run a loadtest of 1800 load test of 1,800 VU’s from 2 locations. The system will then allocate 2 agents in each location, and each agent will run 450 VU’s.
When using Performance Test Scenarios and several tests, each test/Job is handled separately.
Performance of a Loadtest Load test Agent
As stated abovebefore, each Agent is allocated up to 500 VU’s, but the CPU load on the Agents can vary a lot depending on the script:
All these call for More/Higher CPUs:
The number of calls per “page”: More calls => more CPU need
Higher calls
If calls are made in “parallel” or “serial”: Parallel => more CPU need
Parallel Calls
The think time (pause) between each “page”: Shorter time => more CPU need
Shorter Think Times
The response times of the called resources: Shorter time => more CPU need
Shorter Response Time
| Note |
|---|
When an Agent is overloaded (e.g. CPU > 90%) it will limit the throughput and the returned performance data will be wrong (too low). |
| Info |
|---|
In general, an Agent can handle up to |
...
1,000 calls per second. |
...
Can you see if an Agent is overloaded?
...
1. Compare Response Times
The typical symptom of an overloaded Agent is that the total duration of a test iteration (“loop time”) is clearly longer than the sum of the “page times”.
This is because not all execution time is included in the page times, for . For instance, SSL handshakes, HTTP handshakes, and garbage collection.
When the CPU of the Agent is overused, these processes may take significant time.
Example:
On the test “Overview” tab look for this
...
Then click the magnifying glass next to the Load Test name:
...
Then select the “Diagram Diagram: Load Generator Performance:
...
Finally, look at the CPU Usage graph:
...
In this example, the usage is very low, so we’re fine! 
2. Leverage SSL Cache
...
Efficiencies
You can check for this in the result file (see the previous chaptersection), by selecting Diagram: SSL Cache Efficiency. In the example below, it shows that a new SSL handshake was performed for each and every request. This can be CPU intensive.
...
Also, look at the “Results Results per Page | URL (Details)” view. Compare the numbers in the A Av SSL/TLS column with the Av Time column. In the example below, about 10% of the time is spent on SSL.
...
...
| Tip |
|---|
Tips to Avoid Overloading Agents
|
...
|
...
|
...
|