Installation and configuration best practices

This section details best practices for installing and configuring Digital Lab.

Digital Lab can be installed as a full installation (where there is no previous installation) or as an upgrade on top of an existing installation. The installer checks which files are already installed and installs or updates the relevant files.

General deployment considerations

Digital Lab supports a distributed architecture in which different test clients can interact with the same Digital Lab server instance.

Digital Lab deployment has several components:

Component	Function
Digital Lab server	This is a single web server that can be installed on a physical or virtual environment. It serves to: Mediate between the testing-tool client calls to mobile devices and provide a user interface within the testing tool for recording and running tests on real mobile devices. Accept apps for testing and manage app versions. Provide a user interface (Lab Management console) for administrators to: Manage users. Manage apps and view their properties such as OS and version. Control devices: restart, unlock or open a device remotely. View and manage connectors. Configure various settings for users such as proxy definitions and packaging services. Enable extended services such as security scans, production usage, crowd testing, and SDK compliance. Note: When you install the Digital Lab server, you have the option to install an embedded connector if you want to connect devices directly to the Digital Lab server instance
PostgreSQL database	You can choose either to connect Digital Lab to an existing external PostgreSQL database, or use the database that is embedded in the Digital Lab Server installation. You specify this option during installation. For details, see Digital Lab - Windows Installation or Digital Lab- Linux Installation.
Connector	The connector is designed as a lightweight piece of software for connecting devices to Digital Lab and can be installed as a standalone component. You can install the connector on multiple machines in distributed locations, or on your testing-tool machine. The connector can be installed on a Windows, Linux, or Mac machine. The connector is designed as a lightweight piece of software for connecting devices to Digital Lab and can be installed as a standalone component. You can install the connector on multiple machines in distributed locations, or on your testing-tool machine. The connector can be installed on a Windows, Linux, or Mac machine
High Availability	You can configure high availability in an active-passive configuration using multiple servers. In this mode, there is one active Digital Lab server, to which the load balancer routes all the requests, and another passive Digital Lab server ready to take over in case the active server fails. For details, see High Availability support .
File Storage System	Applications are no longer stored in the database but are saved to the file system. When installing or upgrading, you can select a destination folder for storing applications uploaded to Digital Lab. You can also control the number of uploads per application and choose to automatically delete old uploads of an application. This makes it easier for the Digital Lab administrator to manage the number of application uploads that need to be maintained and reduces the load on the file storage system. For details, see the section on configuring application file storage in Digital Lab - Windows Installation and the section Limit application uploads under General Administration settings.

Deployment scenarios

The decision point for Digital Lab deployment scenario varies according to customer requirements.

Scenario	Description	Advantages
All-in-one	Single box deployment for Digital Lab server, database, and embedded connector.	Simplicity. Ideal for proof of concept and local installations.
3-Tier deployment	Separate web and data layers by installing Digital Lab server and databases on different locations.	Scalability of web and database layers. Supports local IT best practices for web and database management.

For the deployment of connectors/devices, the following scenarios can be considered:

Scenario	Description	Advantages
Central device hub	A central lab of devices connected to the connector on the Digital Lab server machine.	Efficiency. Avoids duplication of tasks for setting up and managing devices
Distributed device hubs	Connectors installed on machines in multiple locations (on-site/offsite/globally dispersed).	Scalable. New labs can be added as needed.
Bring your own device	Connector installed on a developer's/testing engineer's machine.	Supports hands-on testing of the app on the device.

Hardware requirements

The full list of hardware requirements for Digital Lab is available in the Support matrix.

When planning Digital Lab hardware resources, consider the following parameters:

