Introduction

The document describes how the OnDemand Agents work for Apica LoadTest (ALT), and what to think about to not overload them.

Locations

The typical subscription for an ALT customer is “OnDemand”.

When you set up a loadtest, you choose from a set of locations, from where you want to run your loadtest:

Each location has a number of 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:

How customer jobs are allocated

Each OnDemand Agent has a limit of 500-1000 Virtual Users, depending on location and contract.

When a customer runs a loadtest 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 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 Agent

As stated above, each Agent is allocated up to 500 VU’s, but the CPU load on the Agents can vary a lot depending on the script:

• The number of calls per “page”: More calls => more CPU need

• If calls are made in “parallel” or “serial”: Parallel => more CPU need

• The think time (pause) between each “page”: Shorter time => more CPU need

• The response times of the called resources: Shorter time => more CPU need

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 1000 calls per second.

How can you see if an Agent is overloaded?

Comparing 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 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

Compare to this:

In this example, there was no difference, so the Agent worked fine!

Looking in 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 the file in the ZebraTester/MyTests folder.

Open the file in the ZebraTester UI/Project Navigator:

Then click the magnifying glass:

Then select the “Diagram: Load Generator Performance:

Finally, look at the CPU graph:

In this example, the usage is very low, so we’re fine!

SSL Cache Efficiency

You can check for this in the result file (see the previous chapter), 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 per Page | URL (Details)” view. Compare the numbers in the A SSL/TLS column with the Av Time column. In the example below, about 10% of the time is spent on SSL.

How to avoid overloading Agents?

1. Use longer think time between pages.

2. Use more locations. This will spread the load over, several Agents.

3. Make sure the SSL connections can be re-used.