• 1: Product Overview
• 1.1: Technical Product Features
• 2: Getting Started
• 2.1: Deployment Types & Architecture
• 2.2: Portal Sign Up and Login
• 2.3: Execute a Simple HTTP/S Test
• 2.4: Convert a Selenium IDE Test to a RealLoad Test
• 3: Release Notes
• 4: User Guide
• 4.1: AWS Measuring Agents
• 4.2: Azure Measuring Agents
• 4.3: Measuring Agent Cluster
• 4.4: Recording of a Web Surfing Session
• 4.5: HTTP Test Wizard
• 4.6: HTTP/S Remote Proxy Recorder
• 5: Synthetic Monitoring
• 6: System Monitoring
• 7: Regression Testing
• 8: Web Browser Recorder Extensions for both Chrome and Firefox
• 9: Desktop Companion
• 9.1: Desktop Companion - Pre-requisites
• 9.2: Desktop Companion - Settings Menu
• 9.3: Desktop Companion - Monitoring
• 9.4: Desktop Companion - File Menu
• 9.5: Desktop Companion - Project Explorer
• 9.6: Desktop Companion - Editor
• 9.7: Desktop Companion - Proxy Recorder
• 9.8: Desktop Companion - AWS Measuring Agents
• 9.9: Release Notes
• 10: Mobile Companion App
• 11: Table Server
• 12: OSHI Daemon
• 13: API
• 13.1: Public API
• 13.2: Remote Admin API
• 13.3: Remote User API
• 13.4: Remote User Monitoring API
• 14: Developer Guide
• 14.1: Developing a JUnit Monitoring Test
• 15: Installation
• 15.1: Ubuntu: Measuring Agent manual install
• 15.2: Ubuntu: Measuring Agent Controller manual install
• 15.3: Ubuntu: Cluster Controller manual install
• 15.4: Ubuntu: Remote Proxy Recorder manual install
• 15.5: Ubuntu: Alert Processor manual install
• 15.6: Ubuntu: OSHI Daemon manual install
• 15.7: Windows: OSHI Daemon installation
• 15.8: Ubuntu: JavaScript Processor manual install
• 15.9: Ubuntu: Portal Server manual install

1 - Product Overview

What is RealLoad?

RealLoad is an Enterprise Tool to perform next generation Load Testing, Regression Testing, and Synthetic Monitoring.

The product architecture is designed for high-performance load testing, with these capabilities also available for synthetic monitoring and regression testing.

The user interface is optimized for maximum comfort, so that most - even complex - functionalities can be carried out with just a few mouse clicks and powerful forms.

Doe to RealLoad’s powerful features you can save a lot of time and money when creating, executing and evaluating professional tests. Including a shorter training period compared to other products.

If you want to program a RealLoad test manually, this also supported and fully documented in the Developer’s Guide.

RealLoad is ready to use out of the box - you can use it immediately and try it for free by Sign Up at the RealLoad Portal.

Due to the universal product architecture, a Test of any Type supported by RealLoad can be executed as:

• Load Test
• Regression Test
• Synthetic Monitoring Job

The following Types of Tests are supported:

• ‘HTTP Test Wizard’ Tests - Web Surfing Sessions and HTTP API Tests.
• JUnit Tests - Testing any type of Network Protocol (such as DNS, SMTP or UDP).
• Selenium IDE and Playwright Tests - Execution of Real Web Browser Tests.

Regardless of what type of test you are running, all measured data are displayed directly in real time in form of statistics and charts.

All work steps can be carried out within the web interface of the RealLoad Portal which:

• contains simple and powerful dialogs.
• contains numerous wizards, so no programming is required in most cases.
• does not require to configure any JSON and XML files.

In addition, using RealLoad offers many other advantages, for example:

• Web surfing sessions can be recorded with a ready-for-use cloud-based HTTP/S Proxy Recorder and post-edited with a powerful wizard.
• JUnit tests can measure Additional Statistics and Charts, declared on the fly.
• Selenium IDE tests can be converted into RealLoad tests using a wizard.
• A powerful graphical Test Suite Editor supports the compilation of Regression Tests.
• The Synthetic Monitoring Dashboard gives you a complete overview of the last 24 hours by displaying real-time sparklines (micro charts) per each monitoring job.
• Multiple Measuring Agents (load generators) can be combined into a cluster, with the test results of the cluster members are combined into a single test result - displayed in real time - for all types of tests.

Complete Overview of All Product Features

1.1 - Technical Product Features

Image Title

Universal ‘RealLoad Tests’

‘RealLoad Tests’ are universal, abstract tests which can created from any type of test. All types of tests can be executed as:

• Load Test
• Regression Test
• and as Synthetic Monitoring Job

Creating a ‘RealLoad Test’ is usually easy and supported by wizards and powerful dialogs.

Types of Tests

The following Types of Tests are supported:

• ‘HTTP Test Wizard’ Tests - Web Surfing Sessions and API Tests
  • HTTP Test Wizard’s tests simulate only the network traffic from an HTTP client to HTTP servers - without running a web browser’s rendering engine. This allows extremely efficient testing of the web servers.
  • Web Sessions can be either created manually - by entering URL HTTPS GET/POST… requests - or by recording a Web Browser Surfing Session using a RealLoad HTTP/S Proxy Recorder.
  • No Programming Required - All functionalities can be carried out using powerful dialogs with just a few mouse clicks and form entries.
  • Support of handling dynamically exchanged Session Variables using a wizard and by editing the session in the Remote Debugger.
  • Support of HTTP response verification
  • Support of Session Cookies
  • Support of PKCS12 Client Certificates
  • Support of parallel executed HTTP requests
  • Support of User Input Fields
  • Support of Input Files (from which variables can be extracted)
  • Support of Conditional Jumps to Session Elements (conditional GoTo)
  • Support of ‘HTTP Test Wizard’ Plug-Ins which are invoked during test execution
  • Support of multiple client TCP/IP addresses during test execution (requires special OS configuration on Measuring Agents)
  • Can be debugged using a powerful Remote Debugger
  • The ‘HTTP Test Wizard’ generates powerful, performance optimized code that does not need to be edited manually. Depending on the hardware resources of a load generator (Measuring Agent), up to 5000 virtual users can be executed in parallel per load generator. In addition, by combining multiple load generators into a cluster, an almost unlimited load can be achieved.
  

  HTTP Test Wizard DocRecording a Web Surfing Session Doc

• ‘RealLoad’ JUnit Tests - Testing any type of network protocol
  • ‘RealLoad’ JUnit Tests can be converted from any JAR file which contains original JUnit Tests by using a wizard, or can be written from scratch.
  • Due to the generic nature of JUnit tests, any type of network protocol can be tested while taking full advantage of the RealLoad infrastructure (e.g. running as load tests, part of a regression test, and executed as monitoring job).
  • Additional Features of RealLoad JUnit Tests written from scratch:
    • Support of User Input Fields
    • Support of Additional Measured Statistics and Charts, declared on the fly inside the JUnit test (in addition to the @Test execution time).
  

  RealLoad JUnit Tests Doc

• ‘RealLoad’ Selenium IDE and Playwright Tests - Execution of Real Web Browser Tests
  • ‘RealLoad’ Selenium IDE Test can be converted from any exported Selenium IDE Test by using a wizard, or can be written from scratch.
  • Support of Firefox and Google Chrome browser.
  • Support of User Input Fields.
  • The executed tests take a final screenshot of the simulated web browser at the end of each surfing session.
  • The tests can take full advantage of the RealLoad infrastructure (e.g. running as load tests, part of a regression test, and executed as monitoring job). However, due to the high CPU load when executing such tests, only a few simulated users can run per load generator at the same time (typically 5 to 50).
  
  RealLoad Selenium IDE Tests Doc

Load Tests

• Support of all types of ‘RealLoad Tests’.
• All measured data (and errors) are displayed in real-time during test execution.
• Support Clusters of Load Generators with up to several hundred cluster members (Measuring Agents). This enables you to execute load tests with an almost unlimited strength of load, with more than 1,000,000 concurrent VUs, for ‘HTTP Test Wizard’ Tests and for JUnit Tests.
• Cluster Features:
  • Assembling a cluster of load generators is easy and can be done with just a few mouse clicks.
  • The content of Input Files can be split among the cluster members.
  • The real-time view of the measured data is also available at cluster level.
  • The test results of the cluster members are combined into a single test result.

Regression Tests

• Support of all types of ‘RealLoad Tests’.
• With a powerful Graphical Editor you can create and edit Test Suites and their tests with just a few mouse clicks and form entries.
• All tests of a Test Suite support to be executed with multiple of concurrent users (same as load tests).
• The tests of a Test Suite are grouped into “Execution Groups”, where the Execution Groups can be executed in sequential or parallel order.
• The progress of a Test Suite “run” can be viewed in real-time.
• The results of the Test Suite “runs” are archived and can be compared with each other.
• A “run” of a Test Suite can be triggered either interactively or via an API.

Synthetic Monitoring

• Support of all types of ‘RealLoad Tests’.
• Multiple “Monitoring Groups” can be defined, each containing multiple “Monitoring Jobs”.
• Each “Monitoring Job” references an (abstract) ‘RealLoad Test’, whereby the same properties as for a Load Test Job can be configured per “Monitoring Job”, i.e. the number of executed virtual users.
• Multiple “Measuring Agents” can be configured per “Monitoring Group” which means that the corresponding “Monitoring Jobs” are executed from multiple geographical locations. The measurement results of the Measuring Agents are combined into a single result, whereby the individual result of each Measuring Agent is still available.
• The Real Time Dashboard displays the status of all Monitoring Groups and Jobs, and displays also real time sparklines (micro charts) per Monitoring Job about the availability and the response times of the last 24 hours.
• Statistics about the availability and performance of the Monitoring Groups and Jobs can be displayed in a freely selectable time period, and can be exported to a PDF and MS Word document. This also allows you to check whether the requirements of an SLA (Service Level Agreement) have been met.
• Detailed historical data for each individual test execution of a Monitoring Job can be displayed.
• Support for Multiple Alert Groups that refer to Alert Devices - which can be configured differently depending on the type of alert.
• Supported Alert Devices: Email, Mobile Companion App (installed on a mobile phone), SMS and Webhooks (RealLoad native, Pagerduty and Slack).
• In addition to release Alert Notifications about measured warnings and errors, an alert can also be triggered if the Performance of a Monitoring Job is poor.
• Support for Delayed Alert Notifications: Alert notifications can be triggered immediately or only after one or several repeats.
• A fully documented API enables developers to implement their own version of a Synthetic Monitoring “Real Time Dashboard”.

RealLoad Portal - Features and Licenses

• Fully integrated functionalities. All work steps can be carried out within the portal.
• Simple and powerful dialogs. All functions can be carried out via the web user interface. And all of this without the need to configure any JSON and XML files.
• Multiple team member accounts can be created per main user account, although certain team members can only have read rights.
• After Sign Up to the portal, a remote HTTP/S Proxy Recorder and two shared Measuring Agents (load generators with limited capacity) are immediately available to you for free. In addition you will get 20 free ‘Cloud Credits’.
• Additional Measuring Agents (load generators), Cluster Controllers and Remote Proxy Recorders that are needed for a short time can be easily started via the portal in the AWS cloud by using of ‘RealLoad Cloud Credits’. The advantage of using ‘Cloud Credits’ is that you do not have any cost risk from forgetting to terminate the instances, and that you don’t need an own AWS account. Depending of your license, you can also start additional (private) Measuring Agents under your own AWS account, by using our Desktop Companion App, or by sign in directly into the AWS console.
• According to your license, you can also operate private Measuring Agents, Cluster Controllers and Remote Proxy Recorders yourself or have us operate them. You can register such components directly in the portal in your account.
• Powerful API with over 70 functions. Such as creating new projects, uploading and downloading files, starting load test jobs and downloading their results, starting regression tests and downloading their results, implementing your own synthetic monitoring dashboard.

RealLoad Core Components

All core components are independent OS processes that can be executed on Linux and Windows:

• Portal Server
• Measuring Agent ¹ - Execution of tests.
• Cluster Controller ¹ - Combines multiple Measuring Agents to a cluster.
• Remote HTTP/S Proxy Recorder ¹ - Recording of HTTP/S web surfing sessions.
• Table Server - Stores values of (previous) tests, which can be used as input for next tests.

¹ = Available as public AWS/EC2 image

RealLoad Apps

Using locally installed RealLoad applications is optional, but can be quite useful:

• Desktop Companion - can be installed on Mac OS X and Windows
  • Generate HTTP Load Test scripts from HTTP archives (.har) files.
  • Locally run the RealLoad HTTP/S Proxy Recorder (local recording of HTTP Test Wizard ‘Tests’).
  • Perform some basic editing of test scripts.
  • Upload test scripts directly to the RealLoad Portal.
  • Manage AWS Measuring Agents by using your own AWS account (launch, terminate, register with RealLoad Portal).

  Desktop Companion Doc

• Mobile Companion - can be installed on Android and iOS mobile phones
  • Displays a simplified real-time view of the Synthetic Monitoring Dashboard.
  • The mobile phone can be used as a Synthetic Monitoring Alert Device. You will receive instant push notifications when a monitoring job detects an error or warning - and when this issue have been resolved.

  Mobile Companion Doc

RealLoad Web Browser Extensions

The use of RealLoad web browser extensions is optional, but allows you to conveniently control the recording of a web surfing session in combination with a Remote HTTP/S Proxy Recorder.

• Browser Extensions are available for Firefox and Google Chrome.

Web Browser Extensions Doc

2 - Getting Started

This section of the documentation will walk you through the first steps in order to getting started with the RealLoad Product.

Follow the next sections of the document and you should be able to run your first basic test script using the SaaS Evaluation scenario within 20 minutes.

Let us know if encounter any issues while getting started, as that will help us updating this documentation to make it as clear and user friendly as possible. Please email us at support@realload.com

2.1 - Deployment Types & Architecture

First of all you’ll have to decide which RealLoad deployment type better suits your needs. These guidelines should assist you in making an informed decision.

Architecture

There a few components that make up the RealLoad solution. Most components are available under an SaaS model which doesn’t require any infrastructure commitment from your side.

If required by security or other constraints, some or all components can be deployed on your own infrastructure. Please reach out to us to discuss requirements if you’re planning to go down this road.

The key components that make up RealLoad’s solution are:

The Portal Server

• Exposes the main GUI to end users.
• All tasks to maintain Load Testing or Synthetic Monitoring scripts are performed here.
• Load Tests are can be triggered via the Portal.
• The Synthetic Monitoring dashboard is visible here and shows the current state of configured tests.

Measuring Agent

• Load Test and Synthetic Monitoring scripts are executed from Measuring Agents.
• For Synthetic Monitoring purposes, you can use shared or dedicated agents to execute your tests from.
• The Measuring Agent needs to be reachable from RealLoad’s portal server and needs to be able to reach the servers to be load tested or monitored.
• You can have multiple Measuring Agents, for example to execute Synthetic Monitoring tests from different locations.

Cluster Controller (Optional)

• If your Load Testing requirements exceed the load generating capacity of a single Measuring Agent, you can combine multiple agents in a cluster using a Cluster Controller.
• Like measuring agents, Cluster Controllers can be hosted in the cloud or on your own infrastructure, as per your requirements.

Proxy Recorder (Optional)

• You can use the Proxy Recorder component in order to develop test scripts by recording HTTP traffic while it transits through it.
• The Proxy Recorder can be run in the cloud, as a service on your own infrastructure or directly on your Desktop using the Desktop Companion.

Typical deployment scenarios

Load Testing using Cloud Credits

The RealLoad portal gives you the ability to launch load generators (Measuring Agents) in the AWS cloud with a click of button and the execute a load test.

• Cloud Credits can be purchased in the RealLoad shop, at this link: https://shop.realload.com/cloud-credits-2  
• The cost charged by RealLoad to run Measuring Agents using Cloud Credits varies by AWS EC2 instance type. See this table for details: https://shop.realload.com/cloud-credits  

Load Testing by running the Measuring Agent behind perimeter firewall

Using Cloud Credits is not an option if the servers to be performance tested are not exposed to the internet. In this scenario, the Measuring Agent will need to be deployed behind perimeter firewalls as follows:

• In AWS: You can launch our pre-configured AMIs under your AWS account and attach them to your VPCs.
• If preferred, Measuring Agent instances can be launched using our convenient Desktop Companion application.
• If running on non-AWS infrastructure: Install the Measuring Agent on a supported Linux Distribution.

• See our online shop for pricing of commonly used license sizes. Reach out to us if you have different licensing requirements. https://shop.realload.com/load-test-licenses  

Synthetic Monitoring of Internet exposed services

Typically Synthetic monitoring is use to monitor services that are exposed to the internet. RealLoad uses Measuring Agents to implement the monitoring functionality.

We recommend executing Synthetic Monitoring tests from at least 2 Measuring Agents, to cater for transitory local disruptions (like network issues or agent software updates) which might trigger false positive alerts.

There are two types of agents you can use for monitoring purposes:

• Shared Agents: These are Monitoring Agents shared by multiple customers. Using these agents is included in the basic cost of the monitoring service.
• Dedicated Agents: If you need to execute monitoring from a specific location or you don’t want to use a shared agent, we can setup a dedicated agent for you. This will incur additional costs, plz reach out to us to discuss.

Synthetic Monitoring of services running behind perimeters firewalls

Should you have the need to monitor services within your perimeter, this can be arranged by deploying Measuring Agents within your networks.

2.2 - Portal Sign Up and Login

If you already have an account, you can login at https://portal.realload.com  

Signing Up - Free Account Features

In order to login to the portal you’ll first have to setup an account. Go to the portal URL and click on the Sign Up button or go this URL: https://portal.realload.com/SignUp  

You’ll need to provide:

• Email address.
• Mobile phone number.
• No credit card required, it’s completely free.

Sign Up Process

Step 1 of 4

Provide your details, including email and mobile number. All data you enter in this form are only required to verify your identity and will not be shared with any third parties.

Step 2 of 4

Validate your email address.

Step 3 of 4

Validate your mobile number.

Step 4 of 4

Configure your nickname and password.

Welcome Page with Examples

Once you signed up, you will be automatically logged in and the welcome page will be displayed. Four examples to perform a test are shown:

• Execution of a Simple HTTP/S Test
• Recording of a Web Surfing Session
• Converting a Selenium IDE Test to a RealLoad Test
• Developing a JUnit Monitoring Test

2.3 - Execute a Simple HTTP/S Test

This example shows how a simple HTTP/S Test can be defined as a RealLoad ‘Test’ and executed as both a Load Test Job and a Monitoring Job.

The test sequence is manually entered into the HTTP Test Wizard to keep this example simple. However, you can also record HTTP/S tests using an HTTP/S Proxy Recorder and convert the recording into a HTTP Test Wizard session.

Pre-Requisites

To configure and execute a simple test you’ll need:

• Access to the RealLoad portal. If you haven’t signed up, do so first Sign Up
• Approx. 20..30 minutes of your time
• A cup of tea or coffee

1. Invoke the HTTP Test Wizard and Create a New Session

Enter the Headline that briefly describes what the test does.

2. Save the (empty) Session

It’s best to save the empty session now. To do this, you must select a Resource Set of a Project. Alternatively, you can also create a new ‘Project’ and/or ‘Resource Set’. ‘Resource Sets’ are something like sub-directories of a Project, which contain all the files necessary to define and execute a test.

Enter the file name for the session, e.g. HttpSession_TestDownloadServer.json and save the session.

In this example, a new Project named ‘HTTP Tests’ is created which also contains a new Resource Set named ‘Download Server’.

3. Add URLs to the Session

Click on the ‘Add’ dropdown and select ‘URL’.

Enter the URL and click on the ‘+’ icon at ‘Verify HTTP Response’.

At ‘Verify HTTP Status Code’ select ‘200 OK’ and then click the ‘Add URL’ button.

You can then add additional URLs to the session. In this example it looks like this:

4. Debug the Session

Before converting the session into a RealLoad ‘Test’ you should Debug the Session first. This way you can check whether all URL calls are working correctly. Click ‘Debug Session’.

This invokes a powerful Remote Debugger that runs always on a Measuring Agent. As shown at the top right of the following image you can also select an alternative Measuring Agent on which the debugger will run.

In the debugger you can also extract values from HTTP responses and assign them to succeeding HTTP requests, whereby the session is automatically synchronized between the debugger and the HTTP Test Wizard.

In the debugger, click Next Step until all URLs have been executed successfully and the end of the session has been reached - or until an error occurs. If an error occurs, exit the debugger, then repair the URL (= HTTP/S request), and then invoke the debugger again.

After debugging is successful, return to the HTTP Test Wizard.

5. Save the (debugged) Session

6. Generate and Compile the Code, and Define the RealLoad ‘Test’

After the source code is compiled, click ‘Define New Test’.

Enter the Test Description, and click ‘Define New Test’.

The RealLoad ‘Test’ is now defined. From here you can now create both a Load Test Job and a Monitoring Job.

Note: In case you (later) modify the session in the HTTP Test Wizard, you will have to generate and compile the source code again.

7. Define and Execute a Load Test Job

In the RealLoad ‘Test’ click ‘Define Test Job’.

In next menu click ‘Continue’ …

… And select the Measuring Agent on which the Load Test Job will be executed, then click ‘Define Load Test Job’.

The Load Test Job is now defined. Click ‘Start Test Job’.

Enter the settings of the Load Test Job here and then click ‘Start Test Job’. We recommend the following settings for the first load test run:

1. Number of Users: 5
2. Max. Test Duration (Seconds): 60
3. Max. Loops per User: [unlimited]
4. Loop Iteration Delay (Milliseconds): 1000
5. Ramp Up Time (Seconds): 10

After a few seconds the Load Test Job is in the state ‘Running’. Click ‘Monitor Jobs’.

The real-time data of the running Load Test Job is now displayed.

Click on ‘Analyze Result’ after the Load Test Job is completed.

The Load Test Job result is then displayed.

To view the Job Output Files navigate to ‘Load Test Jobs’ and click in the dropdown of the Job on ‘Job Log Files’.

Select the file users.out which contains the Log Output of the Job.

If you would like to run the Load Test Job again with the same or changed settings, click on ‘Clone Job’ in the Job dropdown and then start the cloned job.

8. Define a Monitoring Job

If this is your first Monitoring Job, you must first create a Monitoring Group. Navigate to Monitoring, click the ‘Configuration’ tab and then click ‘Add Monitoring Group’. There is also a help available for configuring the Synthetic Monitoring.

Enter the ‘Group Title’ and select at least one ‘Measuring Agent’ on which the Monitoring Job(s) will be executed. Then click ‘Add Monitoring Group’.

In the ‘Monitoring Group’ click ‘Monitoring Jobs’ and then click ‘Add Monitoring Job’.

Select the ‘Test’ of the Monitoring Job.

Click ‘Define Monitoring Job’.

Enable the execution of the Monitoring Group and navigate to ‘Dashboard’.

The Monitoring Job is now defined and will be executed periodically. For additional help configuring monitoring (e.g. adding ‘Alert Devices’), see Monitoring Help.

Tip: If you modify the RealLoad ‘Test’, the corresponding Monitoring Job is not automatically updated to avoid unexpected corruption of the Monitoring Job. After you have verified the modified ‘Test’ by running a small Load Test Job, you must manually update the Monitoring Job.

Done, congrats, you’ve run your first test with Real Load.

9. Conclusion and Prospects

As you have seen, a RealLoad Test can be run as both a Load Test Job and a Monitoring Job.

This example was deliberately kept simple so that you can become familiar with the RealLoad product. To create a test with a web browser session across multiple web pages, you can use a Remote Proxy Recorder to record the test case and then convert the recording into an HTTP Test Wizard session.

Additionally, a Test Job Template can also be defined from any ‘Load Test Job’, which can then be part of a Test Suite. This means that you can add multiple ‘Test Job Templates’ to a Test Suite and execute them in a single run as a Regression Test.

To learn more, we recommend you read the User Guide. There you will find detailed documentation on the steps described in this document.

2.4 - Convert a Selenium IDE Test to a RealLoad Test

This example shows how a Selenium IDE Test - which was recorded with a Chrome or Firefox web browser - can be converted into a RealLoad ‘Test’. The converted RealLoad ‘Test’ can then be executed both as a Load Test Job and as a Monitoring Job. In addition, the converted test can also be part of a Test Suite for performing Regression Tests.

In most cases, the conversion can be done easily with just a few mouse clicks - without the need for any special settings.

At the end of each executed test run (of the converted RealLoad test), a final screenshot of the simulated web browser session is taken for each virtual user so that you can check whether the web browser session of the virtual user has been fully executed.

Tip: If possible, always use the Chrome web browser for Selenium IDE recording, as Chrome sessions are simulated much faster (= more realistic) than Firefox sessions.

Pre-requisites

To configure and execute this test you’ll need:

• Access to the Real Load portal. If you haven’t signed up, do so first: Sign Up
• Approx. 20..30 minutes of your time
• A cup of tea or coffee

1. Export the Selenium IDE Test as JUnit Test

Export the your recorded Selenium IDE Test as Java JUnit file and save the file to any folder on your local device. Note that the 3-dot dropdown icon may initially be hidden and may only appear when you are near to the Selenium ‘Test Case’ area. Do not choose any export option.

2. Upload the exported Selenium JUnit File

At Projects menu click on the ‘Developer Tools’ dropdown and select ‘Convert Selenium IDE Test to Real Load Test’.

Then upload the file by ‘Upload File’ or by dragging and dropping the file into the dashed area.

3. Convert the Uploaded JUnit File

Click on the ‘Convert’ button after uploading the file. The converted Java code is then displayed. Then click on the ‘Save & Compile’ button.

You have to save the converted code in a Resource Set of a Project. You can also first create a new Project with a new Resource Set.

After saving the converted code, you will be automatically redirected to the Compile Java File dialog.

4. Compile the Converted JUnit File

The JAR files required to compile are already preselected, i.e. you need only click the ‘Compile’ button.

After successful compilation, click ‘Define or Update Selenium by JUnit Test’.

You will then be automatically redirected to the Define JUnit & Selenium Test dialog.

5. Define the Selenium RealLoad ‘Test’

Select the JUnit @Test method (in this case only one will be shown) and click ‘Define Test’.

In an intermediate step you can enter an (optional) test description.

Now the Selenium RealLoad ‘Test’ is defined from which you can define a Load Test Job and/or a Monitoring Job.

6. Note about Measuring Agents

Please note that not all Measuring Agents support the execution of Selenium jobs. You can ‘ping’ a Measuring Agent at application level to find out whether Selenium jobs are supported:

Example 1: Measuring Agent ‘Demo Agent 1 (CH)’ does not support Selenium jobs

Example 2: Measuring Agent ‘Demo Agent 2B (CH)’ supports Selenium jobs

3 - Release Notes

4.8.51 | 2025-03-09

• New Feature: Support for ‘outbound’ connected Measuring Agents added. Until now, Measuring Agents could only be operated in ‘inbound’ network connection mode, which means that an inbound firewall rule is required. Starting from this release Measuring Agents can also be operated in ‘outbound’ network connection mode where no firewall rule is necessary. Outbound connected Measuring Agents support all product features as inbound connected Measuring Agents, with the only exception that they cannot be a member of a “Measuring Agent Cluster”. To operate outbound connected Measuring Agents an Agent Controller is required. However, a ‘default’ Agent Controller is already preconfigured and available to all customers. The operation of a customer-specific Agent Controller is recommended and can either be outsourced to us or alternatively carried out by the customer themselves.
• Portal Server version 4.8.51 requires now Measuring Agent and Cluster Controller version 4.5.13.

4.8.49 | 2025-01-13

• Bug Fixes:
  • The ‘Projects’ menu was often displayed with a significant delay of 10 to 60 seconds in the web browser, depending on the number of projects and their files. This performance issue has now been fixed and the projects menu is now always displayed within 1 to 2 seconds.

4.8.47 | 2024-12-23

• Bug Fixes:
  • Synthetic Monitoring: The sparklines (charts) in the real-time dashboard were sometimes displayed very slowly. This has now been fixed.
  • System Monitoring: The WebSocket connections were unstable, which resulted in statistics and data sometimes not being displayed in the web browser. This has now been fixed.
• New Feature:
  • System Monitoring: An API interface is now available and documented.

4.8.46 | 2024-12-09

• New Feature: Support for System Monitoring Webhooks added. Webhook ‘Alert Devices’ are now supported, which can be implemented online in JavaScript. The flexibility of JavaScript means that any third party systems can be integrated. The HTTP calls executed by JavaScript also support PKCS12 client certificates for authentication against Webhook servers.

4.8.44 | 2024-10-27

• New Feature: OS System Monitoring. Originally developed only to monitor our own infrastructure, this new subsystem has proven so successful that we can now make it available to our customers as well.
   
  Highlights of our New Operating System Monitoring Solution:
  • Very easy to implement - and state of the art - support of any Linux and Windows systems.
  • All important operating system metrics are displayed directly in the browser.
  • Predefined system monitoring rules are available and can easily be adapted to your needs.
  • Own system monitoring rules can be implemented online in JavaScript in a very short time.
  • Our new architecture beats the competition by far. And because we are new to the system monitoring market, we can offer you a sophisticated solution at an almost unbeatable price. Check out the documentation and request a quote.

4.8.40 | 2024-06-14

• New Features:

  • Support for Slowloris tests. Slowloris-like testing can now be performed by delaying the sending of HTTP requests and the receiving of HTTP response headers. In addition, the network throughput of HTTP responses can also be limited.
     
    In contrast to classic Slowloris tests, the HTTP requests and responses are fully executed, but are significantly delayed on the client side at the network level, which on the one hand leads to a backlog on the server side and on the other hand greatly reduces the network throughput.
     
    The following additional arguments can be entered when starting a load test job which was generated by the HTTP Test Wizard:
  -httpTimeout <milliseconds> | the HTTP processing timeout (default 30000 milliseconds).
  -delayHttpRequests <milliseconds> | delays sending HTTP requests (default -1 == no delay).
  -delayHttpResponseHeaders <milliseconds> | delays receiving HTTP response headers (default -1 == no delay).
  -throttleHttpResponses <bytes per second> | throttles the throughput of HTTP responses (default -1 == no throttle).
  Note that the -throttleHttpResponses argument has no effect on the server side for URL calls with small response content.
  Example: -httpTimeout 120000 -delayHttpRequests 3000 -delayHttpResponseHeaders 5000 -throttleHttpResponses 50000
  • The Mobile Companion App is now also available for Apple iOS devices.

4.8.38 | 2024-04-21

• New Features: The User Guide has been completely revised. In this context, the portal’s online documentation was also revised and enhanced, which now refers to the corresponding chapters of the user guide.
• Changes:
  • HTTP Test Wizard ‘Output Files’ are now stored in the in the output directory of the test job.
• Bug Fixes:
  • Compiling the code generated by the HTTP Test Wizard failed if the content of an HTTP request was very large.
• Portal Server version 4.8.38 requires now Measuring Agent and Cluster Controller version 4.5.12

4.8.37 | 2024-03-12

• New Features:
  • New Mobile Companion App released. The Mobile Companion is a small Android App that displays a simplified view of the Synthetic Monitoring Dashboard and can receive and display Synthetic Monitoring Alert Notifications.
    • This App gives you an overview of the status of your Synthetic Monitoring Jobs at any time - without having to sign in to the Portal Server.
    • The App also notifies you immediately if a Monitoring Job detects an error or warning.
    • By installing this App on your mobile device, you are always informed whether the operation of your services and servers is working reliably.
    • Documentation and Installation Instructions
• Announcement: Currently the Mobile Companion App can be installed on Android devices only. Support for Apple iOS will be available in around the next 2 months.

4.8.34 | 2024-02-20

• Synthetic Monitoring API Documentation
  • Full Synthetic Monitoring API documentation is now available to support developers to implement their own version of a real-time dashboard for Synthetic Monitoring that can be displayed on their companies screen.
  • The powerful API also supports receiving data for drawing charts and sparklines. In addition, the API documentation contains helpful information about implementation and runtime behavior.
  • See https://kb.realload.com/docs/api/remoteusermonitoringapi/  

4.8.31 | 2024-01-18

• New Features:
  • The Welcome Page that appears after ‘Sign Up’ to the RealLoad Portal now displays 3 ‘Test’ examples, all of which can be run as a Load Test, a Synthetic Monitoring Test, and a Regression Test. These 3 examples are also available in the public documentation:
    • Execution of a Simple HTTP/S Test
    • Converting a Selenium IDE Test to a RealLoad Test
    • Developing a JUnit Monitoring Test

4.8.30 | 2023-12-27

• New Features:
  • Synthetic Monitoring: Added configurable performance alert thresholds for the measured time per loop (= average passed session time). Two performance alert threshold values (in milliseconds) can be configured per monitoring job. One to trigger a warning and another to trigger an error. If one of these thresholds is reached or exceeded, a performance warning or performance error is added to the test result, which has the same effect as measuring a “normal” error with a severity of “Warning” or “Error”.
• Portal Server version 4.8.30 requires now Measuring Agent and Cluster Controller version 4.5.11

4.8.29 | 2023-12-17

• New Features:
  • Synthetic Monitoring: Added real-time Sparklines (microcharts) to the Real Time Dashboard. The sparklines with a time range of the last 24 hours show the measured availability for monitoring groups, and for monitoring jobs the measured availability and the measured response times (milliseconds per loop). The displayed time range of the sparklines can be zoomed by clicking on the chart while holding down the mouse button and panning to the right or left in the chart. After releasing the mouse button, the zoom of the corresponding area appears. If necessary, you can then zoom in again to narrow down the area further.

4.8.28 | 2023-12-14

• New Features:
  • Slightly redesigned Synthetic Monitoring user interface.
    • Real-Time Dashboard: The dashboard supports now to show only monitoring groups or only monitoring jobs - or both of them (as before).
    • Real-Time Dashboard: The displayed availability of Monitoring Groups and Jobs for the last 24 hours is now a hyperlink that, when clicked, displays the corresponding statistical chart.
    • All Synthetic Monitoring menus and popups have been revised to make them more descriptive and user-friendly.
• Bug Fixes:
  • Synthetic Monitoring: Webhook alert calls which return a HTTP status code 202 (instead of 200) are no longer logged as failed.

4.8.27 | 2023-12-07

• New Features:
  • Synthetic Monitoring: Support for delayed alert notifications: Alert notifications can now be triggered immediately (as before) or (new) only after one or several repeats. This means that short-period errors and downtimes can be excluded from alert notifications. This does not affect the measured statistics such as availability and detected errors. Delayed alert notification settings can be configured separately for each “Alert Group”, whereby multiple alerts groups can be assigned to one or multiple “Monitoring Groups” and “Monitoring Jobs”.

4.8.26 | 2023-11-28

• New Features:
  • Synthetic Monitoring: Added support for ‘Monitoring Downtimes’. A Monitoring Downtime is a window of time during which synthetic monitoring is temporarily disabled. Multiple monitoring downtimes can be defined for all monitoring groups, or for specific monitoring groups and also for specific monitoring jobs. In addition, a monitoring downtime can be repeated daily, weekly or monthly.

4.8.24 | 2023-11-12

With this new release we have reached the point where a general load testing tool has been crossed with a monitoring tool and also with a regression testing tool - with both the monitoring tool and the regression testing tool are capable of executing test jobs with hundreds or thousands of concurrent users.

• New Features:
  • Real Load Test Suites
    • Test suites are the grouping of multiple test job templates and are executed as a single “run” with different test scenarios.
    • Due to the universal architecture, test jobs of any kind can be part of a test suite (HTTP Test Wizard Jobs, JUnit Jobs, Selenium Jobs ..).
    • The results of the test suite “runs” are archived and can be compared with each other.
    • In addition, the result of a particular test job of a test suite run can be compared with the result of the same test job executed by other test suite runs.
    • All test jobs of a test suite support the powerful ability to be executed with hundreds or thousands of concurrent users and can even executed on a cluster of measuring agents.
    • The test jobs of a test suite are grouped into “execution groups”, where the test jobs of an execution group can be executed in sequential or parallel order.
    • The execution groups can be nested, whereby a separate measuring agent or measuring agent cluster can be defined for each execution group.
    • A “run” of a test suite can be triggered either interactively or via the Remote User API.
  • The following functions have been added to Remote User API:
    • getTestExecutionSuites
    • getCurrentlyRunningTestExecutionSuiteIds
    • startTestExecutionSuiteTestRun
    • getTestExecutionSuiteTestRunResultDetail
    • getTestExecutionSuiteTestRunTestJobOutputFileContent
    • deleteTestExecutionSuiteTestRun
  • Tests: Delete Test: A warning message will now be displayed if the test is referenced by a Monitoring Job or by a Test Suite.
  • Tests: Option “Delete All Unreferenced Tests” added.
  • Load Test Jobs: The display of load test jobs can now filtered by Project and Resource Set.
• Bug Fixes:
  • Starting a load test job failed in rare cases due to a synchronization problem.
• Portal Server version 4.8.24 requires now Measuring Agent and Cluster Controller version 4.5.10

4.8.23 | 2023-09-18

• New Features:
  • Added support for ‘Test Job Templates’.
  • The following functions have been added to Remote User API:
    • getTestjobTemplates
    • defineNewTestjobFromTemplate
    • submitTestjob
    • makeTestjobReadyToRun
    • startTestjob
    • getMeasuringAgentTestjobs
    • getTestjobOutDirectoryFilesInfo
    • getTestjobOutDirectoryFile
    • saveTestjobOutDirectoryFileToProjectTree
    • deleteTestjob

4.8.21 | 2023-09-13

• New Features:
  • Improved integration of JUnit Test with the Real Load architecture. As already described earlier, any JAR file that contains JUnit test can be uploaded to the portal server and executed directly as a test, i.e. without conversion. However, if you are programming a JUnit test from scratch, you can benefit from the additional enhanced features of the Real Load architecture. These additional features include better log output of the executed JUnit test, support for “User Input Fields” (configurable test input parameters), and the measurement and display of additional statistics obtained during test execution.
  • After logging into the portal server, a new project called “Developer Examples” will appear, which contains an example of a JUnit test and shows how a JUnit test can be fully integrated into the Real Load architecture.

4.8.20 | 2023-09-10

• New Features:
  • Added support for executing Selenium IDE tests with Google Chrome.
  • When a Measuring Agent is pinged at application level, it is displayed whether the Measuring Agent supports the execution of Selenium tests.
• Changes:
  • The Selenium version sent to Measuring Agents is now 4.12.1 instead of 4.10.0. However, this only applies to tests that are newly created.
• Portal Server version 4.8.20 requires now Measuring Agent version 4.5.9 when Selenium IDE tests with Google Chrome are executed.

4.8.19 | 2023-09-04

• New Features:
  • Added support for executing Selenium IDE tests. Selenium IDE tests recorded on your local device can be executed as monitoring job and as load test job - by exporting them in the Selenium IDE as ‘Java JUnit’ test and then importing them into the Real Load portal. The imported tests support also ‘User Input Fields’ (configurable options when starting a test) and take a final screenshot of the (virtual) Web browser display just at the end of each test run - which can then be viewed in the Real Load portal. Currently only tests recorded with Firefox are supported. Support for tests recorded with Chrome and Edge will be added soon.
  • Added support for executing JUnit 4 tests. JAR files which contain ready-to-use JUnit @Test(s) can be uploaded to the Real Load portal and run directly as a monitoring job and as a load test job. The benefit of running JUnit tests on the Real Load infrastructure is firstly that they can be run as a “monitoring job” and secondly that they can be run as a “load test job” with many hundreds of JUnit tests, running concurrently in parallel (or even with many thousands of JUnit tests running in parallel, through the use of a cluster of Real Load Measurement Agents). However, this is usually only useful for JUnit tests which are testing or stressing network services of any kind.
• Portal Server version 4.8.19 requires now Measuring Agent and Cluster Controller version 4.5.8

4.8.17 | 2023-07-29

• New Features:
  • Synthetic Monitoring: Support of ‘Pagerduty V2’ and ‘Slack’ Webhook alert devices added.
  • Test Results: The selected test result can now exported to a PDF and to a MS Word document.
  • ‘HTTPS Server Certificate Tool’ added.
• Changes:
  • HTTP Test Wizard: The URL HTTP timeout can now specified in milliseconds (instead of seconds).

4.8.14 | 2023-06-29

• New Features:
  • Revised Sign-Up: When sign-up, two shared Measuring Agents are now assigned to the new user account.
  • For customers (user accounts) who do not operate their own HTTP/S Remote Proxy Recorder, a temporary HTTP/S Remote Proxy Recorder from a pool is now assigned each time they sign-in.
  • Synthetic Monitoring: A warning sign is now displayed for Monitoring Groups for which no Measuring Agent have been defined.
• Portal Server version 4.8.14 requires now HTTP/S Remote Proxy Recorder version 1.1.3, and Measuring Agent and Cluster Controller version 4.5.7

4.8.13 | 2023-06-20

• New Features:
  • HTTP Test Wizard ‘URL Plugins’ can now be assigned in one step to multiple or all URLs of a HTTP/S session.
• Changes:
  • Sent SMS messages now have the sender ID ‘RealLoad’ instead of a (technical) phone number.
• Bug Fixes:
  • Synthetic Monitoring: No alert was send at monitoring group level when an execution timeout occurred.

4.8.12 | 2023-06-07

• New Features:
  • Measuring Agents which are shared with other Portal Server user accounts (other customers) are now marked with [P] = ‘partial shared’ or [S] = ‘fully shared’ in the Measuring Agents menu. Measuring Agents that are operated exclusively for a specific customer do not have such a mark.
  • The ‘My Account -> Price Plan’ menu shows now the number of sent SMS monitoring alerts of the current month, and also of the last 12 months.
  • Price Plan limits for Synthetic Monitoring have been implemented and are now shown in the ‘My Account -> Price Plan’ menu.
• Changes:
  • The primary Mobile Number for main user accounts and team member accounts no longer needs to be unique across all Real Load accounts.
  • Measuring Agent Housekeeping: The data of executed jobs older than 30 days are now deleted on Measuring Agents (monitoring jobs + load test jobs).
• Bug Fixes:
  • Team member accounts with read/only privileges could make changes to the Synthetic Monitoring configuration.

4.8.10 | 2023-05-11

• New Features:
  • HTTP Test Wizard
    • ‘Conditional Jump’ session element added. For example, this new session element allows a webpage to be called in a loop until the received content contains a certain value, or until a maximum number of conditional jumps is exceeded. Adding multiple conditional jumps per session is supported, with the ability to jump backwards or forwards. The condition of whether to jump and where to jump can be determined by variable values.
    • Java JVM warm-up before starting a test. Tests that run with only one or a few users and loops are now more accurately measuring URL response times by performing a Java JVM warm-up before starting the test.
    • The log-data of measured errors have been improved (less but more meaningful data).
  • Projects Menu
    • The preview of the test results shows now additionally the ‘Avg. Passed Session Time’.
  • Load Test Jobs Menu
    • A new delete option ‘All Completed Jobs - Except the Last Ones’ has been added.
  • Test Results Menu
    • The ‘Avg. Passed Session Time’ is now show in the Summary Statistic.
    • Searching for Text values in an Error Detail ‘Log’ and in an Error Detail ‘Context’ is now supported.
• Changes:
  • HTTP Test Wizard
    • Errors reported at URL level are no longer additional reported at Measurement Group level.
  • Test Execution
    • The number of stored errors is now limited to 2000 fully stored errors plus 8000 partial stored errors (partial stored: without error log and without error context).
• Portal Server version 4.8.10 requires now Measuring Agent and Cluster Controller version 4.5.6
• To take advantage of the new features you have to re-generate and re-compile the Java source code in the HTTP Test Wizard.

4.8.8 | 2023-04-05

• New Features:
  • Menu Measuring Agents
    • Measuring Agent Log File: The log file is displayed faster in the browser and supports now searching for text fragments. The time zone of the log file is now also displayed.
    • List Remote Test Jobs: The display of the Job Type was added (‘Load Test’ or ‘Monitoring’).
• Bug Fixes:
  • In rare cases the start a job failed on Measuring Agents.
  • In rare cases the Synthetic Monitoring Availability Chart did show wrongly a green bar (OK) instead of a red bar (Error).
• Portal Server version 4.8.8 requires now Measuring Agent and Cluster Controller version 4.5.5

4.8.7 | 2023-03-26

• New Features:
  • Synthetic Monitoring
    • “Statistics” Submenu added which shows statistics and charts of monitoring groups and monitoring jobs, such as availability, cumulated error time and performance. The time range can be selected arbitrary. In addition, single, historical measurements can be selected and their details displayed (e.g. to analyze a measured error).
    • The Real Time Dashboard shows now for the monitoring jobs the availability of the last 24 hours in percent.

4.8.4 | 2023-03-03

• New Feature:
  • The Synthetic Monitoring Real Time Dashboard shows now the (average) performance of the last executed monitoring jobs in the unit of milliseconds per passed loop. Background information: A monitoring job can be defined with a strength of up to 5 concurrent users and with up to 5 test-loops per user. This value shows the average execution time of the successful executed test-loops overall concurrent users.

4.8.3 | 2023-02-28

• New Features:
  • Synthetic Monitoring added: The same scripts used for load testing can now also be used to periodically check the uptime and performance of your critical business transactions. This means that a Monitoring Job can be defined from an already existing Test (similar as to define a Load Test Job). The Monitoring Jobs can be combined to Monitoring Groups whereby each Monitoring Group can have its own settings. Multiple Measuring Agents can be assigned to a Monitoring Group in order that the assigned Monitoring Jobs are executed from several, different locations (for example from New York, Berlin and Singapore). Supported Monitoring Alert Devices are Email, SMS and Webhooks.
  • WebSocket API for Synthetic Monitoring added: This WebSocket API enable developers to implement their own version of a Synthetic Monitoring “Real Time Dashboard”.
• Portal Server version 4.8.3 requires now Measuring Agent and Cluster Controller version 4.5.4

4.7.8 | 2022-11-06

• New Features:
  • Desktop Companion: An ‘OS X Intel Installation Kit’ and an ‘OS X ARM Installation Kit’ are now available at https://download.realload.com  
  • Remote Proxy Recorder
    • Support of Client Certificates (PKCS12 files) that can uploaded to the Portal Server and applied for target server authentication on all Remote Proxy Recorders. The uploaded client certificates are automatically transmitted to the Remote Proxy Recorder(s) when connecting from the Portal Server to a Remote Proxy Recorder.
    • The log files of Remote Proxy Recorders can now be viewed in the Portal Server Web UI.
    • ‘Ping’ and ‘Connect’ to a Remote Proxy Recorder in the Portal Server Web UI now show an error message for outdated/incompatible Remote Proxy Recorder versions.
    • Any changes made at Remote Proxy Recorder settings for ‘Hosts Recording Filter’, ‘URL Filter’ and ‘URL Filter Quick Setting’ are now saved on the Portal Server and reapplied when connecting from the Portal Server to any Remote Proxy Recorder.
• Bug Fixes:
  • HTTP/S session recording (with Remote Proxy Recorder and Desktop Companion) failed on Apple macOS and iOS client devices.
  • HTTP Test Wizard URL Explorer - Variables Wizard: variable names for JSON HTTP-request ‘variable assigners’ were not displayed.
  • HTTP Test Wizard Generate Code: The “Java Class Name” can now have a lowercase letter at the beginning.
• Portal Server version 4.7.8 now requires Remote Proxy Recorder version 1.1.1

4.7.6 | 2022-10-17

• New Features:
  • HTTP Test Wizard: Variable Assigner for ‘General Request Header Field’ added.
  • HTTP Test Wizard: Select Multiple Session Elements - ‘URL Filter Quick Settings’ menu added.
  • HTTP Test Wizard Debugger: Support to set/update the ‘Recorded Data’ of an executed URL (shown in the HTTP Test Wizard URL Explorer). This functionality can be used for further test optimization (e.g. if the content of a tested URL has been changed on the server side, or if the URL response is as yet unknown).
  • HTTP Test Wizard Debugger: Menu ‘Search in executed URLs’ added.
• Bug Fixes:
  • HTTP Test Wizard URL Explorer | Variables Wizard: Bug Fix for automatically applied variable assigners which replace URL-Encoded/Decoded values.
  • Measuring Agent - Data Collector: Bug Fix for supporting large measured Error Details.
• Portal Server version 4.7.6 requires now Measuring Agent and Cluster Controller version 4.5.2

4.7.3 | 2022-8-28

• New Features:
  • HTTP Test Wizard: New menu “URL Explorer” added. The URL Explorer shows all the details of the recorded HTTP session data and also supports searching within it. Furthermore, the URL Explorer also contains a “Variables Wizard” which displays all distinct values clearly sent in an HTTP session and makes it much easier to extract and assign session variables.
  • HTTP Test Wizard / Review and Edit URL Settings: This menu has been revised and enhanced. Two new auto-configurations wizards are available with which the content of HTTP responses can be automatically checked for keywords and with which the parallel execution of HTTP calls can be configured automatically.
  • HTTP Test Wizard / Debugger: UI improved.
  • A new “Text Phrase Tool” has added. This tool determines the most meaningful human-readable text phrases or keywords from any given content (HTML/JSON/XML). This tool has also been integrated into the HTTP Test wizard.
  • Remote Proxy Recorder: “URL Filter Quick Setting” menu added.
  • Remote Proxy Recorder: “Convert Recording to HTTP Test Wizard Session” improved and enhanced.
  • Portal Server (all menus): Large screen support has been improved.
  • Admin Menu: Mobile Companion API integrated and “Mobile Companion App - Test & Logs” menu added.
• Bug Fixes:
  • HTTP Test Wizard / Generate Code: The measured statistic IDs of executed load tests have now the same values as the indexes of the HTTP Test Wizard session elements.
  • Load test programs generated by the HTTP Test Wizard did not correctly measure the response time in some cases when an HTTP response had no response content (bug fix in com.dkfqs.tools.jar, new version 2.3.0).
• Portal Server version 4.7.3 requires now Measuring Agent and Cluster Controller version 4.5.0, and Remote Proxy Recorder version 1.0.0

4.6.8 | 2022-5-19

• Bug Fixes:
  • Adding of cluster members to AWS/EC2 ‘Cluster Controller’ instances which have launched by cloud credits did fail.
  • The status of cluster jobs was not updated by the real-time monitor.
  • Deleting of test jobs did fail if the corresponding cluster was no longer defined.
  • Starting of cloud instances is now prevented if the portal’s internal monitoring system is no longer working.
• Portal Server version 4.6.8 requires now Measuring Agent version 4.2.0 (bug fix: incorrect measurement results were reported sporadically)

4.6.7 | 2022-5-18

• New Features:
  • AWS/EC2 ‘Remote Proxy Recorders’ can now be started by cloud credits.
  • Preview of ‘Remote Proxy Recorder CA Root Certificate’ added when downloading a remote proxy recorder CA root certificate.
  • 40 seconds countdown to left navigation added when launching EC2 instances by cloud credits.

4.6.5 | 2022-5-10

• New Features:
  • Support for team member accounts added:
    • Depending on the license (price plan), a normal user (main user) can also define sub-users (so-called team member accounts).
    • Team members can login as usual, with their email and password.
    • Team members can either have the same rights as the main user or alternatively only have read rights.
    • The team members (including the main user) can communicate with each other via push messages. The portal also shows which team member is currently online. Offline team members receive an email instead of an online push notification.
    • A list of all team members is provided for each team member (inclusive the main user), which contains the profile text and profile image of each team member.
    • Team member accounts are not portal-wide ‘public users’, and cannot act as public technical expert.
• Bug Fixes:
  • Deleting of test jobs did fail if the corresponding measuring agent was no longer defined.

4.6.4 | 2022-4-18

• New Features:
  • Support of special licenses to top up the amount of ‘Cloud Credits’.
  • License restrictions on the maximum number of Measuring Agents and Remote Proxy Recorders no longer apply when such components are launched by spending Cloud Credits.
  • The Web Browser interface has been optimized to support large screens.

4.6.2 | 2022-4-12

• New Features:
  • Support of ‘Sign in with Microsoft’ added.

4.6.0 | 2022-4-10

• New Features:
  • The list of excluded AWS/EC2 regions can now be edited in the admin menu.
  • The additional data transfer costs of AWS/EC2 instances which are started via the Portal Server are now billed via Cloud Credits.
  • A new Measuring Agent version 4.1.0 is available which is able to automatically configure the Java memory of the ‘Data Collector’ and the Java memory of executed Java test programs.
• Portal Server version 4.6.0 supports Measuring Agent version 4.0.4 and version 4.1.0

In order to enable the automatic Java memory configuration of a Measuring Agent 4.1.0, the following Java program arguments must be set in the startup script: -autoAdjustMemory -osReservedMemory 1GB

Furthermore, the Java memory of the Measuring Agent should be set in the startup script as shown in the table below:

Example: sudo -H -u dkfqs bash -c ‘CLASSPATH=/home/dkfqs/agent/bin/bcpkix-jdk15on-160.jar:/home/dkfqs/agent/bin/bcprov-jdk15on-160.jar:/home/dkfqs/agent/bin/bctls-jdk15on-160.jar:/home/dkfqs/agent/bin/DKFQSMeasuringAgent.jar;export CLASSPATH;nohup java -Xmx512m -DdkfqsMeasuringAgentProperties=/home/dkfqs/agent/config/measuringagent.properties -Dnashorn.args="–no-deprecation-warning" com.dkfqs.measuringagent.internal.StartDKFQSMeasuringAgent -autoAdjustMemory -osReservedMemory 1GB 1>/home/dkfqs/agent/log/MeasuringAgent.log 2>&1 &’

4.5.0 | 2022-3-27

• New Features:
  • Amazon AWS/EC2 instances of ‘Measuring Agents’ and ‘Cluster Controllers’ can now be started directly in the Portal Server - without the customer needing an Amazon AWS account. The costs of such started AWS/EC2 instances are charged to the customer via so-called ‘Cloud Credits’, whereby the number of ‘Cloud Credits’ can be purchased as an integral part of a license or can also be purchased separately. For customers who register for the first time at the Portal Server, a free amount of ‘Cloud Credits’ will be credited to allow them try out this functionality. Note: It is still fully supported to launch Amazon AWS/EC2 instances of ‘Measuring Agents’ and ‘Cluster Controllers’ with your own Amazon AWS account by using the standalone tool ‘Desktop Companion’.
  • User Top Navigation: Link to Download Server and to Real Load Store added (both links are manageable by the administrator menu).
  • HTTP Test Wizard: Review and Edit URLs menu added.
  • Launched Cloud Instances menu added.
  • Cloud Credit Statement menu added.
  • Measuring Agents & Cluster Controllers menu: The ‘List of Predefined AWS/EC2 Measuring Agent AMIs’ shows no longer incompatible AMI versions.
  • The following new functions have been added for administrators:
    • User Accounts menu: Cloud Credit Statement menu per user added.
    • Server Settings menu: AWS/EC2 Cloud Provider API Settings section added.
    • Customize Auth Users Navigation menu: Download Components and Shop sections added.
    • Cloud Providers & Instance Type Credit Costs menu added.
    • Inspect AWS/EC2 Cloud Instances menu added.
    • Launched Cloud Instances menu added.
    • Cloud Credit Transactions menu added.

Advantages and disadvantages of ‘Cloud Credits’ versus launching AWS/EC2 instances by the ‘Desktop Companion’:

Benefits of ‘Cloud Credits’:

• Full cost control. Cloud instances are automatically terminated after a selected time.
• Easy to use. Seamless integration with the portal server.
• No Amazon AWS account required and therefore no security issue for unauthorized AWS access.

Advantages of the ‘Desktop Companion’:

• Lower costs for cloud instances compared to ‘Cloud Credits’(AWS self-cost are charged only).
• Suitable for customers who use cloud instances frequently and are aware of AWS/EC2 costs involved.

4.4.4 | 2022-1-30

• New Features:
  • Load-releasing Clusters of Measuring Agents are now supported. In order to operate a cluster, a separate process/component is required (so-called “Cluster Controller”) which is not part of the portal server and is operated by the customer himself. Cluster-Features:
    • Multiple clusters can be registered in the portal server using the UI, and the cluster members (measuring agents) can be assigned to the clusters with simple clicks.
    • Depending on the power of the Cluster Controller, a cluster can have several 100 members, which allows to perform load tests of almost unlimited strength (up to millions of concurrent users).
    • A cluster job can be started as easily as a normal job. The only difference is that a cluster is selected for execution instead of a single measuring agent.
    • Optionally, the content of input files can be automatically divided among the cluster members (e.g. if they contain user account credentials).
    • Cluster jobs support all runtime features like normal jobs: suspend job, resume job, stop job and kill job. Entering annotations at runtime is also supported.
    • The real-time display of cluster jobs is exactly the same as for normal jobs, but the statistics displayed at real time already contain the combined values of all cluster members. In addition, a table about the current operating status of each cluster member is available.
    • After a cluster job has been completed, the test result contains the combined values of all cluster members (analogous to the real-time display). In addition, the individual test results of the cluster members can also be displayed.
  • The following functions have been added to the “Remote User API”:
    • getMinRequiredMeasuringAgentVersion
    • getMinRequiredClusterControllerVersion
    • getMinRequiredProxyRecorderVersion
    • getMeasuringAgentClusters
    • getClusterControllers
    • pingClusterController
    • addMeasuringAgentCluster
    • addMemberToMeasuringAgentCluster
    • removeMemberFromMeasuringAgentCluster
    • pingMeasuringAgentClusterMembers
    • setMeasuringAgentClusterActive
    • deleteMeasuringAgentCluster
  • Portal Server “Measuring Agents” menu: The AWS/EC2 popup highlights now incompatible AMI versions.
  • Portal Server “Test Jobs” menu: The log files of executed jobs can now directly copied to the project tree.
• Bug Fixes:
  • A test job can now also have the state “execution failed”.
• Portal Server version 4.4.4 requires now Measuring Agent version 4.0.4

4.3.23 | 2021-11-13

• New Features:
  • HTTP Test Wizard: New Session Element ‘Outbound IP Address’ added. In order that this element can be used, multiple valid IP addresses must be assigned to the network interface of the Measuring Agent(s).
  • HTTP Test Wizard: Support of specific HTTP processing timeout per URL added.
  • Test Results: Support of annotation and annotation events added. The annotation and annotation events can be added at runtime during the test and are shown in the test result. In addition, annotation events can also be reported via the All Purpose Interface and generated, for example, by HTTP Test Wizard plug-ins.
• Bug Fixes:
  • The cached HTTP Test Wizard Session in the Portal Server UI is now updated when a variable is defined, modified or deleted, and when a variable extractor or a variable assigner is deleted.
  • Invalid Java code was generated by the HTTP Test Wizard if the error handling of URLs was set to ‘Continue as usual’.
  • Performance bottleneck fixed in com.dkfqs.tools.http.HTTPClient (occurred since previous version 4.3.22).
  • An incorrect error exception was thrown in com.dkfqs.tools.crypto.EncryptedSocket when an SSL handshake timeout occurred
  • Realtime charts sometimes showed inexact measurement results.
• Portal Server version 4.3.23 requires now Measuring Agent version 3.9.33 and DKFQS Tools version 2.2.25

4.3.22 | 2021-10-24

• Documentation: All Purpose Interface added.
• The All Purpose Interface has been extended by 3 new statistics types that can be declared at runtime:
  • average-and-current-value : An average and current value
  • efficiency-ratio-percent : An efficiency ratio in percent (0..100%)
  • throughput-time-chart : A chart of a throughput per second
• The measurement results of the HTTP Test Wizard now contain the following additional test-specific values (if the executed HTTP Test Wizard session contains URL session elements):
  • Total Bytes Sent
  • Total Bytes Received
  • Network Throughput in Mbps (real-time: current value, test result: average value and chart)
  • Average TCP Connect Time in milliseconds (real-time: + latest value)
  • Average SSL Handshake Time in milliseconds (real-time: + latest value)
  • HTTP Keep-Alive Efficiency (0..100%)
• Bug fix: The time in the name of the test result files is now always set in the time zone of the portal server, regardless of which time zone the Measuring Agents are operated.
• Portal Server version 4.3.22 requires now Measuring Agent version 3.9.32 and DKFQS Tools version 2.2.24

4.3.21 | 2021-09-18

• Searching for a text in all files of the project tree is now supported.
• Support to upload files by drag and drop added.
• Bug fix for assigning variables to HTTP requests in HTTP Test Wizard debugger.
• Bug fix on real time statistics and test results if the measured unit is other than ms.
• User profile images can now have a max size of 400 KB instead of 200 KB.
• CA Root Certificates of HTTP/S Proxy Recorder(s) can now be downloaded via the Portal Server UI.
• Documentation: User Guide added.
• SNMP Plug-In published at https://portal.realload.com/publicPublishedPlugins  

Portal Server Installation / Ubuntu 20: The “fontconfig” package has to be installed in order that the captcha generator is working:

sudo apt-get update
sudo apt-get install fontconfig

4.3.20 | 2021-08-07

• HTTP Test Wizard Plug-Ins can now be published and are then available to other users.
• The following HTTP Test Wizard Plugin fields are now protected by algorithms and cannot be manually modified by the JSON editor:
  • pluginId
  • authorNickname
• A (new) “Resources Library” project is automatically created for each user in the Project Tree which contains by default the following “Resource Sets”:
  • “HTTP Test Wizard Plug-Ins”: by default empty
  • “Java”: contains always the latest version of com.dkfqs.tools.jar
  • “PowerShell”: contains always the latest version of DKFQSLibrary2.psm1
• The “Resources Library” project contains common resources which are used by multiple projects. The users can add additional resource sets and files as needed to this project.
• The file com.dkfqs.tools.jar is no longer copied to the corresponding resource set when a HTTP Test Wizard test is generated. Instead of this the generated test contain now a reference to “Resources Library / Java / com.dkfqs.tools.jar”.
• New created HTTP Test Wizard Plug-Ins contain now by default a reference to the resource file “Resources Library / Java / com.dkfqs.tools.jar”.
• More than 50 minor bugs have been fixed and some improvements have been made to the portal user interface.
• Portal Server version 4.3.20 requires now Measuring Agent version 3.9.31
• Existing tests and plug-ins should be upgraded to use com.dkfqs.tools.jar version 2.2.21 (located at “Resource Sets / Java”). This means that the tests have to be generated and defined once again.
• The tuning parameters of Linux operating systems on which “Measuring Agents” run must be increased:

in /etc/security/limits.conf add or modify:

# TCP/IP Tuning
# =============
* soft     nproc          262140
* hard     nproc          262140
* soft     nofile         262140
* hard     nofile         262140
root soft     nproc          262140
root hard     nproc          262140
root soft     nofile         262140
root hard     nofile         262140

Enter: systemctl show -p TasksMax user-0

output: TasksMax=8966

if you get a value less than 262140 then add in /etc/systemd/system.conf

# System Tuning
# =============
DefaultTasksMax=262140

Reboot the system and verify the settings. Enter: ulimit -n

output: 262140

Enter: systemctl show -p TasksMax user-0

output: TasksMax=262140

4.3.18 | 2021-07-06

• Support of Licenses added. Multiple licenses per user account are supported. New licenses can be entered via the Admin Menu and via the User Menu. Users whose license has expired can enter a new license during sign-in.
• Pluggable Architecture for License Providers implemented.
• Remote Admin API and Remote User API added. The corresponding API Authentication Tokens can be generated via the Admin Menu and via the User Menu. See API Documentation .
• Unix Time Tool in User Menu added.
• User accounts that are since a long time expired are now automatically deleted - including all user specific data. The number of days between the expiry date and the deletion date can be configured in the Admin Menu.
• Deleted user accounts can now be viewed in the Admin Menu.
• Portal Server version 4.3.18 requires now Measuring Agent version 3.9.30

4.3.14 | 2021-04-08

• Support of multiple Price Plans / Limits for User Accounts such as Disk-Space, Number of Measuring Agents, Account expires time … (Admin Menu).
• Access to Measuring Agents can now (optional) protected by an Authentication Token (password).
• Configurable Default Price Plan for Sign Up (Admin Menu).
• Configurable HTML content for Sign Up steps 1 to 4 and for (new) Sign Up completed “Welcome Page” (Admin Menu).
• Test jobs are now digitally signed. This means that the following job settings on a Measuring Agent cannot be modified after the job has been transmitted to the Measuring Agent: type of job, local test job ID, number of users, maximum test duration.

4 - User Guide

Thank you for using the RealLoad product.

This User Guide gives you an overview of how to use RealLoad and also contains numerous links to relevant details.

The order of the chapters in this guide corresponds to the order of the menus in the Main Navigation Bar.

Projects Menu

After you have signed in to the RealLoad Portal, you will see a Main Navigation Bar whose first menu on the left is Projects. This is a file browser that displays all of your files. The view is divided into Projects and Resource Sets which contain all the files for executing your tests and the test results of the executed load tests. You can also store additional files in a Resource Set which contain e.g. instructions on how a test should be performed.

Among other things, you can:

• Create, clone and delete projects.
• Create, clone and delete resource sets (subdirectories of projects).
• Searching for files by file name and by content.
• Upload and download files, create new files, display the content of files, edit and delete files.

There is also a recycle bin from which you can restore deleted projects, resource sets and files.

In the Developer Tools dropdown menu, there is a wizard that supports converting a Selenium IDE Test to a RealLoad Test, and an example of developing a JUnit Test from scratch.

Tests Menu

The Test Menu shows all tests that you have defined. You can also filter the view according to Projects and Resource Sets, and sort the tests in different ways.

Tests can defined:

• By the HTTP Test Wizard (Web Surfing Sessions and HTTP API Tests)
• From exported Selenium IDE Tests (Execution of real Web Browser Tests)
• From imported or self-developed JUnit Tests (Testing any type of Network Protocol such as DNS, SMTP or UDP)

…and can be executed:

• As Load Test Job
• As Regression Test (Part of a Test Suite)
• As Synthetic Monitoring Job

Note that a test is something like a bracket that only contains references to the files that are required for the test execution. There a no files stored inside the test itself.

Each test has a base location from which it was defined (Project + Resource Set) and to where also the load test results are saved.

A test itself can reference its resource files in two ways:

• Resource Files that reside in the base location of the test (the test core files).
• Referenced Files that are located in other Projects / Resource Sets. These are typically libraries, plug-ins and input files which are used/shared by several, different tests.

Defining a Load Test Job

After you have clicked on a test on “Define Test Job”, the intermediate “Define Test Job” menu is displayed.

In contrast to a “test”, all referenced files of the test are copied into the “load test job”. For this reason there is also the option “Synchronize Files at Start of Job” which you should always have switched on. At “Additional Job Arguments” you can enter test-specific command line arguments that are transferred directly to the test program or test script. However, you usually do not need to enter anything.

After you have clicked on “Define Load Test Job” the test job is created and the view changes from the “Tests” menu to the Load Test Jobs menu.

Monitoring Menu

This menu is documented at Synthetic Monitoring.

Load Test Jobs Menu

In this menu all load test jobs are displayed with their states. The green point at the top right next to the title indicates that all measurement agents and cluster controllers which are set to ‘active’ can also be reached. The color of the point changes to yellow or red if one or more ‘active’ measuring agents and cluster controllers cannot be reached / are not available.

A load test job can have one of the following state:

• invalid: The job is damaged and can only be deleted.
• defined: The job is defined locally in the portal server, but has not yet been transmitted to a measuring agent or cluster controller. Jobs that are in this state can still be modified.
• submitted: The job was transmitted to a measuring agent or cluster controller, but is not yet ready to be started.
• ready to run: The job on the measuring agent or cluster controller is ready to start.
• start failed: The start of the job has failed.
• running: The job is currently running and can be monitored at real time.
• completed: A job that was previously running is now completed (done).

As soon as a job is in the “defined” state, it has a “local job Id”. If the job is then submitted to a measuring agent or cluster controller, the job has additionally a “remote job Id”.

From this menu you can also create Test Job Templates and edit Test Suites - which can be executed as Regression Tests.

Starting a Load Test Job

After you have clicked on “Start Test Job” in a load test job you can select/modify the Measuring Agent or Cluster of Measuring Agents on which the job will be executed, and you can configure the job settings.

Input Fields:

• Measuring Agent | Cluster: The Measuring Agent or Cluster of Measuring Agents on which the load test is executed.
• Number of Users: The number of simulated users that are started.
• Max. Test Duration: The maximum test duration.
• Max. Loops per User: The maximum number of sessions executed per user (the number of iterations of the test per user). Each time a new session of a user is started, the user’s session context is reset.
• Loop Iteration Delay: The delay time after a session of a user has ended until the next session of the user is started.
• Ramp Up Time: The length of time at the beginning of the test until all simulated users are started. Example: with 20 simulated users and a time of 10 seconds, a new user is started each 0.5 seconds.
• Additional Arguments: Additional values which are transferred on the command line when the test script is started. These arguments are test specific.
  For tests that were created with the HTTP Test Wizard you can specify following arguments which are considered by the executed URL calls:

• Debug Execution: This option effects that detailed information are written to the log file of the test. For example variable values which have been extracted from input files or from HTTP responses as well as variable values which are assigned at runtime. Only activate this option if you have problems with the execution of the test.
• Debug Measuring: Effects that the Data Collector of the Measuring Agent writes the JSON objects of the All Purpose Interface to its log file. This option can be enabled to debug self-developed tests that have been written from scratch.
• (User Input Fields): If the test contains User Input Fields you can enter their values here.

Normally you do not have to enter any “Additional Arguments” and leave “Debug Execution” and “Debug Measuring” switched off.

After clicking Start Test Job, the job is started on the Measuring Agent or Custer of Measuring Agents and is then in the state “Running”. Then click on “Monitor Jobs” and the view changes from the “Load Test Jobs” menu to the Real Time View menu.

Real Time View Menu

The real time view shows all currently running load test jobs including their measured values and errors.

You can also suspend a running job for a while and resume it later. However this has no effect on the “Max. Test Duration”.

After the job is completed you can click on “Analyze Result”. The view changes then to the Test Results menu.

Test Results Menu

The “Test Results” menu is a workspace into which you can load multiple test results from any type of test. You can also switch back and forth between the test results. All measured values and all measured errors are displayed. In addition, Percentile Statistics and Diagrams of Error Types are also displayed in this menu.

This menu enables you also to combine several test results into a so-called Load Curve - to determine the maximum number of users that a system such a Web server can handle (see next chapter).

The Summary Statistic of a test result contains some interesting values:

• ∅ Measured Samples per Second: These are the number of successful measured values per second, counted over the whole test (in other products also so-called as “hits per second”).
• Max. Concurrent Users: These are the maximum number of concurrent user that have been really reached during the test (which may differ from the “Number of Users” defined when starting the test).
• Max. Pending Samples: This is the maximum amount of requests to the server, for which no immediately response has been received, measured over the whole test (the maximum traffic jam of the requests).
• ∅ CPU Load on Measuring Agent: This is the average CPU load in percent on the measuring agent (load generator) or on the members of a measuring agent cluster - which was captured during the execution of the test. If this value is greater than 95% the test is invalid because the measuring agent was overloaded.

Since several thousand to several million response times can be measured in a very short time during a test, the successfully measured response times are summarized in the response time diagrams at 4-second intervals. For this reason, a minimum value, a average value and a maximum value is displayed for each 4-second interval in such diagrams.

However, this summarization is not performed for Percentile Statistics and for Measured Errors. Every single measured value is taken into account here.

Determining System Capacity - Load Curve

The maximum capacity of a system, such as the maximum number of users that a web server can handle, can be determined by a so-called Load Curve.

To obtain such a Load Curve, you must repeat the same load test several times, by increasing the number of users with each test. For example a test series with 10, 50, 100, 200, 400, 800, 1200 and 1600 users.

The easiest way to repeat a test is to Clone a Load Test Job. You can then enter a higher number of users when starting the cloned load test job.

Another way to run a load test multiple times with different numbers of users is to create multiple Test Tob Templates and add them to a Test Suite.

A measured Load Curve looks like this, for example:

As you can see, the throughput of the server increases linearly up to 400 users - with the response times remaining more or less the same (Avg. Passed Session Time). Then, with 800, 1200 and 1600 users, only individual errors are measured at first, then also many errors, with the response times now increasing sharply.

This means that the server can serve up to 400 users without any problems.
But could you operate the server with 800 users if you accept longer response times? With 800 users, 745,306 URL calls were successfully measured, with only 50 errors occurring. To find it out, let’s compare the detailed response times of “Page 1” of 400 users with 800 users.

Response Times of “Page 1” at 400 Users:

Response Times of “Page 1” at 800 Users:

The 95% percentile value at 400 users is 224 milliseconds and increases to 1952 milliseconds at 800 users. Now you could say that it just takes longer. However, if you look at the red curve of the outliers, these are only one time a little bit more than 1 second at 400 users, but often more than 8 seconds at 800 users. Conclusion: The server cannot be operated with 800 users because it is then overloaded.

Now let’s do one last test with 600 users. Result:

The throughput of the server at 600 users is a little bit higher than at 400 users and also little bit higher than at 800 users. No errors were measured.

Response Times of “Page 1” at 600 Users:

The 95% percentile value at 600 users is 650 milliseconds, and there are only two outliers with a little bit more than one second.

Final Conclusion: The server can serve up to 600 Users, but no more.

Troubleshooting a Load Test

In rare cases it can happen that a test does not measure anything (neither measurement results nor errors). In this case you should either wait until the test is finished or stop it directly in the “Real Time View” menu.

Then you can then acquire the test log files in the “Load Test Jobs” menu and search for errors.

Network Components Menu

The Network Components menu allows you to manage Measuring Agents, Cluster Controllers and HTTP/S Remote Proxy Recorders. In addition, you can also start additional components that you only need for a short time as AWS Cloud Instances by spending RealLoad Cloud Credits.

Measuring Agents & Cluster Controllers

On the one hand, depending on your license (Price Plan), you can add and manage Measuring Agents and Cluster Controllers that you operate yourself. On the other hand, you can also launch additional Measuring Agents and Cluster Controllers using RealLoad Cloud Credits.

How to launch and operate Measuring Agents and Cluster Controllers using your own AWS account is documented at AWS Measuring Agents.

Measuring Agents can be operated in either ‘inbound’ or ‘outbound’ network connection mode (see image below).

Note that ‘inbound’ connected Measuring Agents - usually running on TCP/IP port 8080 (HTTPS) - must be reachable form the ‘Portal Server’, and that you have to enable the corresponding inbound firewall rule.

Conversely, ‘outbound’ connected Measuring Agents do not require an inbound firewall rule, but must be able to connect to the ‘Measuring Agent Controller’. Outbound connected Measuring Agents support all product features and functionalities as inbound connected Measuring Agents, with the only exception that they cannot be a member of a “Measuring Agent Cluster”.

HTTP/S Remote Proxy Recorders

HTTP/S Remote Proxy Recorders can be used to record Web Surfing Sessions, which can then be post-processed with the HTTP Test Wizard and converted into a RealLoad Test.

The most important points here are:

• You must import the CA Root Certificate of the Proxy Recorder into the web browser with which you record the web surfing session (Firefox recommended).
• To control the Proxy Recorder in the RealLoad Portal, you need a second web browser from another manufacturer (Goggle Chrome recommended), or alternatively installation of the RealLoad Browser Extension.
• Optional: When recording, HTTPS/X509 client certificates are also supported to authenticate yourself to the corresponding web server(s) - if required. You can upload the client certificates directly in this menu. The client certificates are then automatically transferred to the proxy recorder and applied during recording.

The complete documentation is available at HTTP/S Remote Proxy Recorder.

Launched Cloud Instances (by Cloud Credits)

This menu shows (only) all AWS instances that were launched using RealLoad Cloud Credits. Here you can also terminate such instances early - whereby Cloud Credits for complete unused hours are refunded.

Wizards Menu

This menu only displays the wizards that can be accessed via direct navigation. In addition, the RealLoad product contains numerous other wizards that are accessible depending on the context.

HTTP Test Wizard

The functionalities of the HTTP Test Wizard (+ Plug-Ins and Published Plug-Ins) is documented at HTTP Test Wizard.

User Input Fields Wizard

“User Input Fields” are additional values that are entered when starting or defining a test execution and that are available as (global) variables during test execution.

