Deployment considerations

You've chosen your architecture model. Now it's time to prepare the infrastructure you need to install all necessary components.

This topic covers how to size your hardware, what network access your components need, and how to scale with dynamic infrastructure.

Hardware sizing

Every NeoLoad component needs a server, physical or virtual, with enough CPU, memory, and disk for the load you plan to generate. The following table lists the minimum requirements per component:

Component

CPU

RAM

Disk

Controller

4 cores

16 GB

200 GB free

Load generator

4 cores

32 GB

100 GB free

Test development workstation

2 cores

8 GB

50 GB free

Load generator sizing by test type

Your test type determines how many virtual users a single load generator can support. For cloud deployments, Tricentis NeoLoad sizes load generators automatically. For on-premises and hybrid deployments, use these numbers as a starting point and adjust based on what you observe during test runs. The following table provides sizing guidelines:

Test type

Virtual users per load generator (4 cores, 32 GB)

Virtual users per load generator (8 cores, 64 GB)

Notes

HTTP/API (simple)

500-1,000

1,000-2,000

Basic web requests with minimal processing.

HTTP/API (complex)

200-500

500-1,000

Scripts with correlations, validations, and large responses.

RealBrowser

5-10

10-20

Browser instances are CPU-intensive.

Citrix

5-15

15-30

Citrix sessions are resource-intensive and need a unique username per virtual user.

SAP GUI

10-30

30-50

SAP GUI sessions are resource-intensive and run only on Windows load generators.

These values are approximate. Run a sizing test with your own scripts to find the right capacity, and monitor CPU and memory use during test runs. If usage regularly exceeds 90%, reduce the number of virtual users, increase think times, or add load generators.

Scale with dynamic infrastructure

NeoLoad supports dynamic infrastructure, which automatically provisions controllers and load generators in your Kubernetes or OpenShift cluster. This is a good fit when:

  • You need elastic load generation without permanent servers.

  • Your organization already runs a cluster and you'd like to reuse it.

  • The application you test is only accessible from within the cluster network.

To connect your cluster to NeoLoad Web, deploy the dynamic infrastructure agent. The agent uses outbound-only connections, so your cluster doesn't need to expose inbound API access.

Network requirements

Your network requirements depend on your deployment model. The core principle is simple: every component must reach the components it communicates with.

Cloud deployment

  • The controller needs outbound HTTPS on port 443 to reach the Tricentis NeoLoad cloud.

  • Cloud load generators need to reach your application under test.

  • If your application sits behind a firewall, allow the Tricentis NeoLoad IP ranges.

  • If the controller connects through a proxy, configure the proxy settings in NeoLoad.

  • Verify that DNS resolves correctly from the cloud load generators to your application.

On-premises deployment

  • The controller must reach all load generators on your internal network.

  • Load generators must reach the application under test.

  • The monitoring agent needs access to every system it monitors: application servers, database servers, and network devices.

  • All components must reach the on-premises NeoLoad Web server.

  • You don't need outbound internet access.

Hybrid deployment

  • On-premises components need outbound HTTPS on port 443 to the Tricentis NeoLoad cloud.

  • On-premises load generators must reach the application under test on your internal network.

  • If you also use cloud load generators, allow the Tricentis NeoLoad IP ranges through your firewall.

What's next

Here's where to go after your infrastructure is ready: