Benchmarking your (VDI) session

• Measure CPU Performance: Calculate x times the y th power of n. This action will benchmark your CPU performance of a Virtual Machine, VDI, or hosted desktop.
• Measure IO Performance: This function will create x files based on a y size, then you can either read these files or remove them. This action will benchmark your IO performance of a Virtual Machine, VDI, or hosted desktop.
• Gather System Information: This action will send your Virtual Machine, VDI, or hosted desktop system information to the database.

Measure CPU Performance

1. Drag the Measure CPU performance action to your Application Block sequence:
2. Enter the values into the presented form. In the below example we will use the following formula: and we will repeat that 2 times.
3. When running this action in a test, the following information will be stored in the User Action database table:
   1. Username: the username of the test user.
   2. Remote server: the machine name of the endpoint the test is running against.
   3. LoadBot: the name of the LoadGen Agent.
   4. Actual Time: the recorded time when the event occurred.
   5. Relative Time: the recorded time (of the start of the test) when the event occurred.
   6. Iteration: in which iteration cycle this event occurred.
   7. Type: always SubtransactionTimeStop, you can create the chart with this filter.
   8. Message: the command of the CPU measurement calculation, in the above example: 2 x (10 to the 6th power) calculation.
   9. Session Time: the recorded time (of the start of the test of this specific user) when the event occurred.
   10. Subtransaction Name: always CPUMeasurement, you can create the chart with this filter.
   11. Subtransaction Time: the time it has taken to act.

Measure IO Performance

Write files

1. Drag the Measure CPU performance action to your Application Block sequence:
2. Enter the values into the presented form. In the example below we will create 1,000 files with a size of 1,024 KB. These files will be created in the following folder %TEMP%\LoadGen\IOFiles.
3. The File IO Write action will create the files, the LoadGen process will keep a handle open during the test users session, so you can perform the File IO Read action with the same file set which was created in the File IO Write action.
   
4. When running this action in a test, the following information will be stored in the User Action database table:
   1. Username: the username of the test user.
   2. Remote server: the machine name of the endpoint the test is running against.
   3. LoadBot: the name of the LoadGen Agent.
   4. Actual Time: the recorded time when the event occurred.
   5. Relative Time: the recorded time (of the start of the test) when the event occurred.
   6. Iteration: in which iteration cycle this event occurred.
   7. Type: always SubtransactionTimeStop, you can create the chart with this filter.
   8. Message: the command of the File IO measurement calculation, in the above example: 1000 x 1048576 bytes operation.
   9. Session Time: the recorded time (of the start of the test of this specific user) when the event occurred.
   10. Subtransaction Name: always FileIOWrite, you can create the chart with this filter.
   11. Subtransaction Time: the time it has taken to act.

Read files

1. Drag the Measure CPU performance action to your Application Block sequence:
2. Select the File IO Read option. In the example below, we already created 1,000 files with a size of 1,024 KB. These files will be created and read from the following folder %TEMP%\LoadGen\IOFiles.
3. The File IO Write action will create the files, the LoadGen process will keep a handle open during the test users session, so you can perform the File IO Read action with the same file set that was created in the File IO Write action.
   
4. When running this action in a test the following information will be stored in the User Action database table:
   1. Username: the username of the test user.
   2. Remote server: the machine name of the endpoint the test is running against.
   3. LoadBot: the name of the LoadGen Agent.
   4. Actual Time: the recorded time when the event occurred.
   5. Relative Time: the recorded time (of the start of the test) when the event occurred.
   6. Iteration: in which iteration cycle this event occurred.
   7. Type: always SubtransactionTimeStop, you can create the chart with this filter.
   8. Message: the command of the File IO measurement calculation, in the above example: Read operation (1000 x 1048576 bytes).
   9. Session Time: the recorded time (of the start of the test of this specific user) when the event occurred.
   10. Subtransaction Name: always FileIORead, you can create the chart with this filter.
   11. Subtransaction Time: the time it has taken to act.

Delete files

1. Drag the Measure CPU performance action to your Application Block sequence:
2. Select the File IO Delete option. In the example below, we already created 1,000 files with a size of 1,024 KB. These files will be deleted from the following folder %TEMP%\LoadGen\IOFiles.

Gather System Information