With this wizard you can create or edit JSON files containing definitions of User Input Fields. By convention, the names of such files must always start with ‘InputFields_’ and end with ‘.json’.

A User Input Field contains the following attributes:

• GUI Label : The label of the User Input Field that is displayed in the user interface.
• Variable Name : The name of the global variable at test execution.
• Input Type : The datatype of the input value (String, Integer, Real or Boolean). Please note that the Input Type is only used to validate the input. During test execution, the value of the variable is always converted to a string.
• Default Value : The default value of the variable.

User Input Fields are supported by All Types of RealLoad Tests.

Tools Menu

This menu contains tools that are helpful for developing and debugging tests:

• Base64 Tool : Converts plain text to Base64 format or vice versa.
• DNS Tool : This allows you to resolve DNS hostnames through one or more specific DNS servers.
• HTTPS Server Certificate Tool : With this tool you can check the validity of HTTPS server certificates and also create your own (client) Trust Stores.
• JSON Editor : This allows you to create and edit JSON files, as well as display JSON data in a formatted view. Tip: You can also copy raw JSON data into the JSON Editor and then view it as formatted JSON data with a mouse click - without having to save the data to a file.
• PKCS12 Client Certificate Tool : With this tool you can view the contents of an SSL/X509 client certificate which is in PKCS12 format.
• Query String Tool : With this tool you can convert URL Query Strings to the unescaped format or vice versa. See Wikipedia - Query String
• Text Phrase Tool: Determines the most meaningful human-readable text phrases or keywords from any given URL with HTML/JSON/XML response content. This tool’s algorithm is also used by the HTTP Test Wizard to verify the content of HTTP responses.
• Unix Time Tool : Converts a Unix time to a formatted local time - or vice versa.
• WebSocket Tool : This allows you to test a WebSocket connection to a web server. The tool also supports SSL/X509 client certificates in PKCS12 format.
• XML Editor : This allows you to create and edit XML files.

User Account Menu

Submenus:

• Sign Out : This will sign out you out without asking. Any tests that may be running are not affected by this and will continue.
• To Welcome Page : Displays the welcome page analogously after sign up.
• Personal Data & Profile Settings : Here you can edit your personal data and also determine whether parts of it are publicly displayed in the portal.
• Team Members : Displays the list of all team members.
• Team Members Accounts : Management of team member accounts by the main user account. Team members have no access to this submenu.
• Mobile Companion : Displays a list of all mobile devices that have logged in to the portal using the Mobile Companion App. Furthermore, all push notifications that were sent to the mobile devices are displayed.
• API Authentication Tokens : Here you can create and manage authentication tokens that are used for authentication against the portal server API.
• Price Plan : Displays your current price plan and your access permissions to RealLoad resources.
• Manage Licenses : Displays your purchased licenses and allows you to add additional licenses and cloud credits.
• Cloud Credit Statement : Displays your Cloud Credit balance and a list of all Cloud Credit transactions.
• Set New Password : Here you can set a new password for your portal account.
• Delete Account : This will permanently delete your account in the portal - including deleting all data associated with your account.

The following submenus are only accessible depending on your configured “Personal Data & Profile Settings”:

• Public In-App Users : Displays a list of all portal users which are visible to other portal users. You can also contact them within the portal. This list is only shown if you are also a public portal user yourself.
• In-App Message Box : Here you can sent and display received messages to/from all portal users which are visible to other portal users.
• Chat with Signed-In Users : Opens the chat popup that allows chatting with other in the portal signed in users who have enabled this functionality in their profile settings.
• Received Contact Messages : If you have enabled “Publish My Profile as Technical Expert:” in your profile settings then all received contact messages will be displayed here.

Downloading RealLoad Components and RealLoad Libraries Java Doc

Clicking this icon will open a new browser window or tab to download.realload.com

Purchase of Licenses and Cloud Credits

Clicking this icon will open a new browser window or tab to shop.realload.com

Here you can Purchase Licenses and additional Cloud Credits.

If you have any questions, please email us at support@realload.com

4.1 - AWS Measuring Agents

This document describes how to launch Measuring Agents in AWS as EC2 instances. Readers are assumed to be familiar with AWS EC2 terms used in here, in particular if launching Measuring Agents manually.

AWS based Measuring Agents can be launched in three ways:

1. Via the RealLoad Portal
2. Via our Desktop Companion App
3. Via the AWS Console

1. Launching AWS Measuring Agents via the RealLoad Portal

Launching AWS Measuring Agents via the RealLoad portal is the easiest of the three options. You don’t need an AWS account for this, but RealLoad ‘Clouds Credits’ are required. If you run out of Cloud Credits, you can purchase new ones in the RealLoad Shop: https://shop.realload.com/  

Launching an AWS Measuring Agent using Cloud Credits

Navigate in the Portal to ‘Measuring Agents & Cluster Controllers’.

Them click the AWS icon:

Click on the rocket icon of an AWS region:

Select the ‘AWS/EC2 Instance Type’ (in this example ’t3.xlarge’) and the number of hours until the instance will be terminated (in this example 3 hours). Then click on the ‘Launch Instance’ button:

You will then receive a confirmation notification that the instance has been started. Now you have to wait at least 40 seconds until the instance gets into the running state.

The Measuring Agent is now registered in the portal. You should then ‘Ping’ it to make sure it is functional. If the Ping fails, wait another minute and then try again.

Premature Termination of an Instance - Refund of Cloud Credits

In this example, the Measuring Agent (cloud instance) was started for three hours, but the load test was performed successfully after just one and a half hours. In order to save Cloud Credits, the instance can be terminated early.

To terminate an instance launched by Cloud Credits navigate to ‘Launched Cloud Instances’:

At the relevant instance, click the ‘Terminate Instance’ icon:

Click the ‘Terminate Instance’ button:

The instance will now terminate. In this example you will receive 4 out of a total of 12 cloud credits back.

Verifying the Cloud Credit Billing

Navigate to ‘Cloud Credit Statement’ to check your Cloud Credit Balance and Transactions:

2. Launching AWS Measuring Agents via the Desktop Companion App

Launching AWS Measuring Agents via the Desktop Companion App requires that you have an AWS account.

No additional costs (beyond the costs charged by AWS) apply when using our Measuring Agent images.

Note that you need the rights to log in to the AWS Console to check whether all Measuring Agent instances that are no longer needed have been terminated.

First download, install and configure the Desktop Companion. The download links are published on https://download.realload.com  

Configuring the Desktop Companion

To configure the Desktop Companion for launching AWS Measuring Agents you need:

1. An AWS ‘Access Key’ of an AWS User which have the permission AmazonEC2FullAccess
2. A RealLoad ‘API Authentication Token’

To generate a RealLoad ‘API Authentication Token’ sign in to the RealLoad Portal and navigate to ‘My Account’ - ‘API Authentication Tokens’:

Click the ‘Add API Authentication Token’ button:

Enter as purpose ‘Desktop Companion’ and click the ‘Add API Authentication Token’ button. Then copy the shown Token Value to the clipboard or to a text editor:

Now start the Desktop Companion and configure it. Click on the File tab and then click Settings.

In the General Tab enter:

1. The Agent Secret: This is something like a password that protects the launched AWS Measuring Agents from unauthorized access. You can enter any text here, but it must not be empty.
2. The Portal URL: This is the URL of the Portal Server API and should always be https://portal.realload.com/RemoteUserAPI  
3. The Authentication Token: Enter here the RealLoad ‘API Authentication Token’.
4. Set the Refresh Interval to a value that is greater than 60 seconds.

Then click the ‘Test’ button near ‘Authentication Token’:

Switch then to the AWS Tab and enter:

1. The AWS Access Key ID
2. The AWS Secret Access Key
3. The Preferred Instance Type: We recommend that you enter t3.medium for your first attempt.
4. Set the AWS EC2 Refresh Interval to a value that is greater than 60 seconds.
5. Select at My AWS Regions your preferred AWS region(s): Multiple regions can be selected by CTRL-mouse-click. We recommend that you select eu-central-1 and/or us-west-1 for your first attempt.

Then click the ‘Test’ button near ‘AWS Secret Access Key’:

Finally, click the ‘OK’ button. The configuration is now complete.

Launching an AWS Measuring Agent

In the Desktop Companion, go to the AWS tab and select an AMI of type ‘MA’ (MA = Measuring Agent). Then launch the instance with a right mouse click:

A window will appear in which you can check the configuration of the instance and set the instance auto-terminate time period. You can also choose a value of zero for the auto-terminate time period, which means that the instance will continue to run until you stop it.

The instance is then launched and in the state ‘pending’:

Now wait until the instance reaches the ‘running’ state. Then register the instance in the portal with a right mouse click:

The instance is now also displayed in ‘Portal Agents Registration’:

Check in the RealLoad Portal whether the instance is running correctly by pinging the Measuring Agent at application level:

Terminating an AWS Measuring Agent

Note that this section only applies to Measuring Agent instance which have launched via the Desktop Companion.

Two steps are necessary to terminate an instance:

1. Terminate the instance in AWS
2. Deregister the Measuring Agent in the portal server

To terminate an instance in AWS, perform a right mouse click in the Desktop Companion - Running AWS Images in “My Regions” at the corresponding instance and select ‘Terminate’:

The instance is then in the state ‘shutting-down’. Now you can deregister the Measuring Agent in the portal server by a right mouse click:

Double-check no longer needed Instances

Because the Desktop Companion only shows Running AWS Images in “My Regions”, some instances launched in other AWS Regions may not be displayed.

Sign in to the AWS console to review Measuring Agent instances across all AWS regions. Select EC2 Global View:

In EC2 Global View click Global search and select the the tag REAL_LOAD_AGENT:

Select the operator Equals and set the value to true, then hit the return key:

If the list displayed contains one or more instances, click on the instance(s):

Memorize the instance ID and terminate the instance:

Sign in into the RealLoad Portal and delete the corresponding Measuring Agent:

3. Launching AWS Measuring Agents via the AWS Console

In EC2, first select the AWS Region where you want to launch the Measurement Agent instance.

Creating the Security Group

In order for the AMI to be reachable from the RealLoad Portal you’ll need to configure a Security Group allowing inbound TCP/IP V4 connections to port 8080 as a minimum. Optionally, you can also configure SSH access.

In the following example the security group “Real Load Agent Security Group” was created:

Launching a Measuring Agent Instance

When launching the instance click Browse more AMIs:

Then click Community AMIs, enter our (RealLoad) AWS account 775953462348 and select the Measuring Agent image:

Add the tag REAL_LOAD_AGENT = true

Select the Instance Type and set the (existing) Security Group “Real Load Agent Security Group”. Optionally you may also set a Key Pair:

Scroll down and click Advanced Details:

In Advanced Details scroll down to User Data. In order to protect access to your Measuring Agent we strongly recommend setting a non-default secret when launching the instance.

The secret can be set at launch time by providing User Data to the AMI as follows (replace “secret” with the secret of your choice):

#!/bin/sh
echo "AGENT_SECRET=secret" > /home/ec2-user/agent_secret.sh

Scroll down to the bottom of the AWS Console and click Launch Instance:

After launching the instance click on the instance ID:

Copy the Public IPv4 address of the instance to a text editor or to the clipboard:

Sign In to the RealLoad Portal and add (=register) the Measuring Agent instance:

The Agent IP Port wil always be 8080. Enter the Auth Token which you have set as AGENT_SECRET when launching the instance.

Then ping the Measuring Agent at application level:

And check the Measuring Agent Log File to verify that the Agent Secret was configured:

The Measuring Agent is now ready for operation. Don’t forget to terminate the instance when you no longer need it.

Once you have terminated the instance, you should delete the corresponding Measuring Agent in the RealLoad Portal.

4. Launching RealLoad Measuring Agents via the AWS Marketplace

You can also launch the Measuring Agent from the AWS Marketplace. The offering is currently free of charge, you won’t incur any subscription charges from us. You’ll still incur AWS EC2 infrastructure costs when launching an EC2 instance.

Subscription process

You’ll find our offering on the AWS Marketplace   by looking for “RealLoad” or directly at this URL   . Then click on the Purchase Options button.

Review the offering terms and then accept.

You’ll then see the purchase confirmation. It might take a couple of minutes for the purchase to be confirmed.

Once the purchase process has completed, you’ll receive a confirmation email.

To access all AWS purchases, click on the link provided in the email, and you’ll be taken to a screen listing all products you’ve purchased including our offering.

Click on the launch link to launch an EC2 instance of the Measuring Agent:

Select the AWS Region where you want to launch the instance:

Follow the prompts on the next screens as per your requirements, which might vary depending on your AWS topology.

Select an appropriate instance type (c5.large is a good starting point). There is no need to provide an SSH key to login to the EC2 instance, unless you need to perform some sort of troubleshooting.

One key requirement is for the RealLoad portal being allowed to connect to the Measuring Agent EC2 instance.

The marketplace offering, by default, will set the option to assign a public IPv4 address to the EC2 instance and allow connections to the required ports, as shown in this screenshot:

We recommend setting a secret on the Measuring Agent, to ensure nobody else can use your instance.

To set a secret, copy and paste the following text into the User Data field, replacing the “secret” string with whatever secret you’d like to use.

#!/bin/sh
echo "AGENT_SECRET=secret" > /home/ec2-user/agent_secret.sh

Once the instance has launched, proceed to configure the Measuring Agent in the RealLoad portal:

The Agent IP Port wil always be 8080. Enter the Auth Token which you have set as AGENT_SECRET when launching the instance.

Then ping the Measuring Agent at application level:

And check the Measuring Agent Log File to verify that the Agent Secret was configured:

The Measuring Agent is now ready for operation. Don’t forget to terminate the instance when you no longer need it.

4.2 - Azure Measuring Agents

This document describes how to launch Measuring Agents in Azure as VM instances.

Measuring Agent offering in the Azure Marketplace

Azure based Measuring Agents can be launched from Azure’s Marketplace. Use this link   to find the offering or enter “RealLoad” in Azure’s search bar:

You should find the following offering:

Launch a VM instance, CPU and memory settings

Click on the “Create” button and select a VM size. For evaluation purposes, a VM with 2GBs of memory will suffice. The memory and CPU sizing will vary depending on length of the performance test to be executed, number of concurrent VUs and amount of data transferred.

Setting an SSH key on the virtual machine is not required, as typically you wouldn’t have to login at the OS to the VM instance.

Disk settings

You can configure the disk to be destroyed on VM termination, as all collected measurements should have been transferred back to the RealLoad portal by the time the VM is destroyed.

Network settings

The VM requires a public IP address, so that it can be reached from the RealLoad portal   server. There is no strict requirement to retain the IP address after termination of the VM instance.

Auto shutdown settings

Optionally you can configure the instance to automatically shutdown at a time when you’re sure that your test execution has been completed.

Setting the agent secret

In order to configure the Agent Secret you’ll need to base64 encode the following string:

AGENT_SECRET=secret1234

Replace “secret1234” with the secret you’d like to use to protect access to the agent.

To Base64 encode the above string, you can use Notepad++ or the Base64 tool   available in the RealLoad portal   :

After encoding the string paste it into the “User Data” field.

After this screen, click on Create to start the Virtual Machine and wait until it has launched.

Obtaining the VM’s external IP address

Once launched, obtain the VM’s external IP address from the VM overview screen. You’ll need the IP address in the next steps, to configure the Measuring Agent instance on the RealLoad portal   .

Configuring the agent on the ReaLoad Portal

Now that the Measuring Agent is launched, you can configure it in the RealLoad Portal, in the Measuring Agents   section:

Click on the “Add Measuring Agent” button and then enter the agent’s IP address and secret.

Verifying connectivity to the agent

Once configured, you can verify connectivity to the Measuring Agent by using the “Ping Agent” functionality:

The result should indicate that the agent is reachable.

Troubleshooting

Connectivity issues

Port Filtering (Security Rules)

When launching the offering, a firewall rule should automatically have been added to allow inbound connections on port 8080.

You can verify connectivity on a Windows computer using powershell, as follows:

Test-NetConnection -ComputerName ip_address_of_agent -Port 8080

On Linux/MacOS you can use openssl:

openssl s_client -connect agent_ip_address:8080

If the result indicates that port 8080 is closed, then check the Azure network security group associated to the VM instance to make sure that port 8080 is actually open:

Other issues

For any other issues please contact us at support@realload.com .

4.3 - Measuring Agent Cluster

This document describes how to combine multiple Measuring Agents into a Cluster and how to run heavy-duty Load Tests.

If you want to perform heavy-duty Load Tests with almost unlimited load, you need a Cluster of Measuring Agents. Or to put it another way: you need a RealLoad ‘Cluster Controller’ to which you can assign up to several hundred of Measuring Agents.

A ‘Cluster Controller’ is a component of the RealLoad architecture that is running as an independent OS process and combines multiple Measuring Agents under one hat. Normally a ‘Cluster Controller’ runs on its own, separate machine whereby the cluster members must be reachable from the ‘Cluster Controller’.

Measuring Agent Clusters Features

• From an external perspective - that is, from the user interface - the cluster behaves the same as a normal load generator (Measuring Agent). As usual, you can start load test jobs on the cluster, view their progress in real time, and evaluate the test results.
• The test results of the cluster members are automatically combined into one result both in real time and during evaluation.
• The content of Input Files can be split over the cluster members.
• The capacity of the cluster scales linearly with the number of cluster members - there is no cluster overhead during execution of a test.
• Up to several hundred of ‘Measuring Agents’ can be combined to a cluster.
• By using RealLoad ‘Cloud Credits’, you can start a high-performance cluster in just a few minutes at any time - at low cost and without any preparation time.
• RealLoad ‘Cluster Controllers’ can also launched by using your own AWS account and can also be installed manually on self-hosted systems.
• After you have got a ‘Cluster Controller’ up and running, the assignment of Measuring Agents can be done very easily via the user interface with a few mouse clicks, without having to configure any JSON or XML files.
• Depending on the number of cluster members and their CPU resources and memory, you can execute load tests with millions of concurrent users. RealLoad is probably one of the the most powerful load testing tool on this earth - and available at an unrivaled competitive price.

The following screenshots are for educational purposes only and show the setup and use of a small cluster.

Launching Cluster Members using Cloud Credits

In this example 3 cluster member are started:

The following steps are repeated 3 times:

Select the Image ID in your preferred AWS region. If your preferred AWS region is not listed, contact support@realload.com - we will then provide you with an appropriate AMI.

Input Fields:

• AWS/EC2 Instance Type : Select an AWS/EC2 instance type. Rule of Thumb for HTTP Test Wizard tests: per EC2 vCPU, 100 virtual users can simulated.
• Terminate Instance after : Select a sufficiently long time period to carry out your test, with some reserve time. Please note that the time period cannot be extended. Cloud credits for completely unused hours will be refunded if you manually terminate the instance early.
• Access Authentication Token : A random value is displayed as default. You can leave it like that.

After you click on ‘Launch Instance’ a confirmation will be displayed. You don’t have to wait any longer and can launch the next Measuring Agent immediately.

After launching the 3 Measuring Agents it looks something like this:

Launching a Cluster Controller using Cloud Credits

After you have launched all cluster members, you can launch the Cluster Controller:

It is recommended to launch the Cluster Controller in the same AWS region where the cluster members are located.

It is recommended to select the same AWS/EC2 Instance Type as for the cluster members. And of course you must select the same value for Terminate Instance after as you have selected for the cluster members.

Now you have to wait at least 40 seconds:

Then ‘Ping’ the Cluster Controller.

If you get an error, wait another minute and then try pinging again.

Assigning Cluster Members to the Cluster

Before you can use a cluster, you must assign cluster members to it. Click on the number of cluster members shown:

Then add the members to the cluster …

… and click ‘Apply’:

Then ‘Ping’ the cluster members via the Cluster Controller:

If no error is displayed, the cluster is now ready for use:

Executing Load Tests using a Cluster

Load Tests Jobs that are executed by a cluster are started in (almost) exactly the same way as load tests jobs that are started on a single Measuring Agent.

When starting a Load Test Job, you simply select the cluster instead of a Measuring Agent:

If the job contains Input Files, you can split their contents among cluster members if necessary:

The Real Time View shows the summarized results of all cluster members. By clicking on the cluster icon you can view details about the cluster members:

After the job is completed you must load the test result immediately. This is because it can no longer be loaded once the cluster controller has been terminated.

The test result shows the summarized results across all cluster members. By clicking on the cluster icon you can view the result of each cluster member. If errors were measured, it is also displayed for each error on which cluster member it occurred on.

Note: After the Cluster Controller instance has been terminated, a warning will be displayed at the corresponding load test jobs - this is normal behavior and not a problem:

4.4 - Recording of a Web Surfing Session

This document describes how a Web Surfing Session can be recorded by using a HTTP/S Remote Proxy Recorder and then post-processed in the HTTP Test Wizard. After post-processing, a RealLoad Test can be generated.

Hint: As an alternative to using an HTTP/S Remote Proxy Recorder, you can also record web sessions using Desktop Companion.

Preconditions

The following assumes that a Firefox web browser is used for recording and that the CA Root Certificate of the HTTP/S Remote Proxy Recorder has already been imported into Firefox.

You must also have the ‘RealLoad Test Recorder’ browser extension installed in Firefox. It is recommended to only turn on this browser extension when recording a Web Surfing Session.

Preparing Firefox for Recording

The following text describes how to copy and paste a HTTP/S Remote Proxy Recorder Configuration into the Firefox ‘RealLoad Test Recorder’ browser extension.

You now need two web browsers from different manufacturers:

• The Firefox browser
• A Chrome browser that is signed-in into the RealLoad portal

In Firefox navigate to Manage Extensions

At the RealLoad Test Recorder extension click Options

Now use the Chrome browser, sign in to the RealLoad portal, navigate to the HTTP/S Remote Proxy Recorders menu, and Connect to the Proxy Recorder

After you are connected to Proxy Recorder with the Chrome browser, click on the ‘Red Eye Icon’ and copy the ‘Proxy Configuration Data’ to the Clipboard by clicking the corresponding icon

Then paste the ‘Proxy Configuration Data’ to the Firefox ‘RealLoad Test Recorder’ browser extension and click ‘Save’

Firefox is now ready for recording.

Tip: You can also Pin the ‘RealLoad Test Recorder’ browser extension to the Firefox Toolbar:

Recording a Web Surfing Session

The following example shows the recording of the purchase of a Cinema Voucher in the RealLoad Cinema Demo Shop.

cinema.realload.com is a public server available to you for educational purposes.

In the Chrome browser connect via portal to the Proxy Recorder and click on the ‘Red Eye Icon’:

In Firefox click the ‘RealLoad Test Recorder’ browser extension. When you are asked for the Proxy Authentication then paste the username and password shown in Chrome.

In the ‘RealLoad Test Recorder’ browser extension first enable Clear Cache & Cookies and then click Start Recording

In Firefox enter the URL https://cinema.realload.com/shop   which is the starting point of the recorded session.

Optional: Have a look at Chrome and you will see that the first web page is recorded:

A cinema voucher will now be added to the shopping cart. In Firefox first insert a ‘Page Break’ with the comment ‘Add Cinema Voucher’, and then click on ‘Add to Chart’ in the shop:

Add another Page Break with the comment ‘Goto Chart’, and then click the Cart Icon:

The shopping cart is now displayed. Add another Page Break with the comment ‘Checkout and Pay’, and then click ‘Checkout and Pay’:

The receipt will be displayed and the recording is now complete.

In the ‘RealLoad Test Recorder’ browser extension, click Stop Recording:

Now return to the Chrome browser and click on ‘Refresh’. As you can see, a lot of URLs were recorded that were unwanted in your test. Click on URL Filter - Quick Settings to filter out the unwanted URLs:

Exclude any web servers that you do not want to be part of your test. In particular, you should exclude any tracking servers.

Then save the recorded session. You can later re-load the recorded session to (any) proxy recorder and filter it again:

After completing the recording, it is strongly recommended to switch off the ‘RealLoad Test Recorder’ browser extension. Only turn this browser extension on again when you record a new web surfing session.

Converting the Recording to an HTTP Test Wizard Session

In the HTTP/S Remote Proxy Recorder click ‘Convert’

Enter the Headline of the HTTP Test Wizard session (in this case ‘Purchase Cinema Voucher’) and click ‘Convert’:

The recording will now be converted and appears in the HTTP Test Wizard. We recommend that you save the HTTP Test Wizard session first before you start post-processing.

Post-Processing of the HTTP Test Wizard Session

Handling of Dynamic Session Values

If a dynamic value such as a order number is part of an HTTP response, and that value is then used in subsequent HTTP requests, you must handle this value using a dynamic session variable.

To identify such dynamic values, you can use the Variables Wizard, which you can access via the HTTP Test Wizard. First click on URL Explorer

Then in the URL Explorer click Variables Wizard

Now a list of Distinct Transmitted Values is shown in the Variables Wizard, which is extracted from all HTTP request of the session. The challenge now is to estimate which of these values are dynamic (static values do not need to be handled).

As a rule of thumb:

• if the value is a simple speaking word, or a combination of simple speaking words, or a small number, it is probably a static value.
• However, if the value is a complex, random string, it is probably a dynamic value.

In the image below there is only one dynamic value (receiptId = e1bjlSo9CoJLR9TL). Click on the magnifying glass icon to handle this value:

The session is now searched for this dynamic value e1bjlSo9CoJLR9TL. Click on the first search result of an HTTP response:

In this example, the HTTP response is in JSON data format. So click on the JSON tab:

Then click on the value of receiptId, and then click Test Extractor and enter a new Variable Name ‘(vReceiptId’ in this case). Finally enable the switch Assign Extracted Value as Variable to All Subsequent HTTP Requests and click the Define Variable Extractor button.

