Symptoms
This is a generic article to help understand and troubleshoot performance and connectivity issues.
Read this article if you experience one of the following symptoms:
- The Workspace is slow or unresponsive.
- Connections are dropped.
- Users sometimes see a "Lost connection" message.
- Application sessions suddenly disappear.
Cause
Determination will be needed to find the cause, as many factors could lead to this behavior.
Initial determination: Who is impacted and what is the behavior?
Try to pinpoint the main cause first by answering these questions:
- Are users complaining about a "Lost connection" message (or a translated version), and/or are application sessions on the right side of the Workspace suddenly disappearing?
If no, get a clear indication of the issue.
If yes, this indicates WebSocket issues.
Under the hood, the Workspace makes use of WebSockets: An API WebSocket which is active as soon as the end user signs in to the Workspace; and an RDP WebSocket if the user has an application session open on the right side of the Workspace.
Known causes:- WebSocket timeouts.
If all external users are affected, it's likely a timeout configuration on your end. Check the firewall - and if applicable load balancer, and/or reverse proxy - in front of the Workspace.
If however only users connecting from a certain physical location are affected: Do the same exercise on their end.
Make sure there is no short timeout set for WebSockets.
See below for some product-specific recommendations.
- Inactivity.
The user is not actively working in the Workspace. Instead, the user is using other applications or browser tabs.
In this case, the browser (or a browser extension) may decide to put the tab to sleep.
The terminology of this functionality may differ. This is referred to as sleeping tabs, hibernating tabs, pausing tabs.
Microsoft Edge: Look for "Never put these sites to sleep": Learn about performance features in Microsoft Edge - Microsoft Support .
Google Chrome: Look for "Always keep these sites active": Personalize Chrome performance - Google Chrome Help .
- Network interruption.
A common example is the end user's device being put to sleep/hibernation, and now being booted again.
- WebSocket timeouts.
- Are all the users affected in the same way, or are only a subset of users affected?
If only a subset is affected: Do they have anything in common?- Are they using the same browser?
- Are they using the same application in the Workspace.
- Is it a graphics-intensive application?
- Watching videos (for example: watching YouTube videos, surveillance videos, ... )
- Using a mapping application (ArcGIS, QGIS, Google Maps, OpenStreetMap, ... )
- Using a graphics application (Adobe Creative Suite, some 3D tool, ...)
- Scrolling through image libraries
- ...
- If they only use another application (such as Microsoft Excel or Word): Are they facing the same symptoms?
- Is it a graphics-intensive application?
- Are they using the same antivirus solution on their end-user device.
- Are they coming from the same IP / working from the same physical location (for example: an office).
- ...
- Does it affect users who are connected strictly through the internal network only?
When accessing the appliance as directly as possible from within the internal network: Are the users facing the same symptoms?
If internal users are NOT affected: Consider anything between
- Is there a firewall in place?
If so, try to disable any form of deep packet inspection of traffic to/from the Workspace.
- Is there a firewall, load balancer or reverse proxy in place?
If so, make sure there is no timeout on WebSockets.
- Is there a firewall in place?
This way, any internal network components/configurations could already be ruled out or turn out to be causing the issues.
Which factors are relevant?
Below is a checklist of important factors.
Based on the answers you obtained from the question list above, you should be able to rule out a lot.
Organizational factors (these would impact all users):
-
Firewall and load balancer:
-
Exclude traffic from/to Parallels Secure Workspace so there is no deep inspection (e.g. packet inspection. The terminology may be different.).
-
If the behavior is that users see "Lost connection" frequently or if their application session disappears frequently: This is often caused by a firewall or load balancer terminating connections after a certain timeout (proxy timeout, timeout tunnel, ...). The example in our admin manual keeps WebSockets open for 12 hours, unless properly closed by the user.
Some product-specific info:
In general, you'd be looking for a timeout setting.-
Nginx: proxy_read_timeout.
-
Microsoft Azure Application Gateway: Verify the "Request Time-out (seconds)" back-end setting. Keep in mind that this is also applied to WebSockets. This should be at least 60 seconds. For certain use cases, you want to increase this to 3600 seconds.
-
HA Proxy on pfSense: Verify the timeout tunnel setting.
-
-
-
Internet connection: Download/upload speed and latency.
-
RDS infrastructure: Does the infrastructure have enough CPU, RAM, disk I/O, bandwidth, ...
End-user factors (these would impact a specific user or a small subset of users):
-
Browser: Use the latest version of one of the officially supported browsers.
In case of WebSocket issues, you'd also want to disable "sleeping tabs":-
Google Chrome: Look for "Always keep these sites active": Personalize Chrome performance - Google Chrome Help .
-
Microsoft Edge: Look for "Never put these sites to sleep": Learn about performance features in Microsoft Edge - Microsoft Support .
-
-
Internet connection: Download speed and latency are key factors. Collect info using for example this SpeedTest .
-
VPN: When using a VPN, this may impact the performance of Parallels Secure Workspace. Depending on the network typology, this could have a negative (or in rare cases positive) impact.
-
Software: An antivirus solution might be installed on the end-user's device and act as a firewall, which may also be doing too much packet inspection. Whitelist traffic from/to Parallels Secure Workspace.
-
The application usage in the Workspace:
If the application has a lot of screen updates, it means a lot of data is sent and converted. Note that the RDP protocol was never designed with video as a use case.
Initially, the data is sent between the session hosts and the Workspace environment (RDP connection).
Then, the Workspace streams it over the RDP WebSocket to the end user / browser.
The quantity of data which needs to be processed and transferred, matters a lot.
Imagine drawing a network diagram, where you map the end user's device, the Workspace virtual machines; and anything in between (firewalls, switches, network cables, ...).
Every component influences the performance, both on a hardware and software level. The performance of your entire setup will determine how well this still works; as the weakest link will impact everything.
-
...
Was this article helpful?
Tell us how we can improve it.