Component	Memory	CPU	Disk Space
Digital Lab server	Digital Lab Server is a Java application. Therefore, it uses a predefined amount of host memory. The amount of consumed memory is impacted by the number of simulation sessions (user sessions). The minimal memory requirement is 4 GB. We recommend 8 GB for medium deployment (<30 devices), and 16 GB for large deployment (>30 devices). * Based on your machine memory we recommend you increase the maximum heap size for the Java virtual machine (JVM) when installing, upgrading, or modifying the Digital Lab server for example: if the machine had 8 GB you can increase the Java heap size to 4GB.	Digital Lab Server CPU consumption is dependent on the number of requests that are processed. The minimal requirement is an x64 processor, 2.2 GHz	Disk space usage on the Digital Lab Server depends on several factors such as logs generated, packaged applications, and processes. We recommend at least 20 GB: 15 GB for general installation and 5 GB for the temporary folder. Please note that in versions 3.5 and above, you can specify a temporary folder different than TMP/TEMP. An additional 1 GB of free disk space is required on the system disk.
PostgreSQL DB	PostgreSQL memory consumption is impacted by SQL queries that it is required to execute. The minimal requirement for memory is 2 GB. We strongly recommend at least 8 GB for medium deployment (<30 devices), and 16 GB for large deployment (>30 devices).	PostgreSQL is process-based. The minimal requirement is a dual-core CPU, 2.2 GHz.	Disk space usage on PostgreSQL depends on the data size. On Windows, PostgreSQL is installed on the C: drive, so disk space must be allocated there.
Connector	Digital Lab Connector is a Java application. Hence, it uses a predefined amount of host memory. The amount of consumed memory is impacted by the number of simulated sessions (user sessions). The minimal requirement is 2 GB. * We recommend at least 8 GB for standard deployments (8-10 devices per connector), and 16 GB for large deployments (12-25 devices).	The guidelines for Digital Lab Server are the same for the Connector Java application. Remote access to the device increases the CPU consumption and must be considered. The connector hardware must be planned according to the expected concurrent sessions on mobile devices. It differs slightly between Windows, Linux, and Mac connectors. The rule of thumb is to allocate one-half of the CPU Core for each remote device session	The disk space usage on the Digital Lab Connector depends on various factors, such as the number of logs generated, and the number of application files cached on the connector. We recommend at least 10 GB.

Component

Memory

CPU

Disk Space

Digital Lab server

Digital Lab Server is a Java application. Therefore, it uses a predefined amount of host memory. The amount of consumed memory is impacted by the number of simulation sessions (user sessions). The minimal memory requirement is 4 GB. We recommend 8 GB for medium deployment (<30 devices), and 16 GB for large deployment (>30 devices).

* Based on your machine memory we recommend you increase the maximum heap size for the Java virtual machine (JVM) when installing, upgrading, or modifying the Digital Lab server for example: if the machine had 8 GB you can increase the Java heap size to 4GB.

Digital Lab Server CPU consumption is dependent on the number of requests that are processed. The minimal requirement is an x64 processor, 2.2 GHz

Disk space usage on the Digital Lab Server depends on several factors such as logs generated, packaged applications, and processes.

We recommend at least 20 GB: 15 GB for general installation and 5 GB for the temporary folder. Please note that in versions 3.5 and above, you can specify a temporary folder different than TMP/TEMP.

An additional 1 GB of free disk space is required on the system disk.

PostgreSQL DB

PostgreSQL memory consumption is impacted by SQL queries that it is required to execute. The minimal requirement for memory is 2 GB. We strongly recommend at least 8 GB for medium deployment (<30 devices), and 16 GB for large deployment (>30 devices).

PostgreSQL is process-based. The minimal requirement is a dual-core CPU, 2.2 GHz.

Disk space usage on PostgreSQL depends on the data size. On Windows, PostgreSQL is installed on the C: drive, so disk space must be allocated there.

Connector

Digital Lab Connector is a Java application. Hence, it uses a predefined amount of host memory.

The amount of consumed memory is impacted by the number of simulated sessions (user sessions). The minimal requirement is 2 GB.

* We recommend at least 8 GB for standard deployments (8-10 devices per connector), and 16 GB for large deployments (12-25 devices).

The guidelines for Digital Lab Server are the same for the Connector Java application.

Remote access to the device increases the CPU consumption and must be considered. The connector hardware must be planned according to the expected concurrent sessions on mobile devices. It differs slightly between Windows, Linux, and Mac connectors. The rule of thumb is to allocate one-half of the CPU Core for each remote device session

The disk space usage on the Digital Lab Connector depends on various factors, such as the number of logs generated, and the number of application files cached on the connector.