The handling of the dynamic session variable is now complete. Click the ‘Variables’ icon to check the variable extractor and variable assigners:

After you have processed all dynamic values, you should save the session again.

Reviewing the HTTP Response Content Validations

When the recording was converted, the verification of the HTTP responses were also automatically configured.

The received HTTP status code of each URL is always checked for the value it had at the time of recording. However, some URLs may also be automatically configured to additionally validate the response content against a text fragment. You should review these URL-specific text fragments and correct them if necessary.

In the HTTP Test Wizard click on Review and Edit URL Settings

Take a look at table column ‘V. Text’ and click on the text fragment wizard icons:

For example, for the URL https://cinema.realload.com/shop, it is better to choose the text fragment ‘RealLoad Cinema Demo Shop’ instead of ‘clone the product card template’:

After you have reviewed the content validations of the HTTP responses, you should save the session again - if you have made any changes.

Debugging an HTTP Test Wizard Session

After you have completed the post-processing, we recommend that you debug the HTTP Test Wizard session.

Since this is a Remote Debugger, you can choose which Measuring Agent the debugger runs on. This means you can also debug the session from different geographical locations.

Click on ‘Next Step’ until you reach the end of the session - or until an error is displayed. During debugging you will also see when the value of dynamic session variable is extracted from an HTTP response and when it is assigned to an HTTP request.

Generating a RealLoad ‘Test’ from an HTTP Test Wizard Session

If you were able to debug the session without errors, you can now generate a RealLoad Test from it. Click on ‘Generate Code’:

First click on ‘Generate Source Code’ and then on ‘Compile & Generate JAR’:

Then click ‘Define New Test’:

You can adjust the name of the test a little (it can also contain spaces). Then click on ‘Define New Test’:

Your browser will now be redirected to the ‘Tests’ menu and the test will appear at first position (if the sorting is set to descending test ID).

From here you can continue as described at the Tests Menu.

4.5 - HTTP Test Wizard

Overview and Functionality

The HTTP Tests Wizard supports you to create sophisticated tests in an easy way. You can:

• Compile (define) the Entire Test via the User Interface
• or Post-Edit a Recorded Web Surfing Session

As the name suggests, the HTTP Tests Wizard is optimized for the execution of HTTP/S tests. However, by using HTTP Tests Wizard Plug-Ins, any other protocols can also be tested and measured (similar to JUnit Tests).

HTTP Tests Wizard Features:

• No programming required (except for self written plug-ins). You can create your test through the powerful user interface by assembling all required functionalities via simple dialogs.
• Variables can be defined and their values can be extracted and assigned directly via the user interface.
• A powerful debugger helps you to perfect your test.
• The defined test can be automatically converted into a performance-optimized RealLoad Test.

Session and Session Elements

The test sequence is referred to as a so-called “Session”, whereby each simulated user repeatedly executes the session in a loop (so called “User Session” or “Session Loop”).

In order to define a test sequence, you can add various Session Elements to a session:

• User Input Field : An additional input field whose value can be entered when starting the test and that is defined as a global variable during the test.
• Measurement Group : Measures the execution time over several session elements.
• URL : Executes an HTTP request and receives and verifies the HTTP response. The URL can executed either synchronously or in parallel with other URLs. (see also URL Synchronisation Point). One or more “Bound to URL Plug-Ins” can also be added to a URL which, among other things, can modify the HTTP request and post-process the HTTP response.
• URL Synchronisation Point : Synchronizes URLs executed in parallel (waits until the last HTTP response has received).
• Delay Time : Delays the execution of the user session for an amount of time.
• Basic Authentication : Adds a Basic Authentication username and password to the URLs, for all Web servers or for a specific Web server.
• SSL/TLS Client Certificate : Adds SSL Client Certificate(s) in PKCS12 format for a specific HTTPS server.
• General Request Header Field : Adds a HTTP request header field (for example “User-Agent”) to the URLs, for all Web servers or for a specific Web server.
• Cookie Modifier : Sets/Extracts/Deletes HTTP cookies.
• Outbound IP Address : Supports to use multiple outbound IP addresses on Measuring Agent(s) when executing the test.
• Conditional Jump : Performs a conditional jump (conditional GoTo) to any other session element.
• Plug-In : Executes a “Normal Session Element Plug-In”.
• Input File : Reads an input file line by line, tokenizes each line and extracts the values of the tokens into variables.
• Output File : Stores the values of variables into an output file.

Position of an Added Session Element

If an (existing) session element is selected, the new session element is inserted after it. Or if no session element is selected, the new session element will be added at the end of the session.

Copy / Cut / Paste and Delete of a Single Session Element

By clicking on the index of a session element, you can copy, cut, paste, and delete it. You can also disable and re-enable the execution of the session element.

Copy / Cut / Paste and Delete of Multiple Session Elements

By clicking on the ‘Select Multiple Session Elements’ icon, you can copy, cut, paste, and delete multiple session elements:

Displaying and Defining Variables

By clicking on the ‘Variables’ icon the list of all variables is shown. Here you can also define new variables and modify their scope and default value. Furthermore all extractors and assigners for each variable are displayed:

Scopes of Variables

A variable can have the following Scope:

• Global : There is only one instance of this variable during test execution. Such a variable is visible across all simulated users and their session loops. The initial (default) value is assigned at the start of the test.
• User : There are as many (different) instances of this variable as there are users simulated during a test - this means that each simulated user has its own instance. Such a variable is visible across all session loops of the simulated user. The initial (default) value is assigned when the simulated user starts.
• User Session : For each session loop of a user, a new instance of the variable is created, which is only valid and visible during the corresponding session loop. The initial (default) value is assigned at the start of each session loop of a user.

Extractors and Assigners for Variables

• A Variable Extractor defines how the value of a variable is extracted from a session element. The value is typically extracted from an HTTP response of a URL, or from a User Input Field, or from an Input File. Values can also be extracted from many other session elements, such as from HTTP Cookies or from Plug-Ins.
• A Variable Assigner defines how the value of a variable is assigned to a session element. The value is typically assigned to an HTTP request of a URL, but can also be assigned to many other session elements, such as to Plug-Ins or to HTTP Cookies.

See also Handling of Dynamic Session Values.

URL Explorer

With the URL Explorer you can view and search the HTTP data of the URLs, and also post-edit (extract and assign) dynamic session values.

Post-Editing Recorded Sessions

See Handling of Dynamic Session Values.

Post-Editing Manually Entered Sessions

If you entered the session manually (i.e. did not record it with a proxy recorder), the HTTP data for the URLs will be empty because they are currently unknown. However, you can use the debugger and handle dynamic session values directly in the debugger:

All definitions regarding variables that you make in the debugger are transferred directly to the HTTP Test Wizard session.

There is another option in the debugger where you can transfer the HTTP data from the URLs into the URL Explorer by clicking on each executed URL at the HTTP response to the ‘Set/Update Recorded URL’ icon:

Afterwards it will look something like this in the URL Explorer and you can continue as described at Handling of Dynamic Session Values.

Reviewing and Editing multiple URLs

After you’ve finished post-editing the session - and the session is working with the debugger - you should take a look at the content verification of the HTTP responses of all URLs. For example, maybe you forgot to verify the HTTP response status code for some URLs. For this purpose invoke the ‘Review and Edit URL Settings’ wizard:

You can also select several URLs here and edit them together:

We also recommend you take a look at Reviewing the HTTP Response Content Validations.

Configuring Parallel URL Execution

A ’normal’ browser loads certain URLs of a website in parallel. For example, images are loaded in parallel. The same behavior can also be achieved in the HTTP Test Wizard by calling the ‘AutoConfig Asynchronous URL Execution’ wizard. However, please note that this wizard is not perfect - you will probably need to manually adjust the execution of the URLs

After calling the wizard, the execution of the URLs will look like this, for example:

Of course, not all URLs are executed in parallel at the same time. As with a web browser, the HTTP requests are first entered into a queue and then processed by a few working threads (typically 4 threads).

By calling the wizard again you can undo the configuration.

Generating a RealLoad ‘Test’ from an HTTP Test Wizard Session

This is documented at Recording of a Web Surfing Session.

Detailed Doc of Session Elements

User Input Field

“User Input Fields” are additional values that are entered when starting or defining a test execution and that are available as (global) variables during test execution.

A User Input Field contains the following attributes:

• GUI Label : The label of the User Input Field that is displayed in the user interface.
• Variable Name : The name of the global variable at test execution.
• Input Type : The datatype of the input value (String, Integer, Real or Boolean). Please note that the Input Type is only used to validate the input. During test execution, the value of the variable is always converted to a string.
• Default Value : The default value of the variable.

See also Starting a Load Test Job

Measurement Group

Adding Measurement Group(s) is optional and causes the execution time of all subsequent session elements to be displayed in aggregate. The end of a measurement group is defined by either adding another measurement group or reaching the end of the session.

Note: If you Record a Web Surfing Session using a Proxy Recorder, a measurement group is automatically added to the session every time you enter a Page Break.

URL

When adding an URL you have at least to select the HTTP Method (for example GET) and to enter the absolute URL (https://<host>/path).

Checking the HTTP response code is optional, but strongly recommended, as otherwise the test result may contain false positive results.

The following fields can be entered or selected:

• General Area
  • HTTP Method: Select the HTTP method (GET, POST, …).
  • URL: Enter an absolute URL, inclusive (optional) query string parameters. Example: https://www.dkfqa.com/?v=1&w=2
  • Execute - synchronous or asynchronous: Determines whether the URL is executed synchronously or in parallel with other URLs (= asynchronous). If you choose “asynchronous” then you have also to add an URL Synchronisation Point to the test sequence after the asynchronous executed URLs.
  • Error Handling: Select what happens if the HTTP request fails or if the HTTP response is invalid. “Final End” means that the whole test is aborted.
  • Enable Implicit Assigners ${<variable-name>}: If checked, then placeholders for variables are considered in the URL as well as in the HTTP request header and content. Example: URL = https://${vHost}/?v=1&w=2, Variable vHost = “www.realload.com”, Result = https://www.realload.com/?v=1&w=2 . Note: instead of using implicit Assigners you can also define Variable Assigners.
• HTTP Request Content Area | Only fill in this area if the HTTP request contains a content, for example for POST requests.
  • Request Content Type: Select or enter the request content type. For example “application/x-www-form-urlencoded” or “application/json”.
  • Request Content Charset: Select or enter the request content charset - or let the field blank if not applicable.
  • Direct Value or Read From File: Select if the request content data are directly entered here or are read from a file.
  • Request Content Data: Enter the request content data (if they are not read from a file). Note: select first the Request Content Type before you enter the Request Content Data.
  • Also send Zero Content Length: If checked, but no content is available, the HTTP request header field “Content-Length: 0” is sent.
• Additional HTTP Header Fields Area
  • You can enter additional HTTP request header fields here which are only applied for this URL. Note: additional HTTP request header fields that apply to all URLs should instead be defined by using a General Request Header Field session element.
• Verify HTTP Response Area | Note: you should configure at least a HTTP response code in order to verify the test result.
  • Verify HTTP Status Code: Select the expected HTTP response code(s).
  • Verify Content Type: Select the expected HTTP response content type(s).
  • Verify Content Text: Enter text fragments that must be present in the HTTP response content, or let the fields blank if not applicable.
• Plug-Ins Area
  • Here you can add Bound to URL Plug-Ins.

URL Synchronisation Point

If you have manually added URLs and configured them to run in parallel (asynchronous) with other URLs, you must add a URL Synchronisation Point after the end of all URLs running in parallel.

See also Configuring Parallel URL Execution

Delay Time

This session element delays execution for a certain time.

The following fields can be entered or selected:

• Title : The title or description (optional).
• Delay Time : The delay time in milliseconds.
• Random Deviation : The random deviation in percent of the Delay Time. Example: if the delay time is 4000 ms and the random deviation is 50% then the randomized delay time that is applied is between 2000 ms and 6000 ms.

Basic Authentication

This session element adds a Authorization: Basic <credentials> HTTP request header field to the HTTP requests of the URLs.

The following fields can be entered or selected:

• Apply for Host : The DNS hostname or the IP Address of the Web Server to which the authentication is sent, or ‘*’ = all Web Servers.
• Apply for Port : The TCP port of the Web Server to which the authentication is sent, or ‘*’ = all Web Servers.
• HTTPS only : If checked, basic authentication will only be sent over encrypted HTTPS connections.
• Direct Value : If checked, the Username and Password can be entered directly. The same value is applied for all simulated users.
• Read Values from Input File : If checked, the Usernames and Passwords are read from an (already defined) Input File. The Scope of the Input File determines how the usernames and passwords are assigned to the simulated users.
• Username : The username (direct value).
• Password : The password (direct value).
• Input File : Select an Input File session element here (if ‘Read Values from Input File’ is checked).
• Username Token No. : Select the token number of the Input File from which the Username is extracted.
• Password Token No. : Select the token number of the Input File from which the Password is extracted.

SSL/TLS Client Certificate

Using this session element, one or multiple SSL/TLS Client Certificates can be configured, which are used for HTTPS server authorization.

The following fields can be entered or selected:

• Apply for Host : The DNS hostname or the IP Address of the HTTPS server.
• Apply for Port : The TCP port of the HTTPS server.
• Single Certificate : If checked, the PKCS12 File can be selected and the Password of the Certificate can be entered directly. The same certificate is applied for all simulated users.
• Multiple Certificates referenced by Input File : If checked, the File Names of the PKCS12 Files and the corresponding Passwords of the Certificates are read from an (already defined) Input File. Note that the PKCS12 Files must be located in the same Project/Resource Set where the Input File is located. The Scope of the Input File determines how certificates are assigned to the simulated users.
• Certificate Password : The password of the certificate (if ‘Single Certificate’ is checked).
• Input File : Select an Input File session element here (if ‘Multiple Certificates referenced by Input File’ is checked).
• PKCS12 File Token No. : Select the token number of the Input File from which the PKCS12 File Name is extracted.
• Certificate Password Token No. : Select the token number of the Input File from which the Password of the Certificate is extracted.

General Request Header Field

This session element adds a HTTP request header field to the HTTP requests of the URLs.

The following fields can be entered or selected:

• Header Field Name : The name of the HTTP request header field. Example: ‘User-Agent’
• Apply for Host : The DNS hostname or the IP Address of the Web Server to which the HTTP request header field is sent, or ‘*’ = all Web Servers.
• Apply for Port : The TCP port of the Web Server to which the HTTP request header field is sent, or ‘*’ = all Web Servers.
• Direct Value : If checked, the value of the HTTP request header field can be entered directly. The same value is applied for all simulated users.
• Assign Value from Variable : If checked, the value of the HTTP request header field is assigned by a Variable. The Scope of the Variable determines how the value of the HTTP Request Header Field is assigned to the simulated users.
• Direct Value : The value of the HTTP Request Header Field (if ‘Direct Value’ is checked).
• Variable : Select a Variable here (if ‘Assign Value from Variable’ is checked).

Cookie Modifier

Using this session element, HTTP Cookies can be manipulated - regardless of whether they are “HttpOnly cookies” or not.

Tip: You can use the Debugger to examine the cookies.

Extract Cookie Value

Extracts the value of a cookie into a variable. The following fields can be entered or selected:

• From Cookie Name : The name of the cookie.
• Cookie Domain : The domain of the cookie.
• Cookie Path : The path of the cookie.
• To Variable : Select a Variable here to which the value of the cookie is assigned.

Assign Cookie Value

Assigns the value of a variable to the value of a cookie. The following fields can be entered or selected:

• From Variable : Select a Variable here whose value is assigned to the cookie.
• To Cookie Name : The name of the cookie.
• Cookie Domain : The domain of the cookie.
• Cookie Path : The path of the cookie.

Add/Set Cookie

Adds or overwrites a cookie. The following fields can be entered or selected:

• Cookie Name : The name of the cookie.
• Cookie Domain : The domain of the cookie.
• Cookie Path : The path of the cookie.
• Variable: Value : Select a Variable here whose value is assigned to the cookie value.
• Secure Only : If checked, the cookie will only be sent over encrypted HTTPS connections.
• Session Cookie : If checked, the cookie is only valid in the session loop of the simulated users (all session cookies will be cleared before each iteration of a session loop).
• Persistent Cookie : If checked, the cookie is a permanent cookie.

Delete Cookie

Deletes a cookie. The following fields can be entered or selected:

• Delete Cookie Name : The name of the cookie.
• Cookie Domain : The domain of the cookie.
• Cookie Path : The path of the cookie.

Delete All Session Cookies

Deletes all session cookies.

Delete All Cookies

Deletes all cookies.

Outbound IP Address

The dynamic assignment of multiple outbound IP addresses for the executed URLs of the simulated users is only possible if you operate specially configured Measuring Agents yourself - or have them operated by us.

Basically, every internet device only has a single routable IP address. However, each operating system can be reconfigured so that it supports multiple IP addresses - if the network environment allows it and the additional IP addresses are also routable.

The Outbound IP Addresses are set by a Variable (often extracted from an Input File), where the Scope of the Variable determines how the Outbound IP Addresses are assigned to the simulated users.

Conditional Jump

This session element performs a conditional jump (conditional GoTo) to any other session element, based on a fixed value or on the value of one or several variables. The number of jumps is counted and can also control the conditional execution.

Conditional Jumps are based on a Conditional Expression whose result is always true or false. If the condition is true, the test execution of the currently executed user session jumps to the addressed (target) session element.

Two types of Condition Interpreters are supported:

• Boolean Expression, such as 1 <= 2
• Boolean Regex, such as (.)Zurich(.)

One or multiple Placeholder for Variables in the format ${variable-name} can be used at any point in a Conditional Expression:

• Example of Boolean Expression with a placeholder variable: ${X} <= 2
• Example of Boolean Regex with a placeholder variable: (.)${Y}(.)

Functionality of the Boolean Expression Interpreter

The Boolean Expression Interpreter supports:

1. The simple keywords true and false (without further text) which effects that the interpreter always returns true or false.
2. Simple conditional expressions, such as 10 > 9 | Note: simple expressions are not enfolded by brackets.
3. Boolean expressions with two conditional expressions, such as (5 > 6) || (6 > 5)
4. Multiple boolean expression, such as ((5 > 6) or (6 > 5)) and ("Meier" contains "ei")

Supported comparison operators:

• <
• <=
• ==
• >=
• >
• !=
• contains
• !contains

Supported boolean operators:

• && or alternatively the keyword and
• || or alternatively the keyword or

Parsing of values:

1. First the interpreter tries to convert values into numbers. If this succeeds for both values of a conditional expression, the comparison is performed with the numbers.
2. If one of the values cannot be converted into a number, both values are interpreted as text and compared as text.
3. Simple text values cannot contain spaces. However, it is supported for text values to be enclosed in double quotes, which circumvents this restriction.

4. Text values enclosed in double quotes are not converted to a number.

Functionality of the Boolean Regex Interpreter

The Boolean Regex Interpreter requires two arguments:

1. The input to which the Regex is applied. This is always referenced by a variable whose value is interpreted as Regex input.
2. The Boolean Regex itself which can contain placeholder for variables. The values of the placeholder variables are replaced first, before the Boolean Regex is evaluated.

Jump To : Target Session Element

A target session element can be:

• A fixed session element : That means that the jump is always made to this session element, regardless of whether new session elements are added or existing session elements are deleted.
• A Session element addressed by element index : That means that the jump is performed to the index of a session element. In case if session elements are added or deleted, the jump target may change - you may need to reconfigure the conditional jump settings in such a case.
• A Session element addressed by a variable whose value is interpreted as (integer number) element index. This allows dynamic jumps.

Jump Action

The jump action is performed when the jump is executed (if Conditional Expression == true):

• None (no specific action)
• Set Variable Value : When jumping, the variable is set to this value.
• Incr/Decr Variable : When jumping, the value of the variable is interpreted as (long) integer number and incremented or decremented by the configured amount.

Max. Number of Jumps

This is the limit of the maximum executed jumps per user session (per session loop) - applied to this conditional jump. For jumps back to previous session elements, this limit should never be ‘unlimited’, otherwise this can end in an endless loop.

After this limit has been reached, the Action: If Max. Number of Jumps Exceeded rules what happens next.

Action: If Max. Number of Jumps Exceeded

One of the following actions can be configured if the limit of ‘Max. Number of Jumps’ is exceeded for this conditional jump:

• No Further Jump : Recommended for simple inner loops.
• Abort User Session and Report Error : The simulated user aborts the current session and will continue with the next session (if the maximum number of outer session-loops per user is not reached).
• Abort User and Report Error : The simulated user is terminated - but all other simulated users continue to run.
• Abort Test and Report Error : All simulated users will be stopped and the test execution will be aborted prematurely.

Plug-In

See Plug-Ins.

Input File

Input files are text files (*.txt, *.csv) whose content is read line by line during the test. Each line is divided into tokens from which values of variables are extracted. Empty lines are skipped. Note that the variables whose values will be extracted from the input file must first be defined before you can add an input file.

The following fields can be entered or selected:

• Token Delimiter: The token delimiter. This is usually a single character, but can be also a string.
• Comment Tag: Lines which are starting with the comment tag are skipped. You can place also the comment tag within a line which means that the remaining part of the line is ignored. The comment tag is usually a single character, but can be also a string.
• Cyclic Read: If not checked, then the test will end when no further line can be read (at eof). On the other hand, if checked, the file is re-read after the end of file was reached.
• Randomize Lines: if checked then the order of the lines is randomized each time when the file is read.
• Trim Values: If checked then whitespace characters are removed from the start and end of the extracted values (tokens).
• Remove Double Quotes: If checked then double quotes are removed from the extracted values (tokens).
• Scope: Get Next Line per:
  • Global: Reads only a single one line of the file. The line is read at the start of the test.
  • User: Reads each time a line from the file when a simulated user is started.
  • User Session: Reads each time a line from the file when a simulated user starts a new session loop iteration.
• 6x Variable - Token[Index]: You can configure up to 6 token indexes whose values are extracted into variables.

Output File

Output files are text files (*.txt, *.csv) into which values of variables are written. The file is saved in the output directory of the test job.

The following fields can be entered or selected:

• Output File Name: The name of the output file.
• Scope: Write Line per:
  • Global: Only a single line is written to the file at the end of the test.
  • User: Each time a simulated user’s execution ends, a line is written to the file.
  • User Session: At the end of each execution of a session loop of any simulated user, a line is written to the file. If the session loop is aborted (for example because an error was measured), no line is written.
• Value Separator: The separator between the values.
• Enclose Values: Here you can configure how the values are enclosed.
• 6x Variable: Up to 6 Variables can be selected

Plug-Ins

Plug-Ins are reusable HTTP Test Wizard extensions that are manually programmed. They can also be published by manufacturing users and imported by other users. Therefore, before you start programming your own plug-in, take first a look at the already published plug-ins.

Plug-In Types

There are 3 types of plug-ins:

• Normal Session Element Plug-Ins: As the name suggests, such plug-ins are executed as a normal session element. This type of plug-in is versatile and can, among other things, process variables, abort the current session, the user or the entire test, or even perform independent measurements with any protocol.
• Bound to URL Plug-Ins: Such plug-ins are linked to a URL session element and can change the HTTP request before sending it to the server and post-process the received HTTP response - such as extracting variable values or checking the content of the HTTP response. Such plug-ins can also abort the current session, the user, or the entire test.
• Java Source Code Modifier Plug-Ins: These are special plug-ins that can subsequently modify the source code generated by the HTTP Test Wizard. Usually such plug-ins are only used as a workaround if the HTTP Test Wizard generates faulty or incomplete source code.

Importing Published Plug-Ins

After you have imported the plug-in you have to load and compile it - then save the compiled plug-in.

After you have saved the compiled plug-in you can add it to your HTTP Test Wizard session. Plug-ins of the type “Java Source Code Modifier Plug-Ins” do not have to be added, but can be called directly after the source code of the test program has been generated.

Developing own Plug-ins

Own plug-ins can be developed in Java 8 or 11. The following example shows a plug-in which decode a base64 encoded string.

After clicking at “New Plug-In” the plugin type has to be selected (in this example “Normal Session Element Plug-In”):

At the “General Settings” tab you have at least to enter the Plug-In Title and the Java Class Name. You should als enter a Plug-In Description which can be formatted by simple HTML tags. The onInitialize Scope can be set to “Global”, as this plug-in does not require any initialization. The onExecute Scope is set to “User Session” in order that all kind of variable scopes are supported.

At the next tab - “Input & Output Values” - a plug-in input and a plug-in output (Java-)variable is defined for the plug-in method onExecute. The values of this two Java variables will later correspond with two HTTP Test Wizard variables (which may have a different variable name):

When you click at the next tab - “Resources Files” - you will see that the Java library com.dkfqs.tools.jar is already added to the plugin. This is normal as all kind of plug-ins require this library. Here you may add also other Java libraries required by the plug-in - but in this case no other libraries are needed.

Now at the “Source Code & Compile” tab, you can first generate the plug-in template. Then you have to extend the generated code with your own code, ie in this example you have to complete the Java import definitions and program the inner logic of the Java method onExecute. Then compile the plug-in.

At the last tab “Test & Save” you can first test the plug-in (remotely) on any Measuring Agent. To perform the test enter for example “SGVsbG8gV29ybGQ=” as input and you will see as output “Hello World”.

Finally save the plug-in:

After you have saved the plug-in click at the “Close” button. Then you will see the new plug-in in the plug-in list:

Publishing Plug-Ins

If your plug-in can be used universally, it would be nice if you also publish it - to make it available to other users.

Note that you have to enable in your Profile Settings the option “Public In-App User” in order that you entitled to publish plug-ins.

Publishing plug-ins is especially useful for users who have additionally activated the option “Publish My Profile as Technical Expert” in their Profile Settings. This will significantly improve your visibility and competence.

Debugger

The HTTP Test Wizard Debugger is a powerful tool with some special features:

• It is a Remote Debugger, which means the instructions are always executed on a Measuring Agent. This also allows you to debug the session from different geographical locations.
• The debugger works directly with the definitions made in the HTTP Test Wizard - so there is no code to compile before debugging a session.
• During debugging, variables can also be defined, modified, and deleted.
• Values of variables can extracted from HTTP responses and assigned to HTTP requests (in addition/alternative to the Variables Wizard of the URL Explorer).
• All definitions made in the debugger regarding variables are synchronized with the HTTP Test Wizard session.
• You can force the debugger to jump over lines of Input Files.
• The value of HTTP Cookies can be examined and modified.
• The value of variables can be monitored in real-time.
• You can search for a text over all (so far) executed HTTP requests and responses.

Selecting the Measuring Agent

The executing Measuring Agent can be selected in the upper right corner. The debugger is reset when you select another Measuring Agent.

Values of User Input Fields

If your session contains User Input Fields, you will be prompted to enter their values when the debugger is initialized or reset.

Jumping over Lines of Input Files

Reading the lines of Input Files is automatically processed by the debugger. However you can force the debugger to jump over the lines of an Input File.

Debugging the Session

Click Next Step repeatedly to debug the session.

If you want to assign the value of a variable to an HTTP request, briefly enable HTTP Requests Breakpoint before the URL is executed. After that, you should disable this option.

Extracting Values from HTTP Responses

Click the received HTTP Response Header or Response Content of a URL to extract a value into a variable:

This example extracts the value of a JSON response into a variable. If the variable does not yet exist, you can define it first.

Assigning Values to HTTP Requests

Proceed as follows

1. Enable ‘HTTP Requests Breakpoint’ before the URL is executed.
2. Click ‘Next Step’. The data of the HTTP request is then initialized, but the request is stopped ‘in the middle’, meaning it is not yet sent to the HTTP(S) server.
3. Assign the value to the URL, or to the HTTP Request Header, or to the HTTP Request Content.
4. Disable ‘HTTP Requests Breakpoint’.
5. Click ‘Continue’. The HTTP request is now sent to the HTTP(S) server.

This example assigns the value of a variable to a JSON HTTP request content:

4.6 - HTTP/S Remote Proxy Recorder

By using an HTTP/S Remote Proxy Recorder, the HTTP/S traffic from Web browsers and technical Web clients can be recorded and easily converted into a HTTP Test Wizard session.

The HTTP Test Wizard session can then be post-processed and debugged. Finally, an executable test can be generated from the recorded session.

Functional Overview: Remote Proxy Recorder

An HTTP/S Remote Proxy Recorder has two service ports:

• A Control Port that is addressed by the portal server.
• A Proxy Port that records the data traffic from a Web browser or from a technical Web client.

All data traffic that passes through the proxy port is first decrypted by the Proxy Recorder and then encrypted again before it is forwarded to the target Web server(s).

In order to record a Web surfing session by a Web browser you have to start two different Web browser products on your local machine. For example:

• A Chrome browser to operate the portal server (Web Browser 1), and
• A Firefox browser to record the Web surfing session (Web Browser 2)

We recommend to use always Firefox as Web Browser 2.

To be able to record a Web surfing session, you have to reconfigure Web Browser 2

• Import the Proxy Recorder CA Root Certificate into the Web Browser 2
• Configure the Network Settings of Web Browser 2 to use the Proxy Server, or alternatively (recommended) install the RealLoad Web Browser Extension in Web Browser 2.

Additional note: Before you start recording a Web surfing session in Web Browser 2, you must always clear the browser cache.

Once the recording is completed you should undo the configuration changes in Web Browser 2 (restore the original network settings and delete the Proxy Server CA Root Certificate).

Importing the Proxy Recorder CA Root Certificate into the Web Browser

The following describes how you can import the CA Root Certificate of a Proxy Recorder in the Firefox Web Browser.

Sign in to the portal, navigate to the HTTP/S Remote Proxy Recorders menu, and download the CA Root Certificate of the Proxy Recorder to any folder on your computer:

Note: The image above shows the certificate of a shared proxy recorder (whereby all shared proxy recorders use the same CA root certificate). However, the ‘Subject’ of the certificate could also have other values, depending on the proxy recorder. So that you can find the certificate in Firefox and delete it if necessary, you should remember the values of the ‘Certificate Subject’ (or take a photo of the certificate properties with your mobile phone).

In Firefox call Settings:

Click Privacy & Security:

Scroll down to Security - Certificates, and click ‘View Certificates…’

In the Firefox Certificate Manager click first on Authorities and then on ‘Import…’

Select the CA Root Certificate you downloaded before and check the “Trust this CA to identify websites” box. Then click OK

The CA Root Certificate is now imported into Firefox:

Important Security Notice

After you have installed a Proxy Recorder’s CA Root Certificate in a web browser product (in this case, Firefox), you can record web surfing sessions, but you can no longer trust the web browser itself, because if someone else has accesses to the same CA Root Certificate, you can be cheated - without the corresponding web browser issuing a warning.

This is especially important if you use a Shared Proxy Recorder or the Desktop Companion application. This means that you should never use such a web browser for financial-critical transactions such as e-banking - or for logging into personal websites, as long as a proxy recorder’s CA root certificate is installed in the browser. Only after removing the CA root certificate from the browser is it safe again.

This security problem is not so critical if you operate your own HTTP/S Remote Proxy Recorder (or have us operate it). But even in this case, you could theoretically be cheated by your team members.

So the most secure way is to remove the proxy recorder’s CA root certificate from the web browser as soon as your recording is done.

Recording of Web Surfing Sessions

Once you have Imported the Proxy Recorder CA Root Certificate into the Web Browser and have installed the ‘RealLoad Test Recorder’ browser extension you are ready to Record Web Surfing Sessions and convert them into RealLoad Tests.

5 - Synthetic Monitoring

Synthetic Monitoring is an essential part of Digital Experience Monitoring, where organizations can detect their service outages or performance degrade proactively by periodically running the tests.

RealLoad provides an easy way of configuring synthetic tests with an outcome of accurate metrics, alerting and SLA details.

RealLoad Synthetic Monitoring Features

• Due to the universal architecture, RealLoad Tests of any kind can be run as a Monitoring Job (HTTP Test Wizard tests, JUnit tests, Selenium IDE tests).
• Monitoring Jobs can be assigned to multiple Measuring Agents, which means that the job is executed from different geographical locations. The measurement results of the Measuring Agents are combined into a single result, whereby the individual result of each Measuring Agent is still available.
• Support for performance warning thresholds.
• Support for delayed alarm notifications.
• Supported alert devices: Email, Mobile Companion App (installed on a mobile phone), SMS and WebHooks (including Pagerduty and Slack).
• Synthetic monitoring jobs can also run with hundreds of virtual users ¹
  ¹ = does not apply to Selenium IDE and Playwright Tests (max. 5..50 users per Measuring Agent due to the high CPU usage)
• Custom dashboards can be created for third-party products like Grafana using the WebSocket API.

Prerequisite: Define a Test

You have first to define a RealLoad ‘Test’ before you can add it to Synthetic Monitoring.

Configure Synthetic Monitoring

First add a Monitoring Group and then add one or more Monitoring Jobs to the Monitoring Group. If you want to run Monitoring Jobs with different intervals, you can also define several Monitoring Groups. Measuring Agents will be available for selection based on how many agents are already configured on different geographical locations.

Add Monitoring Group

Input Fields:

• Group Title : Must be unique across all monitoring groups.
• Group Description : Optional description.
• Max. Data Storage Time : The maximum retention period of the measured data.
• Execution Interval : The execution interval of the Monitoring Jobs.
• Execution Timeout : The execution timeout of the Monitoring Group. Tip: do not choose this too short, otherwise the Monitoring Jobs will be aborted. The execution timeout can also be greater than the execution interval. The monitoring jobs of a monitoring group are executed in sequential order.
• Primary Measuring Agent & Additional Measuring Agents : Select the Measuring Agent(s) on which the Monitoring Jobs will be executed.

After you have added a monitoring group, its execution is switched off. Switch on the execution now:

Add Monitoring Job

In a Monitoring Group, first click on ‘Monitoring Jobs’ and then in the Monitoring Jobs area on ‘Add Monitoring Job’:

Then select a Test …

… And Configure and Define the Monitoring Job:

Input Fields:

• Monitoring Job Title : Required.
• Monitoring Job Description : Optional description.
• Job Execution Enabled : Controls whether the job is executed.
• Number of Users : The number of simulated users that are started.
• Max. Test Duration : The maximum test duration.
• Max. Loops per User : The maximum number of sessions executed per user (the number of iterations of the test per user).
• Loop Iteration Delay : The delay time after a session of a user has ended until the next session of the user is started.
• Ramp Up Time : The length of time at the beginning of the test until all simulated users are started. Example: with 20 simulated users and a time of 10 seconds, a new user is started each 0.5 seconds.
• Additional Arguments : Additional values which are transferred on the command line when the test script is started. These arguments are test specific. For tests that were created with the “HTTP Test Wizard” you can specify for example the following values: “-tcpTimeout 8000 -sslTimeout 5000 -httpTimeout 60000” (TCP connect timeout / SSL handshake timeout / HTTP processing timeout) which are considered by the executed URL calls and override the default values.
• Debug Execution : This option effects that detailed information are written to the log file of the test. For example variable values which have been extracted from input files or from HTTP responses as well as variable values which are assigned at runtime. Only activate this option if you have problems with the execution of the test.
• Debug Measuring : Effects that the Data Collector of the Measuring Agent writes the JSON objects of the All Purpose Interface to its log file. This option can be enabled to debug self-developed tests that have been written from scratch.
• (User Input Fields) : If the test contains User Input Fields you can enter their values here.
• Performance Warning Alert Threshold : If switched on, a warning alert is triggered if the configured time per user loop (per user session) is exceeded.
• Performance Error Alert Threshold : If switched on, a error alert is triggered if the configured time per user loop (per user session) is exceeded.

Normally you do not have to enter any “Additional Arguments” and leave “Debug Execution” and “Debug Measuring” switched off.

Tip: We recommend that you leave options ‘Performance Warning Alert Threshold’ and ‘Performance Error Alert Threshold’ switched off for now and configure them later - after the new defined Monitoring Job has been running for a few hours.

The following limits apply for Monitoring Jobs which are executed on shared Measuring Agents:

• Number of Users: max. 5
• Max. Test Duration (Seconds): max. 300
• Max. Loops per User: max. 5

If you operate your own, private Measuring Agents (or have us to operate them), these limits do not apply - meaning you can run Monitoring Jobs with hundreds or thousands of concurrent users.

Configure Monitoring Downtimes

A Monitoring Downtime is a window of time during which synthetic monitoring is temporarily disabled. Multiple monitoring downtimes can be defined for all monitoring groups, or for specific monitoring groups and also for specific monitoring jobs.

For example, if you know that a web service will be down for a certain period of time due to maintenance, you can configure a monitoring downtime.

To add a new downtime click ‘Add Downtime’:

Input Fields:

• Headword / Description : Required.
• Monitoring Groups : Select the monitoring group(s). Either all, or a single one or several.
• Monitoring Jobs : Select the monitoring jobs(s). Either all, or a single one or several.
• Start Date & Time : The date an time when the monitoring downtime starts (for the selected monitoring groups and jobs).
• Duration HH:MM : The duration of the downtime in hours and minutes.
• Repeat : Determines whether the monitoring downtime is repeated periodically (no repeat, daily, weekly or monthly).
• Number of Repeats : 1 = no repeat. Max. number of repeats: 400

Once a downtime is defined you can modify and delete it. Expired monitoring downtimes are automatically removed.

Alerting

Proceed as follows:

1. Add one or more Alert Groups.
2. Define the Alert Devices and assign them to the Alert Group(s).
3. Assign the Alert Groups to Monitoring Groups and/or to Monitoring Jobs

Add Alert Group

First click on the ‘Alert Groups & Devices’ tab and then click on ‘Add Alert Group’.

Input Fields:

• Alert Group Title : Must be unique across all alert groups.
• Alert Group Description : Optional description.
• Alert Group Enabled : Controls whether the alert group is enabled or disabled.
• Report Measured Errors : Controls whether errors measured by monitoring jobs are reported.
• Report Measured Warnings : Controls whether warnings measured by monitoring jobs are reported.
• Report System Failures : Controls whether malfunctions of the monitoring system are reported (for example if a Measuring Agent is not reachable).
• Report Execution Failures : Controls whether execution failures of monitoring jobs on Measuring Agents are reported (meaning that the start of the corresponding test job failed).
• Repeat Alerts : Controls whether the alerts for the same issue are reported repeatedly.
• Report Alerts ‘Instantly’ or ‘After n Repeat’ : Controls whether alerts are reported immediately or delayed.

Tip: For example, you can define two alert groups, one for operations and another for developers. In the developer alert group, you could turn off the switches ‘Report System Failures’ and ‘Report Execution Failures’.

Add Alert Devices

First expand the area of the alert device type and then click the ‘+’ icon:

After adding the alert device, you should test it:

Assign Alert Device to Alert Groups

After an Alert Device has been added, you can assign it to one or more Alert Groups.

Assign Alert Groups to Monitoring Groups and Monitoring Jobs

To receive Alert Notifications, you must assign the Alert Groups to Monitoring Groups and/or to Monitoring Jobs.

If you click on a bell icon you can only assign one Alert Group. However, you can click the bell icon multiple times to assign multiple Alert Groups.

Real-Time Dashboard

As the name suggests, the current values of the Monitoring Groups and Monitoring Jobs are displayed in real time. The current time, which is received from the portal server, is also shown at the top right. To get a slightly more reduced view, you can also only display the Monitoring Jobs.

Values Displayed:

• System Status (‘Healthy’, ‘Partial Malfunction’, or ‘Malfunction’) : Indicates whether there are malfunctions in the monitoring system (for example if a measuring agent is not reachable).
• Execution State (‘Successful’, ‘Partial Failed’, or ‘Failed’) : Indicates whether execution failures of monitoring jobs on measuring agents are occurred (meaning that the start of the test job failed).
• Availability Last 24hr : The measured availability within the last 24 hours. When you click on the value, the corresponding statistics are displayed. The sparkline (micro chart) shows the availability of the last 24 hours.
• Errors | Warnings : The number of measured errors and warnings of the last execution. If you click on the chart icon, the details of the last measurement result are displayed.
• Last Executed : The date and time of the last execution. If you click on the file icon, the log file of the last test execution as well as the detailed measurement results of the individual measuring agents are displayed.
• Performance : The measured time duration per successfully executed loop or per user session of the last execution of the monitoring job. The sparkline (micro chart) shows the performance of the last 24 hours.

Tip: In addition to the ’normal’ Real-Time Dashboard, a simplified dashboard is also available in the Mobile Companion App. This gives you a quick overview without having to log in to the portal every time.

Display of the Latest Test Result

In a Monitoring Job click the ‘Test Result’ icon. The browser will now be redirected to the Tests Results Menu and the test result will be loaded.

If errors or warnings were measured, you can view their details:

If the test was performed without errors, the test result would look like this:

Display of the Latest Job Log Files

In a Monitoring Job click the ‘Job Output Files’ icon to display the latests job log and output files.

In this example, the monitoring job was configured to be executed from two Measuring Agents:

Statistics, SLA Verification and Historical Data

Click the Statistics Tab to view the data and charts about the measured availability and performance of a Monitoring Group or Monitoring Job.

By selecting a suitable Time Range, you can check whether the SLA requirements have been met.

Proceed as follows:

1. Select a Monitoring Group.
2. Select a Monitoring Job (of the Monitoring Group).
3. Select the Time Range.
4. Click ‘Apply’.
5. Optional: Click inside a chart to get access to the historical data of a specific Monitoring Job execution.

Values Displayed:

• First Measurement : The absolute date/time when the first Monitoring Job was executed in the selected time range.
• Last Measurement : The absolute date/time when the last Monitoring Job was executed in the selected time range.
• Measurements : The number of Monitoring Jobs executed in the selected time range.
• Availability : The error-free availability of the Monitoring Job calculated in the selected time range.
• Error Time : The cumulative time that errors were measured in the selected time range.
• Average Performance : The average time per executed loop (per session loop) of the Monitoring Job in the selected time range.
• Monitoring Availability : The (internal) availability of the RealLoad Monitoring System in the selected time range.

6 - System Monitoring

Architecture Overview

RealLoad System Monitoring is a separate subsystem whose functions can be controlled from the RealLoad Portal, but runs independently of the Portal Server. This means that System Monitoring remains functional even when the Portal Server is down.

The System Monitoring Architecture extends the RealLoad Product by 3 Components:

1. Alert Processor: A stand-alone, independent process that collects Operating System Metrics form all OS systems where OSHI Daemons are installed and executes Monitoring Rules, whose results are instantly visible at real-time in the RealLoad Portal. Every RealLoad customer who wants to perform System Monitoring needs their own Alert Processor.
2. OSHI Daemon: A process that collects local Operating System Metrics and reports them to the Alert Processor. Any Linux and Windows systems are supported.
3. JavaScript Processor: A generic component (OS process) without any context that receive and execute Java Scripts and return the execution result to the caller. Any Linux and Windows systems are supported.

Monitoring Rules are usually executed on the Alert Processor by calling the JavaScript Processor, as this is resource-optimal. Alternatively, Monitoring Rules can also be executed locally on OSHI Daemons called via the Alert Processor (if a JavaScript Processor is installed on the OSHI Daemon), which allows starting or restarting local OS Processes as well as executing HTTP requests directly from the OSHI Daemon.

RealLoad: System Monitoring Features

After installing the Alert Processor, the OSHI Daemons and the JavaScript Processors, there is no further configuration required for such components - all System Monitoring settings can be managed directly from the RealLoad Portal.

• The Unique ID of newly installed OSHI Daemons (= OSHI Systems) can be entered in the RealLoad Portal, whereby such an entry authorizes the OSHI Daemon to establish a network connection to the Alert Processor.

• The Metrics measured by the OSHI Systems are instantly visible on the RealLoad Portal in real-time (+5 seconds).

• All current Alert States of Monitoring Rules executed of any OSHI System are also visible in real-time on the RealLoad Portal.

• Predefined Templates of the most frequently required Monitoring Rules are already available.

• Own Monitoring Rules (written in JavaScript) can be developed online in the RealLoad Portal within a very short time, without the need of any additional tools. A powerful wizard supports you to develop, debug and test Monitoring Rules.

• Multiple Monitoring Rules can be assigned to a Monitoring Group. The Monitoring Group settings determine which OSHI Systems are monitored and at what time interval the Monitoring Rules are executed. Multiple Alert Devices (Email, “Mobile Companion” App installed on iOS or Android, SMS) can be grouped to an Alert Group and assigned to one or multiple Monitoring Groups. The Alert Group settings determine what type of alerts are sent to the Alert Devices.

• Alert notifications can also be received when an OSHI Daemon loses connection to the Alert Processor, and when the connection is restored (for example if the monitored operating system or server is down or restarted).

RealLoad: OSHI Daemon Features

OSHI Daemons are installed locally on OS Systems to be monitored and report Operating System Metrics to the Alert Processor in real time.

The following Operating System Metric Types are continuously measured and reported:

• OS Info: e.g. OS type, version and system boot time
• CPU Info: e.g. CPU usage in %, interrupts and context switches per second
• Memory Info: e.g. used physical memory in %, used swap memory in %, hard page faults per second
• Network Interfaces Info: e.g. current throughput per network interface, network interface error rate
• Network Connections Info: all current network connections with their TCP und UDP states
• Local Disks Info: e.g. disk capacity, disk manufacturer, R/W queue length
• File Systems Info: e.g. file system mount point, total size, used size in %
• OS Processes INFO: all current processes of the OS, e.g. process PID and name, process start arguments

In total, +/- 200 Operating System Metrics are measured.

Additional, own metrics can be measured using shell scripts called directly by Monitoring Rules (see next subsection).

RealLoad OSHI Daemon + Local JavaScript Processor

Installing a local JavaScript Processor on an OSHI Daemon is optional, but has additional advantages.

By installing a local JavaScript Processor on a OSHI Daemon the Daemon can:

• Execute HTTP Requests periodically as Monitoring Rule, which results can also trigger a monitoring alert.
• Execute any local OS Process periodically as Monitoring Rule (for example a bash script), which process-output can also trigger a monitoring alert.
• Periodically Monitor OS Processes, and restart dead processes as daemon ¹ (which can also be reported as a monitoring alert – in case of the absence of an OS Process and when restarting an OS process).

¹ = Restart dead processes as daemon: Depends with which OS account the JavaScript Processor is started - or requires to set a sticky bit for the restart script.

Implementing System Monitoring

Prerequisites

To implement System Monitoring, you need your own “Core Monitoring” system with an Alert Processor and a local JavaScript Processor running both on the same (dedicated) OS system.

You can either install and operate such a “Core-Monitoring” system yourself – or commission us to operate a corresponding instance in the cloud.

After your “Core-Monitoring” system is up and running, it must be registered in the RealLoad Portal by our Support Team and linked to your RealLoad (main-user-)account.

You can then install OSHI Daemons (+ optionally their JavaScript Processors) yourself on any of your systems and also register them yourself in the RealLoad Portal.

Registering OSHI Systems in the RealLoad Portal

If you look at the log file contents of a newly installed OSHI Daemon, you will notice that it cannot yet connect to the Alert Processor because it does not yet have the necessary authorization.

However, in the first lines of the log file you will see the Unique Daemon ID of the newly installed OSHI Daemon. Copy this value into a text file or into an editor.

Direct Visible Operating System Metrics

The most important operating system metrics of the OSHI Systems are directly visible in the RealLoad Portal:

• CPU & Memory (real-time view)
• Network (real-time view)
• Network Connections (snapshot)
• Disks (snapshot)
• Filesystems (snapshot)
• OS Processes (snapshot)

Import Monitoring Rules from Templates

Ready-made Monitoring Rules Templates are available for monitoring the most important system metrics.

You can import such templates and, if necessary, adapt them to your needs (which is usually not necessary). Proceed as follows:

Monitoring Groups

To execute Monitoring Rules, you need at least one “Monitoring Group”. The Monitoring Group determines which OSHI Systems will be monitored and at what time interval the monitoring will be performed.

Input Fields:

• Monitoring Group Title : You can enter any text, but it must be unique across all Monitoring Groups.
• Description : Optional input field.
• Execution Interval : Select the time interval in which the (later added) Monitoring Rules are executed.
• Group Execution Enabled : Set this switch to on.

Assigning Monitoring Rules to a Monitoring Group

Generic Input Fields:

• Rule Enabled : Let this switch to on.
• Execute Rule (“On Alert Processor” or “On OSHI Systems”) : For “normal” rules always select “On Alert Processor”. The option “On OSHI Systems” should only be selected for rules that execute HTTP requests or start OS processes, which also requires that all OSHI systems of the Monitoring Group have a locally installed JavaScript Processor.

Rule Configuration Input Fields:

• Depending on the Monitoring Rule you select, none, one, or more Configuration Input Fields will be displayed. The input fields are pre-filled with default values ​​that you can overwrite and change according to your needs.

Alert Devices & Alert Groups

You can register several different Alert Devices (such as Email recipients, SMS recipients and a Mobile Phones with installed RealLoad “Mobile Companion App”) and assign them to one or more “System Monitoring” Alert Group.

Please note that all Alert Devices are shared between Synthetic Monitoring and System Monitoring. This means that adding/changing/deleting an Alert Devices will affect both Synthetic Monitoring and System Monitoring.

Adding an Alert Group

Input Fields:

• Alert Group Title : You can enter any text, but it must be unique across all Alert Groups.
• Alert Group Description : Optional input field.
• Alert Group Enabled : Let this switch to on.
• Report Measured Errors : This switch controls whether notifications are sent for errors detected by monitoring rules.
• Report Measured Warnings : This switch controls whether notifications are sent for warnings detected by monitoring rules.
• Repeat Alerts : If this switch is off, notifications will only be sent when an alert state changes (new/modified/cancelled alert).
• Report Alerts (“Instantly” or “After N Repeat”) : This allows to control whether a notification is sent immediately or with a delay when an error or warning is detected.
• On active OSHI System disconnects (“No/Info/Warning/Error Notification”) : This allows to control whether a notification is sent when the network connection of an OSHI Daemon to the Alert Processor is interrupted or reestablished.

Adding an Alert Device

Adding Alert Devices to Alert Groups

Assigning Alert Groups to Monitoring Groups and/or to Monitoring Rules

Developing own Monitoring Rules

In the following we will show how you can develop your own Monitoring Rules in JavaScript.

Example

This example monitors whether a specific operating system process exists. To do this we need two pieces of information:

• The list of all OS processes
• A text fragment of an OS process command line to search for.

In the Add Monitoring Rule form enter the following data:

• Rule Title : “Check OS Process exist”
• Add two Configuration Input Fields (Label = “OS Process Title” and “Command Line Text Fragment”, Data Type = String) : Theoretically, the configuration of the rule can be hard coded. However, in order to be able to use the rule as flexibly as possible, “Configuration Input Fields” are used. The “Configuration Input Field” with the label “OS Process Title” is not required for the logic of detecting the OS process, but is part of the alert notification.
• JavaScript Function Name : “checkOsProcessExist”
• Function Parameter #3 : Select osProcessesSnapshot

Some tips:

• The “Save Code” button saves the source code of the rule permanently. Alternatively, you can also enter <Ctrl>-S in the editor.
• The “Update Code and Test Again” button saves the source code in memory only and triggers a new test of the rule.
• By clicking on the “Down Arrow” icon you can enlarge the editor area.
• You can copy the JSON data displayed in the JavaScript console into the JSON editor of a second browser window and format it there.

The source code of the complete rule looks like this:

/* Monitoring Rule.
 * Description: Check if an OS process exists.
 */
function checkOsProcessExist(ruleConfig, ruleContext, osProcessesSnapshot) {
	// console.log(`ruleConfig = ${JSON.stringify(ruleConfig)}`);
	// console.log(`ruleContext = ${JSON.stringify(ruleContext)}`);
	// console.log(`osProcessesSnapshot = ${JSON.stringify(osProcessesSnapshot)}`);
	
	const vProcessTitle = ruleConfig.vProcessTitle;
	const vCommandLineFragment = ruleConfig.vCommandLineFragment;
	
	const systemDescription = ruleContext.oshiSystem.systemDescription;
	const oshiDaemonUniqueId = ruleContext.oshiSystem.oshiDaemonUniqueId;
	
	// count the number of processes that contain the command line fragment
	let osProcessCounter = 0;
	osProcessesSnapshot.osProcessesArray.forEach(osProcess => {
	  const commandLine = osProcess.commandLine;
	  if (commandLine.includes(vCommandLineFragment) === true) {
	    osProcessCounter++;
	  }
	})

    // create the alert context
	const alertContextKey = oshiDaemonUniqueId + '|checkOsProcess_' + vProcessTitle;   // must be unique overall OSHI Systems and Monitoring Rules
	const alertContextDescription = `'${systemDescription}': check if OS process '${vProcessTitle}' exists`;
	let alertMessage = '';
	let alertStatus = 'ok'; // possible values are : 'ok', 'warning' or 'error'
	switch(osProcessCounter) {
    case 0:
      alertMessage = `'${systemDescription}': the OS process '${vProcessTitle}' not exists`;
      alertStatus = 'error';
      break;
    case 1:
      alertMessage = `'${systemDescription}': the OS process '${vProcessTitle}' exists`;
      alertStatus = 'ok';
      break;
    default:
      alertMessage = `'${systemDescription}': the command line fragment '${vCommandLineFragment}' is ambiguous for OS process '${vProcessTitle}'`;
      alertStatus = 'warning';
      break;
	}
	const alertContextArray = [];
	alertContextArray.push({alertContextKey, alertContextDescription, alertMessage, alertStatus});

	// return rule result
	const ruleResult = {
		alertContextArray: alertContextArray
	};
    // console.log(`alertContextArray = ${JSON.stringify(alertContextArray)}`);
	return ruleResult;
}

1. The variables vProcessTitle and vCommandLineFragment are extracted from the function parameter #1 (ruleConfig) and contain the values of the Configuration Input Fields.

2. The variables systemDescription and oshiDaemonUniqueId are extracted from the function parameter #2 (ruleContext) and are initialized by the System Monitoring Alert Processor.

3. Then the number of processes containing the command line text fragment is counted by evaluating the function parameter #3 (osProcessesSnapshot in this example).

4. Finally, the Alert Context is created. As you can see, an array of alert contexts is returned as the function result, which means that a rule can also create multiple alert contexts. In this example, however, only one alert context is created.

Each Alert Context must contain:

• an alertContextKey : This key must be unique overall OSHI systems and monitoring rules. It is best to combine the oshiDaemonUniqueId with another unique property of the monitoring rule, as shown in this example.
• the alertContextDescription : A short description of the alert context. This is only displayed in the RealLoad Portal.
• the alertMessage : This text will be sent as a part of the Alert Notification to the Alert Devices.
• the alertStatus : Which must be ‘ok’, ‘warning’ or ’error’. Any other values are not supported.

Executing OS Processes from Rules

By executing Operating System Processes based on Rules, you can enhance System Monitoring with any custom metrics. For example, you can run Bash scripts to collect additional data and process it in Monitoring Rules. You can also restart dead OS Processes.

Executing Operating System Processes from Monitoring Rules is only supported on OSHI Systems that have a local JavaScript Processor installed. This also means that all OSHI Systems of the Monitoring Group to which the rule is assigned must support a local JavaScript Processor.

In Addition the Monitoring Rules must configured to be executed on “OSHI Systems” (instead to be executed on the “Alert Processor”).

The javascript-processor.properties (on the OSHI Systems) controls if and how many OS Processes can be started per rule execution, and if OS processes can be started as a daemon:

# The JavaScript processor features
JavaScriptStartOsProcessesEnabled=true
JavaScriptStartOsProcessesMaxInstances=3
JavaScriptStartOsProcessesAsDaemonEnabled=true

The JavaScript Engine for executing the Monitoring Rules has been extended by the OSProcess object.

OS processes can either be started as a normal process, with their output being evaluated by the monitoring rule. Such normal processes are killed if they still exists after the monitoring rule is executed. Monitoring Rules that start a normal OS process should always call the JavaScript method waitFor() after start() - see below.

Alternatively, OS processes can also be started as a daemon, with such OS processes surviving the end of the rule’s execution. This can therefore be used to restart dead operating system processes.

JavaScript Constructor : OsProcess.newInstance(<Array of String> OS command line arguments)

Example: The following monitoring rule checks whether the operating system parameter DefaultTasksMax is configured and large enough:

/* Monitoring Rule.
 * Description: Check if the OS parameter DefaultTasksMax is configured and large enough.
 */
function checkOsParamDefaultTasksMax(ruleConfig, ruleContext) {
	// console.log(`ruleConfig = ${JSON.stringify(ruleConfig)}`);
	// console.log(`ruleContext = ${JSON.stringify(ruleContext)}`);
	
	// get Configuration Input Field: DefaultTasksMax Min. Value [Number]
	const vDefaultTasksMaxMinValue = ruleConfig.vDefaultTasksMaxMinValue;
	
	const systemDescription = ruleContext.oshiSystem.systemDescription;
	const oshiDaemonUniqueId = ruleContext.oshiSystem.oshiDaemonUniqueId;
	
	// execute bash script
	const osProcess = OsProcess.newInstance(['bash', '-c', 'systemctl show | grep DefaultTasksMax']);
	osProcess.setCollectStdout();
	osProcess.start();
	osProcess.waitFor();
	const processStdoutLines = osProcess.getStdoutLines();
	// console.log(`processStdoutLines = ${JSON.stringify(processStdoutLines)}`);
	
	// extract systemctl value and create te alert context 
	const alertContextKey = oshiDaemonUniqueId + '|checkOsParamDefaultTasksMax';
	const alertContextDescription = `Check if '${systemDescription}' OS param DefaultTasksMax >= ${vDefaultTasksMaxMinValue}`;
	let alertStatus = 'ok';
	let alertMessage = '';
	
	if ((processStdoutLines.length === 0) || (!processStdoutLines[0].includes('DefaultTasksMax'))) {
	    alertStatus = 'error';
	    alertMessage = 'OS param DefaultTasksMax not configured';
	} else {
	    const currentDefaultTasksMax = Number(processStdoutLines[0].split('=')[1]);
	    // console.log(`currentDefaultTasksMax = ${currentDefaultTasksMax}`)
	    alertMessage = 'OS param DefaultTasksMax = ' + currentDefaultTasksMax;
	    if (currentDefaultTasksMax < vDefaultTasksMaxMinValue) {
	        alertStatus = 'error';
	        alertMessage = alertMessage + ' : value too small, should be at least ' + vDefaultTasksMaxMinValue;
	    }
	}
	
	const alertContextArray = [];
	alertContextArray.push({alertContextKey, alertContextDescription, alertMessage, alertStatus});
	
	// return rule result
	const ruleResult = {
		alertContextArray: alertContextArray
	};
	return ruleResult;
}

Executing HTTP Requests from Rules

Executing HTTP Requests from Monitoring Rules requires - analogous to executing OS Processes from Monitoring Rules - that a local JavaScript Processor is available on the OSHI Systems.

Theoretically (and also possible) HTTP Requests can also be executed on the Alert Processor, but this usually makes little sense since you usually want to check the runtime behavior from a specific location - or because you want to check whether a certain service is accessible from the localhost. For this reason, Monitoring Rules that execute HTTP Requests should be configured to be executed on “OSHI Systems” (instead of on the “Alert Processor”).

The javascript-processor.properties (on the OSHI Systems) controls if and how many HTTP Clients can be started per rule execution, and the maximum size of a received HTTP Response Content (in bytes). Each individual HTTP client can execute multiple requests one after the other or simultaneously, so that in a monitoring rule you usually only need one instance of an HTTP client.

# The JavaScript processor features
JavaScriptHTTPClientEnabled=true
JavaScriptHTTPClientMaxConcurrentInstances=4
JavaScriptHTTPClientMaxStoredResponseContentSize=10000000

The JavaScript Engine for executing the Monitoring Rules has been extended by the HTTPClient object which is directly linked with the Java class com.dkfqs.tools.http.HTTPClient. Detailed documentation about the HTTPClient is available at https://download.realload.com/   - com.dkfqs.tools.jar - JavaDoc .

JavaScript Constructor 1 : HTTPClient.newInstance() // create a new instance with a default processing timeout per URL of 30 seconds, and with 2 processing threads.

JavaScript Constructor 2 : HTTPClient.newInstance(<Number> processingTimeout, <Number> numProcessingThreads) // create a new instance with a processing timeout per URL in milliseconds, and with the number of processing threads (valid range is 1..64).

Example 1 of 2 : HTTP GET Request

/* Monitoring Rule.
 * Description: .. add description here ..
 */
function executeHttpGetRequest(ruleConfig, ruleContext) {
	// console.log(`ruleConfig = ${JSON.stringify(ruleConfig)}`);
	// console.log(`ruleContext = ${JSON.stringify(ruleContext)}`);
	
	const systemDescription = ruleContext.oshiSystem.systemDescription;
	const oshiDaemonUniqueId = ruleContext.oshiSystem.oshiDaemonUniqueId;
	
	const httpRequestMethod = 'GET';
	const url = 'https://www.realload.com';
	const warnExecutionTimeMillis = 3000;
	
	const alertContextKey = oshiDaemonUniqueId + '|' + httpRequestMethod + ' ' + url;
	const alertContextDescription = `Check if ${url} is reachable`;
	let alertMessage = '';
	let alertStatus = 'ok';
	
	 // execute the HTTP GET
    const httpClient = HTTPClient.newInstance(); // create a new HTTPClient instance with a default processing timeout of 30 seconds 
    const httpRequest = httpClient.newRequest(httpRequestMethod, url);
    // const httpRequestHeader = httpRequest.getHttpRequestHeader();
    // httpRequestHeader.addOrReplaceHeaderField('uuid', '123456789');
    // console.log(`httpRequestHeader = ${httpRequestHeader.toJsonObject()}`)
    const httpResponse = httpClient.sendSyncRequest(httpRequest); // execute the HTTP request
    // process the HTTP response
	if (httpRequest.hasErrorException() === true) {
	    alertMessage = `'${systemDescription}': URL ${url} not reachable : ${httpRequest.getErrorException()}`;
	    alertStatus = 'error';
	} else {
	    const httpStatusCode = httpResponse.getHttpStatusCode();
	    const responseContentType = '' + httpResponse.getHttpResponseHeader().getContentMIMEType();
	    const performanceData = httpResponse.getHttpPerformanceData().toJsonObject();
	    const responseContent = httpResponse.getHttpResponseContent().getContentAsString();
	    
	    // console.log(`HTTP status code = ${httpStatusCode}`);
	    // console.log(`Response content type = '${responseContentType}'`);
	    // console.log(`HTTP performance data = ${performanceData}`);
	    // console.log(`HTTP response content = ${responseContent}`);
	    
	    alertMessage = `'${systemDescription}': URL ${url} : `;
	    if (httpStatusCode !== 200) {
	        alertMessage = alertMessage + `invalid HTTP status code ${httpStatusCode}`;
	        alertStatus = 'error';
	    } else {
	        if (responseContentType !== 'text/html') {
	            alertMessage = alertMessage + `invalid response content type '${responseContentType}'`;
	            alertStatus = 'error';
	        } else {
	            const executionTime = JSON.parse(performanceData).executionTime;
	            alertMessage = alertMessage + `exec time ${executionTime} ms`;
	            if (executionTime > warnExecutionTimeMillis) {
	                alertStatus = 'warning';
	            }
	        }
	    }
	}
	httpClient.closeAbort(); // free all internal resources and close all connections of the HTTPClient
	
	const alertContextArray = [];
	alertContextArray.push({alertContextKey, alertContextDescription, alertMessage, alertStatus});

	// return rule result
	const ruleResult = {
		alertContextArray: alertContextArray
	};
	return ruleResult;
}

Example 2 of 2 : HTTP POST Request

/* Monitoring Rule.
 * Description: .. add description here ..
 */
function executeHttpPostRequest(ruleConfig, ruleContext) {
	// console.log(`ruleConfig = ${JSON.stringify(ruleConfig)}`);
	// console.log(`ruleContext = ${JSON.stringify(ruleContext)}`);
	
	const systemDescription = ruleContext.oshiSystem.systemDescription;
	const oshiDaemonUniqueId = ruleContext.oshiSystem.oshiDaemonUniqueId;
	
	const httpRequestMethod = 'POST';
	const url = 'https://portal.realload.com/PublicAPI';
	const warnExecutionTimeMillis = 3000;
	
	const alertContextKey = oshiDaemonUniqueId + '|' + httpRequestMethod + ' ' + url;
	const alertContextDescription = `Check if ${url} is reachable`;
	let alertMessage = '';
	let alertStatus = 'ok';
	
	 // execute the HTTP POST
    const httpClient = HTTPClient.newInstance(); // create a new HTTPClient instance with a default processing timeout of 30 seconds 
    const httpRequest = httpClient.newRequest(httpRequestMethod, url);
    // const httpRequestHeader = httpRequest.getHttpRequestHeader();
    // httpRequestHeader.addOrReplaceHeaderField('uuid', '123456789');
    // console.log(`httpRequestHeader = ${httpRequestHeader.toJsonObject()}`)
    const httpRequestContent = HTTPClient.newHTTPRequestContent('{"action":"getPortalServerInfo"}');    // set JSON data as request content
    httpRequest.setHttpRequestContent(httpRequestContent, "application/json");
    const httpResponse = httpClient.sendSyncRequest(httpRequest); // execute the HTTP request
    // process the HTTP response
	if (httpRequest.hasErrorException() === true) {
	    alertMessage = `'${systemDescription}': URL ${url} not reachable : ${httpRequest.getErrorException()}`;
	    alertStatus = 'error';
	} else {
	    const httpStatusCode = httpResponse.getHttpStatusCode();
	    const responseContentType = '' + httpResponse.getHttpResponseHeader().getContentMIMEType();
	    const performanceData = httpResponse.getHttpPerformanceData().toJsonObject();
	    const responseContent = httpResponse.getHttpResponseContent().getContentAsString();
	    
	    // console.log(`HTTP status code = ${httpStatusCode}`);
	    // console.log(`Response content type = '${responseContentType}'`);
	    // console.log(`HTTP performance data = ${performanceData}`);
	    // console.log(`HTTP response content = ${responseContent}`);
	    
	    alertMessage = `'${systemDescription}': URL ${url} : `;
	    if (httpStatusCode !== 200) {
	        alertMessage = alertMessage + `invalid HTTP status code ${httpStatusCode}`;
	        alertStatus = 'error';
	    } else {
	        if (responseContentType !== 'application/json') {
	            alertMessage = alertMessage + `invalid response content type '${responseContentType}'`;
	            alertStatus = 'error';
	        } else {
	            const executionTime = JSON.parse(performanceData).executionTime;
	            alertMessage = alertMessage + `exec time ${executionTime} ms`;
	            if (executionTime > warnExecutionTimeMillis) {
	                alertStatus = 'warning';
	            }
	        }
	    }
	}
	httpClient.closeAbort(); // free all internal resources and close all connections of the HTTPClient
	
	const alertContextArray = [];
	alertContextArray.push({alertContextKey, alertContextDescription, alertMessage, alertStatus});

	// return rule result
	const ruleResult = {
		alertContextArray: alertContextArray
	};
	// console.log(`ruleResult = ${JSON.stringify(ruleResult)}`);
	return ruleResult;
}

7 - Regression Testing

Abstract

Regression testing is supported by Real Load using “Test Job Templates” and “Test Suites”.

Features of Real Load Test Suites:

• Test suites are the grouping of multiple test job templates and are executed as a single “run” with different test scenarios.
• Due to the universal architecture, test jobs of any kind can be part of a test suite (HTTP Test Wizard Jobs, JUnit Jobs, Selenium Jobs ..).
• The results of the test suite “runs” are archived and can be compared with each other.
• In addition, the result of a particular test job of a test suite run can be compared with the result of the same test job executed by other test suite runs.
• All test jobs of a test suite support the powerful ability to be executed with hundreds or thousands of concurrent users and can even executed on a cluster of measuring agents.
• The test jobs of a test suite are grouped into “execution groups”, where the test jobs of an execution group can be executed in sequential or parallel order.
• The execution groups can be nested, whereby a separate measuring agent or measuring agent cluster can be defined for each execution group.
• A “run” of a test suite can be triggered either interactively or via the Remote User API.

This seems a bit complicated at first glance. However, as you will see, creating and running test suites is fairly easy.

Test Job Templates

Test job templates can be created by clicking ‘Save as Template’ in the dropdown menu of any load test job:

You can freely choose the name of the template, but it must be unique.

The template is then created. For verification purposes, the test job properties are displayed which you can also change here.

The list of all templates will then be displayed. Here you can delete, clone and modify individual templates and you can create also new load test jobs from a template.

Test Suites

Adding a Test Suite

As soon as one or more test job templates are created, you can add a new test suite.

You can freely choose the name of the test suite, but it must be unique.

After that the test suite is created and the “Test Suite Editor” is automatically invoked.

Editing a Test Suite

It is recommended that you configure a measuring agent or cluster on which the test suite runs will be executed so that you are not asked about it every time you start a test suite run.

Only “Execution Groups” can be defined at the main level of a test suite. This means that you have first to add one or more execution groups to the test sequence.

At the top right of the editor area you can configure the “Main Execution Order”, which controls whether the execution groups at the main level are executed one after the other (= sequential ) or concurrently (= parallel).

Adding an Execution Group

Here you can specify on which measuring agent or cluster the execution group will be executed, whereby the default option “inherit from parent” is recommended. By setting the “Execution Order” you can determine whether the elements of the execution group are executed sequentially or in parallel.

Note: Execution groups can also be nested, which means that an execution group can contain several sub-execution groups, which can then contain sub-sub execution groups. The advantage of nesting execution groups is, among other things, that the measured data of the executed the test jobs are presented in aggregated form at the level of each execution group.

Adding Test Job Templates to an Execution Group

Finally, click the icon at the top left corner to return to the Test Suites Dashboard.

Executing a Test Suite “Run”

A test suite “run” can be triggered either interactively or via the Remote User API.

To start a “run” click on the green icon of the test suite - which means that all test jobs of the test suite are executed.

In the upper area of the green window, summarized/aggregated measurement results over all executed test jobs are displayed.

In the left area of the green window, the progress of the of the test suite execution is displayed in real time, whereby the measured values of the currently executed (load) test jobs are updated every 4 seconds.

Multiple test suites can be executed concurrently, but the same test suite cannot be executed twice at the same time. Note that closing the green window will not abort the execution of the test suite “run”.

Tip: If a load test job of a test suite takes several minutes to execute, you can also view the detailed statistics of the load test job in a second Web Browser window in the Real Time View. All you have to do is select the Real Time View in the second browser window.

After a test suite run is completed you can click on “Display Result”.

Test Suite “Run” Results

Test Suite Run Results are always historical data, whereby the execution groups and the test jobs are painted as they were at the time of execution.

In the upper area summarized/aggregated measurement results over all executed test jobs are displayed.

Clicking on the chart icon of a test job displays the “Test Result Details”. By clicking the file icon, you can view the contents of the test job output files.

Comparing Test Suite Run Results

The summarized/aggregated measurement results of the test suite runs can be compared across all or a selection of runs.

Furthermore, the measurement results of the individual test jobs can be compared across all or a selection of runs.

8 - Web Browser Recorder Extensions for both Chrome and Firefox

This browser extension will ask for the RealLoad proxy configurations, then automatically set Proxy in the browser. Using the extension user can clear cache, start recording, stop recording, clear recording and add page breaks while recording the user journeys in the browser.

Before you start installing the browser extension, please make sure that you have already followed the steps mentioned in the doc HTTP/S Remote Proxy Recorder and imported the Proxy Server CA Root Certificate.

Browser Extension for Chrome

Open the link https://chrome.google.com/webstore/detail/mlindhmkpdadnkdoicbmijgdecpbioai/ in Chrome and click ‘Add to Chrome’.

After adding the extension to Chrome, we recommend that you pin the extension.

The next step will be setting the proxy details for recording in the extension options. In order to do that first you need to copy the proxy configuration data from the RealLoad portal like below (at the ‘HTTP/S Remote Proxy Recorder | Manage Recording’ screen):

Once you have entered all the necessary RealLoad proxy details and save, you are ready to use the Browser Recorder extension for Chrome.

Now you can go ahead and record your browser sessions by click Start Recording and entering an URL:

You can add Page Breaks while recording by entering the page break name and click the icon marked in the below screenshot:

Once you are done with your recording, click Stop Recording, which will revert the configured RealLoad Proxy to the Browser Automatic Proxy.

Now in the RealLoad portal, you can see the recording under the configured HTTP/S Remote Proxy Recorder screen.

Then proceed as follows:

1. Save te Recording
2. Call the URL Filter Quick Setting to filter out URLs from unwanted hosts
3. Convert the Recording to a HTTP Test Wizard session Doc

Browser Extension for Firefox

Open the link https://addons.mozilla.org/en-US/firefox/addon/realload-test-recorder/ in Firefox and click ‘Add to Firefox’.

Make sure that you have checked the option “Allow this extension to run in Private Windows” during installation - otherwise the Add-On will not work.

After adding the Add-On to Firefox, proceed as described in Recording of a Web Surfing Session

9 - Desktop Companion

The Desktop Companion is a small application that allows you to manage some features related to the RealLoad Platform. The Desktop Companion App can be installed on Windows and macOS systems [ Download ] and includes, among other things, the RealLoad Proxy Recorder component.

In particular the Desktop Companion allows you to:

• Display the Synthetic Monitoring dashboard without timing out
• Upload/Download/Delete project files
• Edit with a local editor Text and CSV files
• Switch between multiple RealLoad accounts
• Generate HTTP Load Test scripts from HTTP archives (.har) files
• Run the RealLoad Proxy Recorder locally
• Perform some basic editing of test scripts
• Upload test scripts directly to the RealLoad Portal
• Manage AWS Measuring Agents (launch, terminate, register with RealLoad Portal) by using your own AWS account

See sections below to learn more about the Desktop Companion.

9.1 - Desktop Companion - Pre-requisites

Before using the Desktop Companion make sure you satisfy the following pre-requisites:

RealLoad Portal User API Authentication Token (required)

In order to upload tests scripts to the RealLoad portal and register the AWS EC2 instances you’ve launched, the Desktop Companion requires that you configure an RealLead authentication token.

To create an authentication token proceed as follows:

Login to the RealLoad Portal and click on the User API Authentication Tokens menu.

Enter a suitable purpose. Optionally you can restrict the source IP address(es) from where this token can be used. Then click on the “Add API Authentication Tokens” button:

Copy the authentication Token Value to the clipboard as you’ll need to configure it in the Desktop Companion.

Input Fields:

• Portal URL : enter https://portal.realload.com/RemoteUserAPI  
• Authentication Token : past the value from the clipboard

AWS API Security Credentials (optional)

In order to use the AWS integration features, you’ll need to prepare Security Credentials with AWS IAM.

Search for “IAM” in the AWS search bar and click on “Users”:

Then add a new user:

Enter a suitable user name and select “Access key” as the AWS credential type.

On the next page set an appropriate policy for the user. Using the “AmazonEC2FullAccess” provides sufficient permissions.

Skip the “Add tags” screen and go to the “Review” screen and click on “Create user”. Make sure the permissions you’ve assigned to the user appear on this screen.

Finally take a note of the Access Key ID and Secret Access Key as thess need to be configured in the RealLoad Desktop Companion.

For further steps see Launching AWS Measuring Agents via the Desktop Companion App

9.2 - Desktop Companion - Settings Menu

Various application settings are configurable in the File Settings menu.

General settings

• Default HAR input folder: Location where to look for .har (HTTP Archives) files by default. This should be the location where your browser writes files to.

• Default export folder: This is the location where RealLoad HTTP test scripts will be exported to in JSON format.

• Agent Secret: The Measuring Agent secret to authenticate connections from the RealLoad Portal to the Cloud Agent instance (AWS EC2 and Azure instances in future).

• Default text editor: Path to the text editor to be used to edit text and CSV files. By default Notepad is configured on Windows and TextEdit on MacOS.

User API settings

• Portal Account: Configure multiple portal accounts if needed, so that you can easily switch between accounts. Select “Enter new name” to add a new account. The Portal URL will default to the RealLoad shared portal.

• Portal URL: The endpoint of the RealLoad portal User API. Unless you have an on-premise installation, use the default value https://portal.realload.com/RemoteUserAPI  

• Authentication Token: Enter here the authentication token that was generated by the Portal as part of the pre-requisites steps. Click on the “Test” button to test the API token.

• Refresh Interval: How frequently should the list of Measuring Agents registered with the RealLoad portal be refreshed. Any value 60 seconds or lower indicates no background refresh, you’ll need to manually trigger a refresh via context menu. By default set to 61 seconds (background refresh enabled).

• Delete Button: Use the Delete button to remove a portal account.

AWS settings

• AWS Access Key ID: Paste the AWS Access Key that was obtained as part of the preparation steps.

• AWS Secret Access Key: Paste the AWS Secret Access key that was obtained as part of the preparation steps. Use the “Test” button to validate the credentials.

• Preferred Instance Type: The EC2 instance type to use when launching a new Measuring Agent instance.

• AWS EC2 Refresh Interval: How frequently should the list of AWS EC2 instances be refreshed. Any value 60 seconds or lower indicates no background refresh, you’ll need to manually trigger a refresh via context menu. By default set to 61 seconds (background refresh enabled).

• My AWS Regions: Select the AWS regions you commonly use. To select multiple regions hold the CTRL key while selecting.

Proxy Recorder settings

• Proxy Port: The TCP port on the local machine that will listen for incoming proxy connections. You’ll need to configure this port as the HTTP proxy in your browser.

• Export CA Certificate: This exports the CA certificate used by reverse proxy to sign SSL certificates. The exported CA should be added as a trusted CA to the browser you’re planning to use to record HTTP requests.

The next settings should be left to default values, unless there are specific reasons for changing them.

• Proxy Backend Server Start Port Range: Starting TCP source port range for connections generated by the Proxy.
• Proxy Backend Server End Port Range: Ending (high) TCP source port range for connections generated by the Proxy.
• Debug HTTP Headers: Enables capturing HTTP headers values in Proxy debug log.

9.3 - Desktop Companion - Monitoring

The Monitoring tab of the Desktop Companion allows you to display the status of your Synthetic Monitoring tests without having to login to the RealLoad portal.

Assuming you’ve configured an API token in the settings window, upon launching the Desktop Application you’ll see the status of your monitoring jobs, as shown in this screenshot:

The application will keep the connection to the RealLoad portal server alive as long as it is running.

9.4 - Desktop Companion - File Menu

Import Test Script

Imports a HTTP Test Wizard session from the RealLoad portal into the Desktop Companion editor.

Import HAR File

Imports an HTTP Archive (.har file) generate by a web browser from a folder of your local desktop into the Desktop Companion editor. This way you can convert HAR files into HTTP Test Wizard sessions.

Export Session to File

Saves the current session of the Desktop Companion editor in HTTP Test Wizard data format on your local desktop.

Export Session to Portal

Uploads the current session of the Desktop Companion editor in HTTP Test Wizard data format to the RealLoad portal. You’ll need to select the Project and Resource Set of the RealLoad portal:

You have 2 options:

• Overwrite existing test script: If you select and existing HTTP Test Wizard session without modifying the filename this will effectively overwrite it.
• Select a resource set: On the other hand if you select a resource set (… “Web Test” in the above screenshot for example) you’ll then have to enter a filename for your new HTTP Test Wizard session.

9.5 - Desktop Companion - Project Explorer

The Project Explorer tab allows you to:

• Download files: Drag and drop file(s) from the RealLoad portal to your desktop. Currently only file file at a time can be downloaded.
• Upload files: Drag and drop file(s) from your desktop to the RealLoad portal. Multiple file section is supported. The files need to be dropped on a Resource Set name (folder name) for the upload to be triggered.
• Edit text files: Select a text or csv file then right click and select the “Edit” option. The text editor you’ve configured in the Settings will open displaying the file content. The file will be uploaded to the portal when locally saved.
• Delete files: Select one or more files on the RealLoad portal then right click and select the “Delete” option in the pop-up menu.

9.6 - Desktop Companion - Editor

In the ‘Editor and Proxy Recorder’ tab you’ll be able to perform some basic editing of the requests imported from an HAR file or recorded by the integrated proxy recorder.

For more complex editing please use the HTTP Test Wizard in the RealLoad portal after uploading your test script there.

Overview

The Editor area is split in 3 main parts:

• HTTP Requests: This section shows all HTTP requests imported from an HAR or recorded by the Proxy Recorder. The context menu accessible via a right click allows you to perform some basic editing functions.
• Request Details: When selecting a request some additional details about the HTTP request will appear, like values extracted from HTTP headers, etc…
• Unique Domains: In this section all unique domain names will be listed. Clicking on a domain will select all relevant rows in the requests table.

Delete Requests

You can mark requests in the main editor window by clicking on them. Hold the ctrl key to mark multiple request or use the shift key to mark a range of requests.

Once marked you can delete the requests by right-clicking on a marked request and selecting “Delete selected” from the context menu:

Adding Time Delays

To add a time delay before or after a request, select the relevant context menu item while hovering over a request. The time delay is currently hardcoded to 1 second, but can modified in the HTTP Test Wizard.

Time delays rows appear as requests of type in the main editor window:

Domain Based Selection

In order to bulk select all requests belonging to specific domains select one or more domains (by holding the CTRL key). This will select corresponding requests in the requests list which can then be easily deleted.

It is also possible to directly delete requests belonging to one or multiple domains using the context menu.

9.7 - Desktop Companion - Proxy Recorder

The Desktop Companion allows you to run the RealLoad Proxy Recorder component locally on your desktop. Recorded HTTP(S) requests will then appear in the Editor tab.

There are two main sections in this chapter:

• How to configure your web browser.
• Hot to record a web session.

Configure your Web Browser

You’ll have to configure the listening TCP port of the integrated RealLoad Proxy Recorder in your web browser (host: 127.0.0.1, default port: 18080). We strongly recommend using a web browser that allows you to configure proxy settings independently of the operating system’s proxy settings, for example Firefox (Chrome and Edge do not support this feature).

Import the Proxy Recorder CA Certificate

For the web browser to trust HTTPS (SSL) web server certificates issued on the fly by the local Proxy Recorder, you’ll need to import the Proxy’s CA certificate as follows:

1: First export the Proxy Recorder CA certificate to a file: In the Desktop Companion’s “Proxy Recorder” tab, click the “Export CA Certificate”. Then select a folder where the certificate is to be stored. It will be stored in a file named RecProxyCert.cer.

2: Then import the Proxy Recorder CA certificate into Firefox: In Firefox call Settings

Click Privacy & Security:

Scroll down to Security - Certificates, and click ‘View Certificates…’

In the Firefox Certificate Manager click first on Authorities and then on ‘Import…’

Select the CA Root Certificate you downloaded before and check the “Trust this CA to identify websites” box. Then click OK

The CA Root Certificate is now imported into Firefox:

Configure Proxy Settings

In the Firefox “Settings” scroll to the bottom of the page where “Network Settings” are located.

Select “Manual proxy configuration” and configure the Proxy Host to 127.0.0.1 and the Proxy Port to 18080 for both HTTP and HTTPS. Enable the checkbox “Also use this proxy for HTTPS” and click the “OK” button.

Test Browser Configuration

Navigate to any HTTPS page. You shouldn’t see any warnings about untrusted SSL certificates beings used.

If you check the certificate of the site you’re visiting, the issuer should be “Real Load Pty Ltd”, as shown in the below screenshots.

Recording a Web Session

Before starting recording, you should clear the browser cache each time.

Then navigate to the “Editor and Proxy Recorder” tab and expand the “Proxy Recorder Controls” area:

To start the recording click on the “Start Recorder” button:

Then enter the URL in the web browser:

We recommend adding Page Breaks while recording - every time before you click a button in the web browser or submit a form.

Click “Stop Recorder” after recording is completed.

After recording, proceed as follows:

1. Restore the original proxy settings in the browser and, if necessary, delete the Proxy Recorder CA certificate in the browser.
2. Delete HTTP requests for unwanted domains.
3. Upload the recorded web session to the RealLoad portal and post-edit it in the HTTP Test Wizard.

9.8 - Desktop Companion - AWS Measuring Agents

The AWS tab allows you to manage cloud based Measuring Agents by using your own AWS account. This section of the application will be of most use if you configured AWS credentials in the preferences section of the application.

If no AWS credentials are configured, you won’t be able to start and terminate AWS instances.

Listing AMIs

In the left pane you’ll see a list of available AWS AMIs. You can further filter the list of AMIs by selecting a specific version and/or by selecting an AWS region.

Type:

• MA = Measuring Agent
• CC = Cluster Controller

Launching an Instance

To launch an new EC2 instance right-click on the relevant AMI and select “Launch”. A screen to confirm the launch will be displayed. Confirm by clicking on the “Launch” button.

When launching an instance in an AWS EC2 region that is not yet part of your “My Regions” list, the region will be automatically added to the list.

Launching a new instance will automatically trigger a refresh of the AWS Measuring Agents list. It might take a few second for the list to update and the new instance to be reflected in it.

A window will appear in which you can check the configuration of the instance and set the instance auto-terminate time period. You can also choose a value of zero for the auto-terminate time period, which means that the instance will continue to run until you stop it.

Listing running EC2 Instances

After launching an instance go to the top right part of the window listing the running instances and right click on “Refresh”. This will retrieve all running EC2 instances from the preferred AWS regions and display them in the table.

Registering an Instance

To register an AWS instance with the RealLoad wait Portal right-click on the instance and then select the “Register with portal” menu item. The instance ID will be used as the description in the RealLoad Portal.

List registered Instances

In the right bottom part of the window you’ll see the Measuring Agents currently registered on the RealLoad Portal. To update the list right click and select the “Refresh” option.

De-register an Instance

In order to de-register an instance from the RealLoad Portal right click on the instance name and select “De-register”.

Terminate an Instance

To terminate an AWS EC2 instance right click on the instance name.

9.9 - Release Notes

0.27 | 14 Nov 2024

• Functionality: Added Monitoring tab to display the Synthetic Monitoring dashboard.
• Functionality: Added the Project Explorer tab, allowing to upload/download/delete project resources.
• Functionality: Added the ability to configure and switch between multiple RealLoad accounts.
• Bug fixes: Various minor bugfixes.
• Download URL Windows full installer: https://rllargefiles.blob.core.windows.net/rldc/RLDTC_windows-x64_0_27.exe  
• Download URL OS X x64: https://rllargefiles.blob.core.windows.net/rldc/RLDTC_macos_x64_0_27.dmg  
• Download URL OS X ARM: https://rllargefiles.blob.core.windows.net/rldc/RLDTC_macos_arm_0_27.dmg  

0.26 | 6 Nov 2022

• Bug fix: Fixed an SSL related issue preventing recordings from OS X / iOS.

0.25 | 28 Oct 2022

• Functionality: Updated Desktop Companion to support Portal v4.7.3. Plz update to this version.

0.24 | 21 Mar 2022

• Functionality: Added support for AWS Cluster Controller images.
• Note: Before using Cluster Controller AMIs, using the AWS console remove the Real Load security group. It will be automatically re-created with new settings once you start an AWS instance.
• Functionality: Moved proxy recorder controls to Editor tab. List of recorded requests updated in real time.
• Functionality: Added various new Proxy Recorder related options (auto-page breaks, etc…).
• Functionality: When launching an AWS image you can now specify an auto-shutdown timeout.

0.23 | 25 Jan 2022

• Functionality: Added ability to assign an elastic IP to a running EC2 instance.
• Security: Update to address Log4j Shell CVE-2021-44228

0.22 | 13 Dec 2021

• Usability: Allow adding page breaks as you navigate from page to page while recording.
• Usability: Added a real-time counter of the requests being recorded.
• Usability: Added a button to force the Desktop Companion window on top of others, so it doesn’t get hidden by browser windows.

0.21 | 9 Dec 2021

• Usability: Proxy Recorder log is always deleted when starting a new recording.
• Usability: Added a “Delete” contextual menu to the “Unique Domains” window.
• Packaging: The Windows Installer is now signed with a Code Signing certificate.

0.20 | 3 Dec 2021

• Usability: Added help links to online documentation.
• Usability: Added various configuration checks and related alert dialogs.
• Usability: On exit, added alert in relation to running AWS EC2 instances.
• Usability: List of AWS instances is updated via a background thread, periodically.
• Usability: List of registered Measuring Agents is updated via a background thread, periodically.
• Usability: The AWS region where an EC2 instance is launched is automatically added to “My Regions” list.
• Installer: Created a Windows full installer that includes a JRE.
• Bugfix: Fixed an issue with HAR files containing POST requests with no content type.
• Bugfix: Updated JavaFX to v17

0.10 | 8 Nov 2021

• Documentation: Desktop Companion Documentation initial release.
• Application: Initial release.

10 - Mobile Companion App

Abstract

App Features

• This App gives you an overview of the status of your Synthetic Monitoring Jobs at any time - without having to sign in to the Portal Server.
• The App also notifies you immediately if a Monitoring Job detects an error or warning.
• The use of multiple Mobile Devices per Portal Server main user account and its team member accounts is supported.
• Each Mobile Device can be a member of one or multiple Monitoring Alert Groups, thereby causing different types of Alert Notifications to be sent to different Mobile Devices.

Prerequisites:

• Any device running Android version 9 or newer, or running iOS version 11.0 or newer.
• You need a RealLoad Portal Server account, i.e. the App cannot be operated “stand-alone”. If you don’t have a RealLoad Portal Server account you can Sign Up for Free and follow the instructions to create your first Synthetic Monitoring job.
• You should have at least one Synthetic Monitoring Job configured.

Installation

Android

In order to receive notifications at any time, we recommend that you switch off the App option “Pause app activity if unused”.

iOS

You should allow the app to send you notifications at any time.

App Configuration - Login to the Portal Server

When you start the App for the first time, you have to log in to the portal server. Enter the same username and password as for a normal portal server sign-in.

In the background, during the login process on the portal server, a so-called “API Authentication Token” is generated with the purpose “RealLoad Mobile App” which is permanently stored in the Mobile Companion App.

Portal Server:

Testing the App

After you have installed and configured the App, you should test the receipt of push notifications.

1. Sign in to the Portal Server using a web browser
2. Navigate to User - Mobile Companion
3. Send a Test Notification
4. Check the receiving of the Notification

Synthetic Monitoring Dashboard - Simplified View

1. Click “Monitoring” at the bottom of the App. This will display the status of your Monitoring Groups.
2. Click on a Monitoring Group. This displays the status of the corresponding Monitoring Jobs.

If Synthetic Monitoring warnings or errors were detected, the background color changes to yellow or red:

Configuration as Alert Device

1. Sign in to the Portal Server using a web browser.
2. Navigate to Synthetic Monitoring - Alert Groups & Devices.
3. In the Mobile Companion section, click the Expand icon.
4. In the Mobile Companion section, click the Add icon.
5. Select the Mobile Companion Device and click the “Add Mobile Companion Alert Device” button.
6. The Mobile Companion Device is now shown in the Mobile Companion section. Click the “Add to Alert Groups” icon.
7. Select one or multiple Alert Groups and click the “Add Alert Device to Alert Groups” button.

When you set up a mobile device as an alert device for the first time, we recommend that you double check whether all alert notifications have been received. Proceed as follow:

1. Sign in to the Portal Server using a web browser.
2. Navigate to User - Mobile Companion.
3. Select the “Transmitted Push Notifications” tab.
4. Compare the number and type(s) of the transmitted notifications of your Device Id with the number of shown messages in the Mobile Companion App.

Tip: You can get the unique Device Id at any time by clicking “Settings” at the bottom of the App.

11 - Table Server

It is an API Service which holds all the API requests, which can be used to store the test data in table formats in a Database, which can be consumed/produced by both load test and synthetic monitoring tests. So it acts like a Test Data database where multiple scripts can consume common test data.

Currently, the Tests need Plugins to communicate with the Table Server API, but in near future we will come up with a solution where performance Engineers can write inline javascript in the test to communicate with the Table Server APIs.

Below are the API Requests that Table Server supports

• Create a Table with the JSON input, an overwriteFlag flag will be optional here, if set to true, it will overwrite the existing table with the same name.

  curl -k --location --request POST 'https://{{tableserverURL}}:8084/Api' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "apiAuthToken": "{{apiAuthToken}}",
  "action": "createNewTable",
  "tableName": "Products",
  "columnNamesAndValues": [
        {
            "ProductGroup": "Icecream",   
            "ProductName": "Vanilla"
        },
        {
            "ProductGroup": "Pizza",   
            "ProductName": "Margareta"
        }
    ]
  }'

