Components and data flow

This section describes the system.

Architecture and components

This section describes the architecture and components.

Architecture/Component	Description
Database server	The database server stores four types of schemas: Site Management schema. Stores information related to each tenant in the system, including users and site management tasks. A row exists in this schema for each tenant you create. Site Administration schema. Stores information related to the system, such as domains, users, and site parameters. A row exists in this schema for each project you create. Irrespective of how you configure your system, there is always only one Site Administration schema. Lab Management. Stores lab information related to managing lab resources, such as hosts and host pools, and for managing assets, such as servers, licenses, and usage reports. There is always only one Lab Management schema. Project schemas. Stores project information, such as entity data and user data. A separate schema exists for every project you create. The schemas can reside on an Oracle, Microsoft SQL, or PostgreSQL server. Note: To improve system performance, it is advisable that the OpenText Enterprise Performance Engineering server and the Database server be installed on separate machines and be connected over LAN.
Project repository	Stores all files to be used by all the projects in the system. For example, scripts, run results, .xml files, templates, and attachments. By default the repository is located on the same machine as the application server, which is useful for smaller setups. For larger organizations however, or when working in a clustered environment, it is advisable to install the repository on a dedicated machine. When working in a clustered environment, the repository must be accessible by all nodes.
OpenText Enterprise Performance Engineering Server	Hosts the web pages that enable you to design performance tests, configure monitors, reserve testing resources, run and monitor test runs, and analyze test results.
Administration	The center for managing lab resources, such as hosts and host pools, and for managing assets, such as servers, licenses, projects, runs, timeslots, and system usage reports. Also used for managing cloud settings when using cloud hosts, and automated maintenance of the system's key components to detect system failures.
OpenText Enterprise Performance Engineering Hosts	Used to control performance tests, generate load, and analyze data. Hosts can be configured as Controllers, load generators, or data processors: Controller. The manager of a performance test. The Controller receives scripts, runtime settings, and a list of load generators to use. The Controller issues instructions to the load generators including which scripts to run, how many Vusers to run per script, and scheduler settings. At the conclusion of the test run, the Controller collates the data. There is only one Controller per performance test. Load Generator. Generates load by running virtual users, otherwise known as Vusers. The Controller dictates the manner in which they start and stop running. There can be any number of load generators for a test. Data Processor. Used for analyzing and publishing performance test results.

Applications

The following standalone applications integrate with your system.

Application	Description
Analysis	Provides graphs and reports with in-depth performance analysis information. Using these graphs and reports, you can pinpoint and identify the bottlenecks in your application and determine what changes need to be made to your system to improve its performance.
MI Listener	Needed when running Vusers and monitoring applications over a firewall.
Monitors Over Firewall Agent	Used to monitor servers that are located over a firewall.
OneLG	A combined (standalone) load generator installer for all of the OpenText Performance Engineering family products.
Virtual User Generator (VuGen)	Generates Vusers by recording actions that typical end-users would perform on your application. VuGen records your actions into automated Vuser scripts which form the foundation of your performance tests.

Use the diagram and table in the Communication paths and Load considerations sections to determine which machines to allocate for which performance testing tasks.

For example, you can combine a number of applications that have a light load on a single machine. For details on which standalone applications can be installed together, see the Support Matrix.

For information on installing the standalone applications, see Install standalone and additional components.

Communication paths

When installing, it is important to consider the communication paths between the components, and their resource demands.

Component overview

When running a performance test, components share information using a distinct system of communication. Understanding which components communicate with one another and the method of communication is essential for configuring your system.

The following diagram illustrates the communication paths in an advanced deployment:

Note:

To view other deployment options that can be used for configuring on‑premises or on the cloud, see Deployment examples.
If the installation cannot use a default port because it is already in use, you can change the port. For details, see Unable to install a component if the default port is in use.
You cannot have a firewall between the server, hosts used as Controllers, and MI Listener.
Port 8182 from hosts to load generators is relevant when running network virtualization emulation for viewing NV related graphs during online. If the port is closed, graphs are still available in the offline results and the Analysis report.
Connections from APM tools to the AUT are not displayed in the diagram. Each AUT tool uses its own ports, which can be found in the corresponding product’s documentation.
When using a load balancer for servers:
- The load balancer needs to be configured for sticky sessions based on the HTTP cookie ASP.Net_SessionId.
- You need to configure WebSocket on the load balancer. However, if you have SSL configured on the load balancer only (and not on the servers), you need to terminate SSL for WebSocket on the load balancer.
- You may need to address the Secure Flag vulnerability. For details, see Secure flags on session cookies.

Connection ports

The following table displays the connection ports that must be opened for incoming traffic on the various components.

Component	Ports
OpenText Enterprise Performance Engineering Server	HTTP: 80* **
OpenText Enterprise Performance Engineering Host	HTTP: 8731, 3333 TCP: 54345 8182 for hosts used as Load Generators to see online graphs for NV emulation information. If the port is closed, you can still see NV information in the offline results. 8731 for the server to communicate with the Load Testing Operator service that orchestrates the test. 8086 for a server or host to get online or offline analysis data. The port must be open for outgoing communication from the server, and for incoming communication for the host (for an internal database). For an external database, the port must be open for both incoming and outgoing communication from the server and host. 54345 for the Agent Service. Enables the Controller to connect to this host when it acts as a Load Generator. 3333 for the Remote Management Agent Service. Enables the server to perform lab maintenance operations on this host.
Database	TCP: 1433 (Microsoft SQL) 1521 (Oracle) 5432 (PostgreSQL)
Repository	NetBIOS
Standalone Load Generator	TCP: 54345, HTTP: 3333 8182 to see online graphs for NV emulation information. If the port is closed, you can still see NV information in the offline results.
Cloud-based Load Generator	As defined in the Cloud Network Settings dialog box. For details, see Initial cloud settings.
MI Listener	HTTP/TCP (load generator only): 443** TCP (OpenText Enterprise Performance Engineering server, host used as a Controller only): 50500
SiteScope - Monitor Profiles	HTTP: 8888*