We recommend at least 10 GB.

Network requirements

Digital Lab provides straightforward network requirements. For more details, see Digital Lab Architecture.

Network latency	Digital Lab is designed for resiliency over the network (WAN), by using REST API communication over the HTTP/S protocol. However, there is also a communication channel that leverages the WebSocket protocol. Communication through this protocol may present some limitations that need to be considered. In general, if network latency is less than 100 ms, communication issues are unlikely when Digital Lab and connectors are using the public Internet, MPLS, VPN, or any other method. A latency greater than 200 ms will introduce connectivity challenges. To work on a device in remote view, we recommend a network bandwidth of 1 Mbps or higher.
Digital Lab and SSL	By default, Digital Lab uses an SSL configuration to communicate between a server and connectors. This is achieved by generating a self-signed SSL certificate during the installation. For production usage, we strongly recommend using CA certificates (certificate issued by Certification Authority as opposed to selfsigned), which will remove security warnings in browsers as well as streamline connectivity of testing tools. We also recommend using a CA certificate together with a CA Root certificate, to avoid any recognition issues on the client machine. For more information, see SSL and certificates. Using SSL is also beneficial from a networking perspective, as it eliminates any internal security blockages by IPS or other security gateways.
Digital Lab ports	Digital Lab Server (Web front end) utilizes a single port. The port is configured during the installation of Digital Lab Server. The Digital Lab connector also utilizes a single port for connectivity with the Digital Lab server and the end-user (client). Internally, the Digital Lab connector utilizes a reverse proxy (Nginx) to route the requests to relevant mobile devices. Therefore, from the networking perspective, a single port should be accessible (ingress) for the Digital Lab Server and Connector. Regarding protocols used, there is a requirement for HTTP/HTTPS and WebSocket/WebSocket Secure (WS/WSS) protocols.
Client tools and Digital Lab server connectivity	Common client tools are UFT One, LoadRunner, Sprinter, BPM, UFT Developer, and Appium scripts. Testing-tool clients connect to the Digital Lab server for the following: A user interface (UI) for managing devices and uploading apps over HTTP/HTTPS. API (JSON commands) for tests and management, sent over WebSocket (WS/WSS). The remote screen viewer client sent over WebSocket (WS/WSS)

USB hubs and device power consumption

When a device is used with Digital Lab, there is a need for synchronization and charging. The device is connected via a USB cable, which provides constant charging and communication (Digital Lab Connector to Agent). As the number of USB ports is usually limited, use a USB self-powered hub to support the required scalability. The hub is powered by an external power supply and can therefore provide full power to every port. Charging requirements for mobile devices vary from 500 to 5,000 mA (from Android and iOS phones to tablets and iPads). We strongly recommend that you ensure the power hub can deliver the required power to all USB ports.

Consider, for example, a powered 7-port USB hub of 60 W has specs of 12V and 5A (12x5=60). A smart hub dynamically splits the 5A among 7 ports, giving each port ~714 mA, which is sufficient for small/older mobile phones. However, if an iPad is connected to that hub, it will consume 2100 mA, leaving the remaining 2900 mA to be split among 6 ports (~480 mA each); this might be an issue even for mobile phones since the power allotment is less than the required 500 mA.

The following table lists the most popular devices and their power requirement for sync and charge.