1. Drag the Gather System information action to your Application Block sequence:
2. When running this action in a test, the following information will be stored in the User Action database table:
   1. Username: the username of the test user.
   2. Remote server: the machine name of the endpoint the test is running against.
   3. LoadBot: the name of the LoadGen Agent.
   4. Actual Time: the recorded time when the event occurred.
   5. Relative Time: the recorded time (of the start of the test) when the event occurred.
   6. Iteration: in which iteration cycle this event occurred.
   7. Type: always SendMessage.
   8. Message: the result of the system specifications:
      1. Microsoft Corporation - Virtual Machine
      2. CPU #0 - GenuineIntel - Intel64 Family 6 Model 85 Stepping 4 - Cores: 2 - LogicalCores: 4 - ClockSpeed: 2095
      3. Hyper-Threading enabled: Yes
      4. Total Memory: 16GB
      5. Disk #0: Caption: C: - Description: Local Fixed Disk -  Type: Local Disk - Space: 108.73\126.51GB
      6. Disk #1: Caption: D: - Description: Local Fixed Disk -  Type: Local Disk - Space: 30.91\32GB
   9. Session Time: the recorded time (of the start of the test of this specific user) when the event occurred.

OBUX

Traditional benchmarks focus on CPU usage, disk throughput, or frame rates; however, they rarely capture how users actually feel when working in their virtual desktop or application. OBUX (Open Benchmark for User Experience) is an open‑source initiative that fills this gap by combining hard system data with subjective user experience and environmental impact. LoadGen is the official simulation engine powering OBUX, enabling reproducible, vendor‑neutral benchmarks for digital workspaces.

### The vision behind OBUX

OBUX’s goal is to provide a transparent, robust, and vendor‑neutral benchmark that reflects both infrastructure capability and perceived user experience. Each benchmark run evaluates three dimensions:

• System performance – CPU utilisation, memory usage, disk latency, and GPU load.

• User experience – responsiveness, satisfaction, and frustration levels.

• Environmental impact – for example, the energy consumed and associated CO₂ emissions.

These dimensions are combined into a composite score that helps IT leaders make decisions based on both technical metrics and human experience.

How LoadGen powers the OBUX benchmark

To deliver accurate and reproducible benchmark results, OBUX relies on realistic user simulation. LoadGen’s no‑code workload engine allows anyone to build high‑fidelity user scenarios through a visual interface—no scripting required. Typical activities simulated in OBUX workloads include:

• Opening and working with productivity applications such as Outlook, Word, or Excel.

• Navigating enterprise portals and intranet sites.

• Executing transactions in business‑critical systems like CRM, EMR, or ERP applications.

• Launching virtual desktops or remote sessions.

LoadGen sequences these tasks as modular transactions. Each transaction is an atomic unit of user activity—keystrokes, mouse actions, file I/O, UI navigation or response‑time checkpoints—and is timed, logged and scored for responsiveness and stability. Transactions can be orchestrated into complete user journeys and run concurrently across multiple virtual users and environments.

Understanding the OBUX scoring model

OBUX combines objective system metrics with subjective user perception to produce an overall benchmark score. Two dimensions make up the score:

1. System Score (absolute) – derived from hardware and OS‑level metrics such as CPU load, memory utilisation, disk latency, and system response times.

2. User Experience Score (relative) – represents perceived UX on a scale from 0.00 (unacceptable) to 0.94 (perfect), with anchor points at 0.50 (“just fair”), 0.70 (“optimal”).

An example formula used in OBUX is:

Benchmark Score = (number of sessions at fair or better performance) × (UX score + System score)

This ensures that both technical efficiency and subjective quality contribute to the final result. Every benchmark run comprises multiple sessions, each containing repeated transactions. For each transaction, OBUX records:

• Timestamp – compared against expected performance thresholds.

• Duration and jitter – measuring consistency and latency.

• Resource utilisation – CPU, memory, and I/O consumed.

• Environmental impact – energy use converted to CO₂ equivalents.

These measurements feed into the scoring engine to correlate system strain, user perception, and environmental footprint.

Transparency, extensibility, and collaboration

OBUX is designed to be open and reproducible. Benchmark definitions are publicly available; metrics are stored in InfluxDB and visualised with Grafana. The entire test flow can be audited and reproduced. Community contributions via GitHub are encouraged, and the LoadGen engine’s plug‑in architecture allows custom applications or vertical‑specific workloads (for example, healthcare EMRs, financial dashboards, or CAD) to be added.

What’s next

The first public release of the OBUX benchmark is scheduled for late 2024 with launch events at EUCworld and E2EVC. Upcoming initiatives include:

• Free or discounted LoadGen licences for OBUX contributors.

• Pre‑built workload packs for common use cases.

• Enhanced real‑time feedback using AI/LLM‑assisted UX interpretation.

The collaboration between LoadGen and OBUX brings precision engineering together with open benchmarking to help organisations see beyond infrastructure metrics and understand real‑world user experience.