* HTTPS is also supported on this component.

** Default values that can be changed during configuration.

Secure flags on session cookies

The Missing Secure Flags on Session Cookies security vulnerability, may pose a risk of exposure if transmitted over unencrypted HTTP.

This issue may occur when SSL termination is implemented on a load balancer.

The procedure below describes how to configure an OpenText Enterprise Performance Engineering server to set secure cookies when SSL offloading is implemented on load balancer:

To configure a secure cookie:

In appsettings.default.json, set the following flag:

"CookieAdditionalSettings": {

"IsCookieSecure": true

},
Restart the backend service.
Run iisrestart.

Note: Access to the OpenText Enterprise Performance Engineering server is restricted to localhost connections. You will not be able to access a specific server with a VPN directly via its IP address. This limitation applies to all SaaS deployments and if you are using HTTP over a Load Balancer.

Load considerations

The following table provides some basic installation considerations for each component.

Machine	Quantity in the system	Load Considerations
OpenText Enterprise Performance Engineering Server	At least one. Also supports cluster configuration. For details, see Clustered configuration.	Heavy load. To balance the load, you can install and configure external load balancers. For additional load balancing support, you can install multiple servers.
OpenText Enterprise Performance Engineering Hosts: Controller, Load Generator, and Data Processor	At least one of each.	Controller has heavy load. Load generator has medium load. Data processor has medium to high load. It is recommended to designate spare Controllers and load generators for fault-tolerance and high availability purposes. Note: You can configure a host as a Controller + Load Generator, but this is not recommended because running Vusers consumes a lot of resources. Running Vusers on the Controller host is only appropriate for performance tests that have a small number of Vusers. You can configure a host as a Controller + Data Processor, but this is not recommended because data processing might consume high amounts of CPU and resources.
MI Listener	At least one, if you are monitoring over a firewall.	Medium load. Standalone installation is required. Cannot exist on a machine running IIS.
Monitor Over Firewall machine	At least one, if you are monitoring over a firewall.	Light load. Standalone installation is required.
SiteScope (optional)	One	Light load.

Tip: Consider the communication paths between different components and their resource demands. This information helps you configure your system to evenly distribute the load, and prevent overloading any resource. For details, see Communication paths.

Distributed Denial of Service attack protection

Consider implementing DDoS attack protection on servers hosting OpenText Enterprise Performance Engineering Web client only in cases where your Web client is exposed to the public Internet. In most production environments, deploying Web client on the public Internet are rare, therefore carefully consider if this best practice applies to your specific deployment.

A few DDoS attacks such as Slowloris may be mitigated by implementing third party protections such as the following:

Setting request limits.
Setting header limits.
Restricting IP addresses.

For details, see the relevant Microsoft IIS documentation.

In addition, you can also apply restrictions, such as setting timeouts and header limits, in the PCWEB\Web.config and PCWEB\PCX\Web.config files.

Note: Due to the nature of these attacks, it is not possible to implement application-specific fixes or enhancements to prevent these types of attacks.

Clustered configuration

OpenText Enterprise Performance Engineering can be run on a single node cluster. A cluster is a group of application servers that run as if they were a single system. Each application server in a cluster is referred to as a node.

Clusters provide mission-critical services to ensure maximum scalability. The load balancing technique within the cluster is used to distribute client requests across multiple application servers, making it easy to scale to an infinite number of users.

Take the following into consideration when setting up a clustered environment:

All nodes must have access to the database server on which you configure the system.
All nodes must have access to the repository. For example, if the repository is located on the first node in the cluster, all other nodes must have access to the first node. If you install the repository on a dedicated machine, each node must have access to that machine.
The load balancer must be configured with session persistency. Set the persistency to sticky session enabled or destination address affinity, depending on the load balancer.

The following diagram illustrates a clustered system configuration.

Clustered system configuration

Prerequisites for clustering

You can install OpenText Enterprise Performance Engineering on a single node or as a cluster. This section describes the prerequisites for installing as a cluster on a Windows environment.

Check with your system administrator whether you are installing on a single node or as a cluster.
If you are installing on cluster nodes, verify which machine to use as the first node to start the installation and the number of machines you should use. This depends on the number of users and availability considerations.
When creating a common repository for the cluster nodes, the folder must be shared with the domain user used for configuring the cluster nodes.
The OpenText Enterprise Performance Engineering account should be set with a domain user that has the correct permissions for setting a cluster environment; the IUSR_METRO user does not have permissions on a remote repository or on the IIS web server of the first node and on hosts.
Install each cluster node with the same domain and user as configured in the first node. The name is case sensitive.
Configure each node with the same Site Administration and Lab database schema names (not just the same database server).

This is important because when a node is installed in cluster mode, the Lab schema name is not read from the common repository. For example, if node A is installed with schema names LRE_ADMIN_MYSCHEMA and LRE_LAB_MYSCHEMA, when node B is installed, the schema names is automatically populated in the Configuration wizard with LRE_ADMIN_MYSCHEMA and LRE_DEFAULT_LAB_DB.

Therefore, you need to manually change the Lab database schema name from LRE_DEFAULT_LAB_DB to LRE_LAB_MYSCHEMA.
You must use the same communication passphrase on all nodes.

For details on installing as a cluster, contact OpenText support.