• Create a Table with the CSV file data, an overwriteFlag flag will be optional here, if set to true, it will overwrite the existing table with the same name.

  curl -k --location --request POST 'https://{{tableserverURL}}:8084/Api' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "apiAuthToken": "{{apiAuthToken}}",
  "action": "createNewTableFromCSVFile",
  "uploadFileName": "Products.csv",
  "delimiter": ",",
  "uploadFileDataB64": "UHJvZHVjdEdyb3VwLFByb2R1Y3ROYW1lLFByaWNlDURyaW5rcyxDb2NhQ29sYSwxMApEcmlua3MsUGVwc2ksNwpEcmlua3MsN1VwLDgKRHJpbmtzLEZhbnRhLDkKUGl6emEsTWFyZ2FyZXRhLDEwDQ=="
  }'

• Get All the Tables from Table Server with or without column details.

  curl -k --location --request POST 'https://{{tableserverURL}}:8084/Api' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "apiAuthToken": "{{apiAuthToken}}",
  "action": "getAllTables",
  "includeColumns": true
  }'

• Create a single test data, can also pass an optional parameter “uniqueFlag” to 1, so that it will make sure that the column value is unique.

  curl -k --location --request POST 'https://{{tableserverURL}}:8084/Api' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "apiAuthToken": "{{apiAuthToken}}",
  "action": "insertColumn",
  "table": "Products",
  "column": "ProductGroup",
  "value": "Sweets"
  }'

• Get a single test data, returns first row value for the given column and marks that as retrieved in the table. Supports an additional parameter rowIndex for getting the same value multiple times during the execution of the tests.

  curl -k --location --request POST 'https://{{tableserverURL}}:8084/Api' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "apiAuthToken": "{{apiAuthToken}}",
  "action": "retrieveColumn",
  "table": "Products",
  "column": "ProductName"
  }'

• Update a single test data.

  curl -k --location --request POST 'https://{{tableserverURL}}:8084/Api' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "apiAuthToken": "{{apiAuthToken}}",
  "action": "updateColumn",
  "table": "Products",
  "column": "ProductGroup",
  "value": "Fruits",
  "rowIndex":1
  }'
  

• Create multiple test data.

  curl -k --location --request POST 'https://{{tableserverURL}}:8084/Api' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "apiAuthToken": "{{apiAuthToken}}",
  "action": "insertRow",
  "table": "Products",
  "columnsAndValues": [
        {
            "ProductGroup": "Vegetables",      
            "ProductName": "Carrot"
        }
    ]
  }'

• Get multiple test data, returns first row values for given columns and marks that as retrieved in the table. Supports an additional parameter rowIndex for getting the same value multiple times during the execution of the tests.

  curl --location --request POST 'https://{{tableserverURL}}:8084/Api' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "apiAuthToken": "{{apiAuthToken}}",
  "action": "retrieveRow",
  "table": "Products",
  "columns": [
            "ProductGroup",    
            "ProductName"
    ]
  }'

• Query a table with column names and values, if not provided Column Names and Values, the entire table data will be retrieved.

  curl -k --location --request POST 'https://{{tableserverURL}}:8084/Api' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "apiAuthToken": "{{apiAuthToken}}",
  "action": "queryTable",
  "table": "Products",
  "columnNamesAndValues": [
        {
            "ProductGroup": "Vegetables",   
            "ProductName": "Carrot"
        }
    ]
  }'

• Export a table as CSV file data.

 curl --location --request POST 'https://{{tableserverURL}}:8084/Api' \
 --header 'Content-Type: application/json' \
 --data-raw '{
 "apiAuthToken": "{{apiAuthToken}}",
 "action": "exportTableToCSV",
 "table": "Products"
 }'

12 - OSHI Daemon

Abstract

The OSHI daemon measures and collects operating system and hardware information and can be installed on Linux and Windows systems.

Access to the measurement data is via a WebSocket API, whereby the authentication token of the OSHI daemon must be provided.

API Functions

The API supports the following functions (so-called “actions”):

• getAboutRealLoadOshiDaemon : Provides general information about the OSHI daemon, including its product version.
• getOperatingSystemInfo : Get general information about the operating system.
• getCpuInfo : Get a snapshot of the CPU information.
• getMemoryInfo : Get a snapshot of the memory information.
• getNetworkInfo : Get a snapshot of the network information.
• getNetworkConnectionsListInfo : Get a list of all TCP and UDP connections
• getDiskInfo: Get a snapshot of the local disks information.
• getFileSystemInfo : Get a snapshot of the file system information.
• getProcessListInfo : Get a list of all OS processes.
• getProcessInfo : Get a snapshot of a specific OS process information.
• getInternalLog : Get the last 2000 lines of the OSHI daemon log.
• getOshiInformationLastHistoricalSnapshot : Get a snapshot of the latest collected OSHI data without any overhead.
• subscribeToOshiInformation : Subscribe to OSHI real-time information.
• unsubscribeFromOshiInformation : Unsubscribe from OSHI real-time information.

The authentication token can either be passed as a HTTP request header field or as a query string parameter.

Example: wss://192.168.1.27:8087/api?authToken=aaa&subscribeToHeartbeat=true

All API data are send and received in JSON data format. Numeric values of -1 (minus one) means “no such data available”. The API responses will never contain null values.

Runtime Behavior

• When the WebSocket connection is closed, all subscriptions are terminated.
• When you send an “action”, the action is confirmed with a response frame with the name of the action repeated.
• If you send an invalid “action”, the WebSocket connection will be closed.
• The WebSocket connection doesn’t last forever. It will be closed after a few hours. You then have to reestablish the WebSocket connection and renew the subscriptions.

Received Periodic Heartbeat

{
  "action": "realtimeHeartbeat",
  "timestamp": 1718904334079,
  "isError": false
}

getAboutRealLoadOshiDaemon

• Send action : “getAboutRealLoadOshiDaemon”

{
  "action":"getAboutRealLoadOshiDaemon"
}

• Received action: “getAboutRealLoadOshiDaemon”

{
  "action": "getAboutRealLoadOshiDaemon",
  "timestamp": 1719597333886,
  "productVersion": "1.0.2",
  "productReleaseDate": "25 Jun 2024",
  "aboutThisOshiDaemonText": "This daemon runs in unprivileged mode, so some detailed values may not be captured or displayed.",
  "aboutThisOshiDaemonSupportEmailAddress": "support@realload.com",
  "collectOshiSubjectsList": "CPU,MEMORY,NETWORK",
  "collectOshiSubjectsIntervalSeconds": 5,
  "CollectOshiSubjectsMaxStorageTimeSeconds": 43200,
  "isError": false
}

getOperatingSystemInfo

• Send action : “getOperatingSystemInfo”

{
  "action":"getOperatingSystemInfo"
}

• Received action: “getOperatingSystemInfo”

{
  "action": "getOperatingSystemInfo",
  "operatingSystemInfo": {
    "oshiSubject": "OPERATING_SYSTEM",
    "infoTimestamp": 1718896045383,
    "osManufacturer": "GNU/Linux",
    "osFamily": "Ubuntu",
    "osVersion": "20.04.6 LTS",
    "osBuildNumber": "5.4.0-176-generic",
    "systemBootTimestamp": 1715870847,
    "systemUpTimeSeconds": 3025197,
    "processCount": 145,
    "threadCount": 243
  },
  "isError": false
}

getCpuInfo

• Send action : “getCpuInfo”

{
  "action":"getCpuInfo"
}

• Received action: “getCpuInfo”

{
  "action": "getCpuInfo",
  "cpuInfo": {
    "oshiSubject": "CPU",
    "infoTimestamp": 1718896380637,
    "infoDeltaMillis": 1217,
    "physicalProcessorCount": 4,
    "logicalProcessorCount": 4,
    "logicalProcessorsCurrentFrequencyHz": 1129519488,
    "logicalProcessorsMaxFrequencyHz": 2900000000,
    "systemCpuLoadPercent": 3.3268101,
    "totalContextSwitches": 1232984118,
    "deltaContextSwitches": 891,
    "contextSwitchesPerSecond": 732,
    "totalInterrupts": 665000639,
    "deltaInterrupts": 517,
    "interruptsPerSecond": 425
  },
  "isError": false
}

getMemoryInfo

• Send action : “getMemoryInfo”

{
  "action":"getMemoryInfo"
}

• Received action: “getMemoryInfo”

{
  "action": "getMemoryInfo",
  "memoryInfo": {
    "oshiSubject": "MEMORY",
    "infoTimestamp": 1718896700858,
    "infoDeltaMillis": 1001,
    "totalPhysicalMemoryGib": 15.372253,
    "usedPhysicalMemoryGib": 1.142189,
    "availablePhysicalMemoryGib": 14.230064,
    "availablePhysicalMemoryPercent": 92.5698,
    "maxVirtualMemoryGib": 11.686123,
    "totalVirtualMemoryGib": 3.9999962,
    "usedVirtualMemoryGib": 0,
    "availableVirtualMemoryGib": 3.9999962,
    "totalHardPageFaults": 0,
    "deltaHardPageFaults": 0,
    "hardPageFaultsPerSecond": 0,
    "totalPagesWrittenToSwap": 0,
    "deltaPagesWrittenToSwap": 0,
    "pagesWrittenToSwapPerSecond": 0
  },
  "isError": false
}