ALT OnDemand Agents Guide
Introduction
This Guide describes how the OnDemand Agents work for Apica LoadTest (ALT) and tips not to overload them.
The typical subscription for an ALT customer is โOnDemand.โ
Locations
ย
Location Map | OnDemand Agent Locations |
---|---|
When you set up a load test, you choose from a set of locations from where you want to run your load test: ย | Each location has several available OnDemand Agents. |
ย
OnDemand Agents
On the following link, you can find up-to-date information about locations and agents:
ALT Agent Global Locations with IPs
The current number of available agents per location:
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-1,000 Virtual Users, depending on the location and contract.
When a customer runs a 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 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 Load test Agent
As before, each Agent is allocated up to 500 VUโs, but the CPU load on the Agents can vary a lot depending on the script:
Each of these conditions calls for More/Higher CPUs:
The number of calls per โpage.โ
Higher calls
If calls are made in โparallelโ or โserial.โ
Parallel Calls
The think time (pause) between each โpage.โ
Shorter Think Times
The response times of the called resources
Shorter Response Time
When an Agent is overloaded (e.g., CPU > 90%), it will limit the throughput, and the returned performance data will be wrong (too low).
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
Loop Time > Page Times = Agent Overload
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 instance, SSL handshakes, HTTP handshakes, and garbage collection.
When the Agent's CPU is overused, these additional processes may take significant time for the agent to process so that they will be added to the Loop time but NOT the Page Time.
Example:
On the test โOverviewโ tab, check the Average Response time Per Loop | Compare the Loop Response time to the Page Summary Total |
There was no difference; the Loop included each of the 5-page response times, so the Agent worked fine! |
Looking at the detailed result file | |
---|---|
Once a job is finished, you can download the detailed result file and analyze it. In the โJobsโ view, click the download icon for the job youโre interested in. | |
This will get you an xxx.prxres file. Put that file in the ZebraTester/MyTests folder. Open the file in the ZebraTester UI/Project Navigator: | |
Then click the magnifying glass next to the Load Test name: | |
Then select the 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
More SSL Cache Hits Help Agent CPU
ย
Check SSL Cache Efficiency and Percent time Spent on SSL. | |
---|---|
You can check for this in the result file (see the previous section) by selecting Diagram: SSL Cache Efficiency. The example below shows that a new SSL handshake was performed for every request. This can be CPU intensive, so keep the SSL Cache-hits as high as possible; Offloading this to the cache keeps the Agent CPU lower. | ย |
Also, look at the Results per Page | URL (Details) view. Compare the numbers in the Av SSL/TLS column with the Av Time column. In the example below, about 10% of the time is spent on SSL. |
ย
ย
Cannot find what you're looking for? Send an E-mail to support@apica.io.