iOS Devices	mA	Android Devices	mA
iPad Pro 12.9 inch (4th generation)	3000	Samsung S9/S9+	2000
iPad Pro 12.9 inch (3rd generation)	3000	Samsung Note8	2100
iPad Pro 11-inch (2nd generation)	3000	LG G4	1800
iPad Pro 11-inch	3000	Google Pixel 2	2000
iPad Retina	2400	Samsung S9/S9+	2000
iPad 2	2100	Samsung Note8	2100
iPad Air and iPad Air 2	2100	LG G4	1800
iPad Mini 2 and 3	2100	Google Pixel 2	2000
iPad Mini	1000	Huawei Mate 9	2000
iPhone 5s	500	Lenovo K8	1000
iPhone 6/7 and iPhone 6/7 Plus	1000	Motorola Nexus 6	2000
iPhone X and iPhone XS	1000	Xiaomi Mi 5	1000
iPhone 8 and iPhone 8 Plus	1000	Samsung S20/S20+	4000
iPhone XS Max	1000	Samsung S21 Ultra	5000
iPhone XR	1000	Samsung S21/S21+	4000/4800
iPhone 11	2000	Google Pixel 4a	3140
iPhone 11 Pro	2000	Google Pixel 5	2800
iPhone 11 Pro Max	2000	Motorola One 5G	5000
iPhone 12	2815	Samsung S22 Ultra	5000
iPhone 12 Pro	2815	Google Pixel 6 Pro	5000
iPhone 12 Pro Max	3687	Samsung Galaxy Z Flip 3	3300
iPhone 13	3227	Oppo Find X5 Pro	5000
iPhone 13 Pro	3095	Samsung S22+	4500
iPhone 13 Pro Max	4352	OnePlus Nord 2	4500
iPad mini 6	8827	OnePlus 10 Pro	5000
		Xiaomi Redmi Note 10 Pro	5020
		Xiaomi Mi 11	4600

We recommend that you plan and calculate power requirements in advance to avoid device disconnections due to power issues. In addition, we recommend that you use powered USB hubs that comply with the BC 1.2 standard. Here are some examples of products recommended:

16-Port USB 2.0 hub 200W multiple USB port hub - USB charging splitter 5V 40A
16-Port USB Charging Station with Syncing, 230V, 5V 40A (200W) USB Charger Output, 2U Rack-Mount
SuperSync15 – Cambrionix Multideck

Device hosting

Mobile devices are constantly connected to a power source. We recommend the following to reduce the amount of heat and impact of this configuration:

• Place the devices in a non-flammable, well-ventilated enclosure

• Provide extra ventilation for the enclosure

A number of solutions are available to help you meet these requirements. For example:

Devices beam for rack-mounted installation
Extra-fan panel for rack-mounted installation
1U 16 ports USB power hub
16-device USB charging station cabinet

For additional best practices related to devices hosting, see Connect devices to Digital Lab.

Device configuration

To help with device configurations, check the following when connecting a device to Digital Lab:

General

No passcode configured on the device
No Google Play Account/Apple Store Account configured on the device
Device connected to the Wi-Fi
Device screen brightness to minimum
Device wallpaper set to monochrome, static

Android devices

Disable Lock device option
Enable Developer option (Go to Settings → About Device →Click 7 times on Build number)
Enable Stay Awake option under developer options
Enable USB Debugging option under Developer options
On Samsung device that run on Android 8.0 and later, make sure to add the
Digital Lab Agent to unmonitored applications under Battery saver menu
Disable auto-update and patches install
To avoid automatic upgrades on Android devices:
In Settings > System > About device > Software update, disable auto update.

iOS (Apple) devices

Copy the UDID of the device (required for re-signing the Agents)
Disable the Lock device option
If the device runs on iOS 12 and above configure the Auto-lock to 30 seconds
Under Settings > Safari >Advanced enable JavaScript and Web Inspector.
Enable UI Automation option (after first connection to Digital Lab the option is diplayed in the Settings)
Disable the iOS auto update (Settings > General > Software Update)

To avoid automatic upgrades on iOS devices:

1. Tap Settings.

2. Tap General.

3. In the section Software update, turn off the Automatic Updates option.

To remove previously downloaded iOS updates:

Open the Settings app.
Tap General.
Tap iPhone/iPad Storage.
Scroll down slightly until you see a list of apps and the amount of storage they use. Look for the iOS update.
Tap the update to see more details, and then select Delete Update.
Tap Delete Update to confirm.

You can also block iOS automatic updates by blocking the following domains on the Wi-Fi router:

appldnld.apple.com
mesu.apple.com

Additional items to consider:

SIM card error message. This system alert message can prevent plug-and-play operation for the device. Solution: Install a fake sim card or use the workaround in Error codes to resolve
Automatic dismissal of system dialogs. For details, see iOS options
Automatic prevention of device lock. For details, see iOS options

Additional admin best practices

For best practices for lab maintenance operations, monitoring, upgrades, and packaging services, see Additional admin best practices.