Deployment considerations

You've chosen your deployment model. Before you install anything, you need to prepare the infrastructure. This topic covers the key considerations for hardware, network, and scaling. It doesn't explain how to install step by step. Instead, it tells you what to plan and what to discuss with your infrastructure team.

For step-by-step install and setup procedures, see controllers and load generators.

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 32 GB 250 GB free
Load generator 4 cores 32 GB 100 GB free
Test development workstation 2 cores 8 GB 50 GB free

For cloud and hybrid deployments, you still need to provision a controller server yourself. Tricentis manages load generators in cloud zones.

Load generator sizing by test type

The number of virtual users a single load generator can support depends on the test type. The following table provides sizing guidelines:

Test type Virtual users Cores / RAM Notes
HTTP/API Up to 500 4 cores / 32 GB A single load generator is sufficient.
HTTP/API 500-2,000 8 cores / 64 GB Add more load generators for larger tests.
RealBrowser Up to 50 4 cores / 32 GB Browser instances need more resources per user.
Citrix Up to 25 4 cores / 32 GB Citrix sessions are resource-intensive.
SAP GUI Up to 50 4 cores / 32 GB Each SAP session requires dedicated resources.

Monitor CPU and memory during test runs. If usage regularly exceeds 90%, reduce virtual users, increase think times, or add more load generators.

For cloud deployments, Tricentis sizes load generators automatically. For on-premise and hybrid, use these numbers as a starting point and adjust based on what you observe during test runs.

Monitoring agent

The monitoring agent collects server-side metrics from your application infrastructure. It runs on a separate server and needs network access to the systems you want to monitor, such as application servers, database servers, and load balancers. The resource requirements for the agent itself are modest.

NeoLoad Web, on-premise only

If you deploy NeoLoad Web on-premise, you need a server for the web application and a database backend. Plan for the following:

  • Database size grows with the number of test results you store. Configure retention policies to control growth.

  • Consider a load balancer or reverse proxy in front of NeoLoad Web if many users access it at the same time.

Network requirements

The network requirements depend on your deployment model. The core principle: every component must reach the components it communicates with. Here's what that looks like for each model:

Cloud deployment

A cloud deployment has the following network requirements:

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

  • Cloud load generators need to reach your application under test. If your application is behind a firewall, allow the Tricentis cloud IP ranges. Work with your network team to configure this.

  • 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-premise deployment

An on-premise deployment has the following network requirements:

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

  • Load generators must reach the application under test.

  • The monitoring agent must reach the systems it monitors, such as application servers, database servers, and network devices.

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

  • No outbound internet access required.

Hybrid deployment

A hybrid deployment combines requirements from both models:

  • On-premise components, specifically the controller and load generators, need outbound HTTPS on port 443 to the Tricentis cloud.

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

  • If you also use cloud load generators, they need to reach your application. Allow the Tricentis cloud IP ranges through your firewall.

  • The monitoring agent follows the same rules as on-premise.

Scale with Kubernetes

NeoLoad supports container-based deployment for load generators. If your organization uses Kubernetes, you can orchestrate load generators as pods and scale them on demand.

This approach is useful when you:

  • Want elastic load generation without permanent servers. Provision pods before a test and release them after.

  • Already have a Kubernetes cluster and want to reuse it for performance testing.

  • Need to test applications that run inside the cluster and are only accessible from within the cluster network.

Key considerations for Kubernetes deployment:

  • Each load generator pod needs enough CPU and memory to simulate its share of virtual users. Set resource requests and limits based on your test type, whether protocol-based or browser-based.

  • The controller can also run as a pod, or it can run outside the cluster and communicate with load generator pods over the network.

  • Make sure the pods can reach the application under test and that the controller can reach all load generator pods.

  • If you use a Horizontal Pod Autoscaler, configure it based on CPU use so the cluster adds load generator pods as demand grows.

Validate your deployment

After you deploy, run through these checks before you start real tests:

  • Sign in to NeoLoad Web and confirm the interface loads.

  • Verify that controllers and load generators appear as online in your zone.

  • Upload a sample project and run a short test to confirm all components can connect.

  • Check that test results appear in the Results tab.

  • If you use monitoring agents, confirm that server-side metrics appear in the test results.

What's next

Now that your infrastructure is ready, here's where to go: