Tutorial: Installation of the LoadGen Core Agent

Updated June 22, 2026 08:30

Tutorial: Installation of the LoadGen Core Agent

With the LoadGen Q1 2022 release, we introduce the LoadGen Core Agent. This LoadGen Core Agent can be installed on Linux and Windows. The LoadGen Core Agent can be used with every VDI / Hosted Desktop technology unless the technology agent supports a command line to launch user sessions.

Linux

To install the LoadGen Core Agent, you must perform the following actions:

Login to your Linux machine.
Start the Terminal.
Check which version of Linux you run with the command lsb_release -a

Ubuntu 20.04

For setting up the LoadGen Core Agent on a system running Ubuntu 20.04, follow these steps:

Set the correct package location (check this article, too: https://docs.microsoft.com/en-us/dotnet/core/install/linux-ubuntu):

wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb

Now install the dotnet runtime:

sudo apt-get update
sudo apt-get install -y apt-transport-https
sudo apt-get update
sudo apt-get install -y dotnet-runtime-8.0

Copy the LoadGen files, we use the /usr/local/bin location to set up the LoadGen Core Agent:

cd /usr/local/bin
sudo mkdir loadgen
sudo chmod a+rwx loadgen
cd loadgen

Start the LoadGen Core Agent with the following command:

dotnet LoadGen.Core.Agent.dll

Ubuntu 22.04 or 24.04

Following the release of .NET Core for Linux, it was initially unavailable in the official Ubuntu repository. Consequently, many users opted to add the Microsoft APT repository to install it. However, .NET Core packages have since been added to the Ubuntu repository, leading to conflicts between the Microsoft and Ubuntu packages. The resolution is simple: you need to choose either Microsoft or Ubuntu packages to avoid mixing. This article will guide you through sticking with the Microsoft packages. We suggest this because Microsoft is likely to provide more frequent updates.

Firstly, clean your system by removing all existing packages related to .NET Core:

sudo apt remove dotnet\*
sudo apt remove aspnetcore\*
sudo apt remove netstandard\*

Next, create a file in /etc/apt/preferences.d. The file name should follow the convention of starting with a two-digit number to ensure a predictable sorting and loading order. For instance, you can name the file 99microsoft-dotnet.pref. The content of this file should be as follows:

echo "Package: \*" | sudo tee /etc/apt/preferences.d/99microsoft-dotnet.pref

echo "Pin: origin \"packages.microsoft.com\"" | sudo tee -a /etc/apt/preferences.d/99microsoft-dotnet.pref

echo "Pin-Priority: 1001" | sudo tee -a /etc/apt/preferences.d/99microsoft-dotnet.pref

After setting your preference for Microsoft packages, update and install .NET Core SDK 6.0:

sudo apt update
sudo apt install dotnet-runtime-8.0

Alternatively, if you prefer to use the official Ubuntu packages, follow the removal step above instead of creating an entry in /etc/apt/preferences.d, remove the Microsoft repository:

sudo rm /etc/apt/sources.list.d/microsoft-prod.list
sudo apt update
sudo apt install dotnet-runtime-8.0

Please note that the Microsoft repository contains other packages, such as PowerShell, SQL Server Command-Line Tools, and more. Removing this repository might not be ideal if you rely on these packages.

Copy the LoadGen files, we use the /usr/local/bin location to set up the LoadGen Core Agent:

cd /usr/local/bin
sudo mkdir loadgen
sudo chmod a+rwx loadgen
sudo chmod -R +x /usr/local/bin/loadgen/.playwright/
cd loadgen

Start the LoadGen Core Agent with the following command:

dotnet LoadGen.Core.Agent.dll

LoadGen Core Agent running as a Service

In addition to its direct running capabilities, the LoadGen Core Agent can be set up to operate as a persistent service on a Linux system. This enables the agent to run continuously in the background, independent of user sessions, and automatically start on boot. This is particularly useful for maintaining long-term, uninterrupted load testing, especially in environments where routine user interaction is not feasible or efficient. The following steps will guide you on how to set up the LoadGen Core Agent as a service on your Linux machine.

It's important to note that, by default, the LoadGen Core Agent uses desktop session 0, as determined by the $DISPLAY environment variable. This is a common setup on many Linux systems, where the first display that's started is assigned the value 0. If you need to target a different display, you can select it explicitly with the display:<n> argument, where <n> is the X display number to use. For example, run dotnet LoadGen.Core.Agent.dll display:1 from the foreground, or add the argument to the ExecStart line of the service file (ExecStart=dotnet /usr/local/bin/loadgen/LoadGen.Core.Agent.dll display:1). See the Command-Line Reference below for the full list of options.

SSH into the Linux machine and copy the files within the LoadGen Core Agent from the LoadGen Director installation path (C:\Program Files\LoadGen\LoadGen Director) to the Linux machine /usr/local/bin/loadgen.
Create a service file into /etc/systemd/system/LoadGen.Core.Agent.service with the following content. Make sure you add the correct user in the file:

[Unit]
Description=LoadGen.Core.Agent
After=network.target
StartLimitIntervalSec=10

[Service]
Type=simple
Restart=always
ResetSec=1
User={User logged in GNOME}
ExecStart=dotnet /usr/local/bin/loadgen/LoadGen.Core.Agent.dll

[Install]
WantedBy=multi-user.target

Enable the service:

sudo systemctl enable LoadGen.Core.Agent

Start the service:

sudo systemctl start LoadGen.Core.Agent

LoadGen Core Agent for WebTesting

LoadGen's WebTesting feature allows users to conduct performance and load testing directly from a user's perspective. Available from Q2-2023, our updated LoadGen Core Agent supports multiple browsers, such as Chrome, Chromium, Microsoft Edge, Firefox, and, from Q3-2023 onwards, even Webkit. This allows you to record, convert, and validate user interactions, including clicks, typing, and other activities within your web applications, bringing you accurate insights into your application's user experience.

Additionally, our Core Agent allows you to effortlessly use variables and data sources to feed data into your Software as a Service (SaaS) applications, helping you to simulate more realistic user interactions. One of the key capabilities of the LoadGen Core Agent is measuring the wait time associated with user actions, a critical metric when gauging user experience and overall application performance.

However, please take note of the $DISPLAY environment variable when setting up the LoadGen Core Agent. By default, LoadGen uses desktop session 0. If you need to target a different display, pass the display:<n> argument to the agent (for example, display:1) to select the X display number to use. If your environment doesn't permit using a display at all, there's no need to worry. You still have the option to adjust your load test profile and enable headless mode. Headless mode allows your tests to run without a display environment, making it a practical solution when working in non-interactive session conditions or when display access is restricted.

Before we dive into the specifics of setting up LoadGen Core Agent for WebTesting, it's worth mentioning the importance of having a solid network infrastructure. The LoadGen test infrastructure components, including the LoadGen Director and LoadGen Core Agents, require seamless network communication to perform optimally. In cases where these components are set up across different networks, a Site-to-Site VPN might be required to ensure secure communication. Read more about network traffic here.

One of the key components of WebTesting using LoadGen Core Agent is its ability to streamline the testing process by enabling you to make certain preparations before running your first test. For instance, you can save time by pre-emptively preparing the WebTesting feature for your Linux environment. This can be done by running the following command:

dotnet LoadGen.Core.WebRecorder.dll "00000000-0000-0000-0000-000000000000"
sudo chmod -R +x /usr/local/bin/loadgen/.playwright/

This command primes the LoadGen Core Agent for WebTesting and ensures that when you run your first test, you won't encounter any unnecessary delays. Press CTRL-C to stop the LoadGen.Core.WebRecorder.

Another benefit of LoadGen Core Agent is its support for the Microsoft Edge browser on Linux environments. You can install Microsoft Edge directly within the directory where the LoadGen Core Agent is stored, typically /usr/local/bin/loadgen, by executing the following command:

.playwright/node/linux-x64/playwright.sh install msedge

This command facilitates the installation of Microsoft Edge in your Linux environment, offering greater flexibility and testing options. Once you've successfully installed Microsoft Edge, it's critical to manually launch the browser and complete all initial setup steps before initiating a test. This ensures that any introductory prompts or configurations are properly addressed, allowing your tests to run smoothly.

Once you've successfully installed the necessary browsers and prepped the WebTesting feature, you can start the LoadGen Core Agent by executing the following command:

dotnet LoadGen.Core.Agent.dll

Updating the LoadGen Core Agent

Updating the LoadGen Core Agent on Linux is simple. First, copy the latest version of the Core Agent files from your local machine to the target Linux system using a secure file transfer tool such as SCP (Secure Copy Protocol). Once the files are transferred, connect to the Linux machine using SSH. Navigate to the directory where you placed the new files and ensure the permissions are correct. Then, stop the current LoadGen Core Agent process (if it's running), and start the updated version:

dotnet LoadGen.Core.WebRecorder.dll "00000000-0000-0000-0000-000000000000"
sudo chmod -R +x /usr/local/bin/loadgen/.playwright/

Once you've successfully prepped the WebTesting feature, you can start the LoadGen Core Agent by executing the following command:

dotnet LoadGen.Core.Agent.dll

Installing Google Chrome on Ubuntu - NO ARM

The following instructions will guide you through installing Google Chrome on your Ubuntu machine. Please note that Chrome is not built for ARM processors, so if you want to run LoadGen WebTesting on a Raspberry Pi, for example, use Chromium:

sudo apt install chromium-browser

Start by opening the Terminal application. You can easily find this by searching for "Terminal" in Ubuntu's application launcher or pressing Ctrl + Alt + T to launch it.
Next, you need to download the installation file for Google Chrome. Execute the following wget command in Terminal, which will fetch the latest version of Google Chrome:

wget https://dl.google.com/linux/direct/google-chrome-stable\_current\_amd64.deb

Once the download is complete, proceed to install Google Chrome using the dpkg command as shown below:

sudo dpkg -i google-chrome-stable\_current\_amd64.deb

Should you come across an error indicating that there are missing dependency packages, resolve this by running:

sudo apt-get install -f

At this point, Google Chrome should be successfully installed on your system. You can open it either by entering google-chrome-stable in the Terminal or by clicking the Google Chrome icon, which can be found in Ubuntu's application launcher.

Running a Web Test from SSH Terminal

During the execution of a web test from a Secure Shell (SSH) terminal session, you might encounter the following error:

Looks like you launched a headed browser without having an XServer running.

This error typically arises when you attempt to run a graphical user interface (GUI) based browser without an active XServer, which is required to render the GUI on Linux systems. While it is possible to run a web test from an SSH session, the "Headless browsing" option must be enabled in the LoadGen Director to bypass the need for an XServer. This option enables the browser to run in a headless environment, essentially without a visible GUI, minimizing the overhead associated with a full-fledged desktop session.

Here's how to enable headless browsing:

Launch the LoadGen Director.
Open your active canvas.
Proceed to the tab page Target Environment.
Choose Headless browsing.

Once you've enabled headless browsing, the web tests should execute smoothly from your SSH terminal. If you want to verify the progress of your tests, you can enable the "Send screenshot to database" option from the LoadGen Studio. This feature captures screenshots at specified points during the test, providing a visual reference to assess if the test is proceeding as expected.

Resolving System.IO.IOException in LoadGen Core Agent on Linux

In some cases, while running the LoadGen Core Agent on Linux systems, you might encounter an error similar to this:

Unhandled exception. System.IO.IOException: The configured user limit (128) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached.

This error indicates that the maximum user limit for inotify instances, or the per-process limit for open file descriptors, has been reached. Inotify is a Linux mechanism for monitoring changes to the filesystem, and each inotify instance consumes system resources.

To resolve this issue, you can increase the limit of inotify instances. Here's how to do it:

Open your Linux terminal.
Switch to the root user by entering the following command:

sudo -i

Then, add a new limit for the maximum user instances of inotify by entering:

echo fs.inotify.max*user*instances=524288 >> /etc/sysctl.conf

This command writes the line fs.inotify.maxuserinstances=524288 at the end of the sysctl.conf file, which sets the maximum user instances of inotify to 524288.

Type exit to break out the root user context.

By increasing this limit, you can run the LoadGen Core Agent without encountering the error.

Resolving System.Net.Sockets.SocketException in LoadGen Core Agent on Linux

During the operation of the LoadGen Core Agent on Linux systems, you might encounter the following error:

Error while delegating packet to subscribers.System.Net.Sockets.SocketException (107): Transport endpoint is not connected

This error usually arises due to a mismatch in the time zone configuration between the LoadGen Director, which initiates the test, and the Linux LoadGen Core Agent. A discrepancy in time zones can lead to communication issues between the different components of the LoadGen infrastructure.

A straightforward solution to this issue is to align the time zones on all systems involved in the test. Here's how to adjust the timezone on your Linux machine using the timedatectl command:

Open your Linux terminal.
Check the current system's timezone by running the following command:

timedatectl

To find out the full name of the timezone, use the command:

timedatectl list-timezones

The naming convention for time zones usually follows the Region/City format. You can narrow down the timezone list by combining the timedatectl command with the grep command to filter the search using the name of a city, like so:

timedatectl list-timezones | grep Paris

Press CTRL + C to exit the list.
Once you've identified the correct timezone, update your system's timezone with the following command:

sudo timedatectl set-timezone [timezone]

Replace [timezone] with the name of your desired timezone.

To verify that the timezone has been updated successfully, run:

timedatectl

The output should reflect the new local time and timezone. By ensuring the timezones across your LoadGen infrastructure align, you can run the LoadGen Core Agent without encountering the 107 error.

Resolving System.Security.Cryptography.CryptographicException in LoadGen Core Agent on Linux

If you encounter a System.Security.Cryptography.CryptographicException error in the LoadGen Core Agent on Linux may be due to a corrupted cache file. To resolve this issue, follow these steps:

Open a terminal and locate the cache file by running:

find / -name Core-msalcache.bin
find / -name credentials.bin

Remove the identified file using the rm command:

rm /path/to/Core-msalcache.bin
rm /path/to/credentials.bin

Restart the LoadGen Core Agent to apply the changes.

This should resolve the error and allow the Core Agent to function correctly.

Resolving Permission Denied Error

If you encounter the error:

One or more errors occurred. (An error occurred trying to start process '/usr/local/bin/loadgen/.playwright/node/linux-x64/node' with working directory '/usr/local/bin/loadgen'. Permission denied)

This error typically indicates that the node executable in the specified directory doesn't have the proper execution permissions. To resolve it, ensure the file is executable by running:

chmod +x /usr/local/bin/loadgen/.playwright/node/linux-x64/node

Also, verify that your user account has sufficient rights to access and execute files in that directory—if necessary, you might need to run the command with elevated privileges (e.g., using sudo). These steps should help address the permission issue and allow the process to start as expected.

Resolving FATAL ERROR: ENOENT: no such file or directory

When encountering the error message:

FATAL ERROR: ENOENT: no such file or directory, mkdtemp 'C:\UsersUSERNAME%\AppData\Local\Temp\2\playwright-artifacts-XXXXXXXXXXXX'

It indicates that the system is attempting to create a temporary directory for Playwright artifacts but cannot find the specified path.

Verify the Existence of the Directory Path: Ensure that the directory C:\Users\%USERNAME%\AppData\Local\Temp\2 exists.
If it does not exist, manually create the missing folders.
Permissions: Verify that your user account has the permissions to create directories and files within the Temp directory.

By ensuring that the full path C:\Users\%USERNAME%\AppData\Local\Temp\2 exists and is accessible, you can resolve the ENOENT error and allow Playwright to create the necessary temporary directories for its operations.

Windows

To install the LoadGen Core Agent, you must perform the following actions:

Install the dotnet runtime 8.0 client (https://docs.microsoft.com/en-us/dotnet/core/install/windows?tabs=net80).
Login into the Windows machine and copy the files within the LoadGen Core Agent from the LoadGen Director installation path (C:\Program Files\LoadGen\LoadGen Director) to the Windows machine C:\Program Files\LoadGen\LoadGen Core Agent.
Make sure you auto-login on the Windows machine (https://docs.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/turn-on-automatic-logon).
Make sure you auto-start the LoadGen.Core.Agent.exe (https://support.microsoft.com/en-us/windows/add-an-app-to-run-automatically-at-startup-in-windows-10-150da165-dcd9-7230-517b-cf3c295d89dd).
If you start the LoadGen Core Agent manually, make sure to run the command or PowerShell with Elevated rights.

Tip: For headless web testing you can install the agent as a native Windows Service instead of relying on auto-login and auto-start. From an elevated prompt, run LoadGen.Core.Agent.exe --install to register and enable the service, then --start / --stop to control it and --uninstall to remove it. See the Command-Line Reference below for the full list of switches. Note that a service runs web tests in headless mode only, so keep the auto-login plus auto-start setup if you need headed (visible) browser sessions.

LoadGen Core Agent for WebTesting

Note: If you start the LoadGen Core Agent manually, make sure to run the command or PowerShell with Elevated rights.

One of the key components of WebTesting using LoadGen Core Agent is its ability to streamline the testing process by enabling you to make specific preparations before running your first test. For instance, you can save time by pre-emptively preparing the WebTesting feature for your Windows environment. This can be done by running the following command:

dotnet LoadGen.Core.WebRecorder.dll "00000000-0000-0000-0000-000000000000"

This command primes the LoadGen Core Agent for WebTesting and ensures that you won't encounter any unnecessary delays when you run your first test.

Once you've successfully installed the necessary browsers (make sure you install Google Chrome if you want to run a test with Chrome as the preferred browser) and prepped the WebTesting feature, you can start the LoadGen Core Agent by executing the following command:

LoadGen.Core.Agent.exe

Using a Proxy for the LoadGen WebRecorder

In specific environments, internet access is only available through a proxy server. If you're using the LoadGen Core WebRecorder and experience issues with downloading components or initializing correctly, you may need to explicitly set the proxy settings before launching the recorder.

You can do this by opening a Command Prompt (CMD) and setting the HTTPS_PROXY environment variable before executing the WebRecorder command:

set HTTPS\_PROXY=http://proxy.test:8080
cd /d "C:\Program Files\LoadGen\LoadGen Core Agent"
LoadGen.Core.WebRecorder.exe "00000000-0000-0000-0000-000000000000"

Adjust the proxy address as needed. After setting the proxy variable and running the WebRecorder this way, downloads should proceed correctly. In our test scenario, both LoadGen Studio and LoadGen Director operated as expected once the proxy was configured this way.

Microsoft Edge

Once you've successfully installed Microsoft Edge, it's critical to manually launch the browser and complete all initial setup steps before initiating a test. This ensures that any introductory prompts or configurations are properly addressed, allowing your tests to run smoothly.

Google Chrome and Firefox

In addition to Microsoft Edge, LoadGen supports testing on Google Chrome and Firefox. If you intend to use either of these browsers for your testing process, ensure they are manually installed on your system before running tests. This manual installation step is a necessary prerequisite for the accurate and seamless operation of LoadGen's testing capabilities.

Raspberry Pi (ARM)

When installing LoadGen Core Agent and running LoadGen WebTesting you will need to install the additional packages:

apt-get update && apt-get install -y \
libglib2.0-0 \
libnss3 \
libnspr4 \
libdbus-1-3 \
libatk1.0-0 \
libatk-bridge2.0-0 \
libcups2 \
libdrm2 \
libxcb1 \
libxkbcommon0 \
libatspi2.0-0 \
libx11-6 \
libxcomposite1 \
libxdamage1 \
libxext6 \
libxfixes3 \
libxrandr2 \
libgbm1 \
libpango-1.0-0 \
libcairo2 \
libasound2t64

Command-Line Reference

Both the LoadGen Core Agent and the LoadGen Core WebRecorder accept command-line switches that control how they run and where they keep their browsers. You can display the full list at any time by passing --help (or --?) to either executable. On Linux, substitute dotnet LoadGen.Core.Agent.dll for LoadGen.Core.Agent.exe, and dotnet LoadGen.Core.WebRecorder.dll for LoadGen.Core.WebRecorder.exe.

LoadGen Core Agent command-line options

Run LoadGen.Core.Agent.exe --? to display the help text:

LoadGen Core Agent

Usage: LoadGen.Core.Agent [command]

Run modes:
  (no command)     Run in the foreground as a console application.
  --service        Run hosted as a background service (used by the service manager).

Service management (require elevated/Administrator/root privileges):
  --install        Install and enable the agent as a service that starts on boot.
  --uninstall      Stop (if running) and remove the service.
  --start          Start the installed service.
  --stop           Stop the installed service.

Other:
  --help, --?      Show this help text.
  display:<n>      (Linux) Set the X display number to use.

Detected service host:
  Windows  - installs as a Windows Service via sc.exe / the Service Control Manager.

Note: when running as a service, only web tests are supported and they always run
      in headless mode (a service has no interactive desktop to display a browser).

Run modes:

(no command) runs the agent in the foreground as a console application. This is the mode used in the examples earlier in this article and is convenient for first-time setup and troubleshooting, because all output is visible in the terminal.
--service runs the agent hosted as a background service. You normally do not call this switch yourself, the service manager uses it after the service is installed.

Service management (these require elevated, Administrator, or root privileges):

--install installs and enables the agent as a service that starts automatically on boot.
--uninstall stops the service (if it is running) and removes it.
--start starts the installed service.
--stop stops the installed service.

Other:

--help, --? shows the help text.
display: (Linux only) sets the X display number the agent uses, for example display:0. This lets you target a specific desktop session rather than relying solely on the $DISPLAY environment variable described in the WebTesting sections above.

On Windows, the agent installs as a Windows Service through sc.exe and the Service Control Manager. This native service install is an alternative to the auto-login plus auto-start approach described in the Windows section, and it keeps the agent running independently of an interactive logon.

Note: When running as a service, only web tests are supported and they always run in headless mode, because a service has no interactive desktop on which to display a browser. If you need headed (visible) browser sessions, run the agent in the foreground under an auto-logged-in user instead.

LoadGen Core WebRecorder command-line options

The LoadGen Core WebRecorder is responsible for provisioning the browsers (Playwright) that WebTesting uses. Run LoadGen.Core.WebRecorder.exe --? to display the help text:

LoadGen Core WebRecorder

Usage: LoadGen.Core.WebRecorder <command>

Browser provisioning commands:
  --install                       Install browsers to the current path.
  --install <path>                Install browsers to <path> and remember it.
  --install <path> --no-remember  Install browsers to <path> without remembering it.
  --set-path <path>               Remember <path> as the browsers location (no install).
  --current-path                  Show the current browsers path and its source.
  --clear-path                    Forget the custom path; revert to the default below.
                                  (alias: --reset-path)
  --help, --?                     Show this help text.

  <path> is a directory and is written the same way for every command.

  Default path: C:\Program Files\LoadGen\ms-playwright
  Current path: C:\Program Files\LoadGen\ms-playwright

Browser provisioning commands:

--install installs the browsers to the current path.
--install installs the browsers to <path> and remembers that location for future runs.
--install --no-remember installs the browsers to <path> for this run only, without saving it as the remembered location.
--set-path remembers <path> as the browsers location without installing anything. Use this when the browsers already exist at that path.
--current-path shows the browsers path that is currently in effect and the source of that setting.
--clear-path (alias --reset-path) forgets a custom path and reverts to the default location.
--help, --? shows the help text.

<path> is a directory and is written the same way for every command.

By default, browsers are installed under C:\Program Files\LoadGen\ms-playwright. Run --current-path to confirm which location is active before a test, and use --set-path or --install <path> when you want the browsers stored somewhere other than the default, for example on a larger volume or a shared path.

Slotcount and SessionStreams

In the context of the LoadGen Director, the terms "Slot Count" and "Session Streams" are crucial to understanding as they determine how the system manages the load testing process:

Slot Count: This refers to the total number of concurrent sessions the LoadGen Core Agent can handle. This essentially means the total number of virtual users that can be active and interact with the tested environment simultaneously. It's a representation of the maximum load or capacity that your system is tested for.
Session Streams: This number indicates how many concurrent sessions the LoadGen Core Agent can start simultaneously. Rather than starting all the sessions at once, LoadGen starts them in groups or 'streams' to avoid overloading the system at the start of the test and to simulate more realistic usage patterns. This can be particularly useful in scenarios where you want to ramp up the load gradually or if your system has limitations on the number of new sessions it can handle per unit of time.

Adjusting these values allows you to fine-tune how the LoadGen Core Agent performs load testing. This ensures that the tests accurately simulate the desired usage conditions and do not exceed your system's capabilities.

In LoadGen Director, it's possible to adjust the slot count and session streams for the LoadGen Core Agent directly in the XML configuration file. Follow the steps below to successfully make these changes:

Close the LoadGen Director. It is crucial that the LoadGen Director is not running while you are making changes to the XML file.
Open the XML file. Navigate to %ProgramData%\LoadGen\Director\ and open LoadGenLoadBots.xml file in a text editor of your choice.
Edit the values. Within this file, locate the and tags; these can be adjusted for each LoadGen Core Agent. Change the numerical values between these tags to your desired numbers. For example, if you want to set the slot count to 250 and the session streams to 2, your XML should look like this:

250
2

Save and close the XML file. After adjusting these values, save your changes and close the file.
Start the LoadGen Director. Start the LoadGen Director again to ensure that your changes take effect.

Following these steps, you can adjust the slot count and session streams for the LoadGen Core Agent as per your requirements.