Your deployment can be performing slowly for a number of reasons. Even though the VM instances are hosted on Google Cloud, they are still subject to many of the same limitations that a normal PC would. For example, if your PC is using 100% of its CPU for an extended period of time, then it will slow down, if not come to a complete halt or crash. The same goes for the VM Instances in your deployment. When your deployment is slow, you can start by checking the below items.

The File Server (that corresponds to the region the user is logged into). Specifically, you want to check for:

● Heavy CPU consumption

● Heavy Memory consumption

● Low Storage

(If you have a Multi-Region deployment, you must check the File Server that corresponds to the region that the user is logging into. We provide more information about this in the Checking Users Physical Location... section towards the end of this article)

The User Session Server that the user is logged into. Specifically you want to check for:

● Heavy CPU consumption

● Heavy Memory consumption

● Low Storage

The end-users physical location relative to where the servers are located.

Please proceed to the next sections to learn how to check for the above items.

Checking Which Server The User Is Logged Into

In this article, we’ll be focusing on the t1@redchair.rchr user, as per the screenshot below.

In the above screenshot, we see that this user belongs to the Web Browsers collection. So we know that t1@redchair.rchr will be logging into a User Session Server that belongs to the Web Browsers collection.

To find out which specific server t1@redchair.rchr is logged into, navigate to the Insights module.

At the bottom of the Insights module, you can see which users are logged in, and which server they are logged into. You also have the ability to search for a specific user, if the list is too long/

Based on the screenshot above, we know that the t1@redchair.rchr user is logged into rchruss003. Now, we’re going to login to rchruss003 and begin troubleshooting.

Checking CPU, Memory, and Server Uptime

When you login to the server, the first thing you want to do is open Task Manager

  1. To Open Task Manager, right-click a blank space on the Windows Taskbar, and click on Task Manager

2. In the Task Manager window, click More Details

3. Click on the Performance tab

4. Here is where you will see your CPU usage, Memory usage, and Server Uptime

If the CPU/Memory is running excessively high, you can go to the User tab for a detailed breakdown of how much CPU/Memory a user is consuming, and which program(s) are doing so

In the screenshot above, you can see that the t1@redchair.rchr user is consuming 46.4% of the server's CPU. The user has a total of 7 Instances of Google Chrome open, and 2 of those instances account for the full 46.4% of CPU consumption. This type of analysis should be performed for each user. Sometimes, a user may have 15 instances of Google Chrome open, when only 3 are necessary. The end-users will have to be educated in regard to limiting the amount of applications they have open at the same time, as it can consume a lot of resources on the server, thereby slowing it down considerably.

In the event that the CPU/Memory is running excessively high, but all of your users are running programs normally, then the next step would be to reboot the User Session Server. This can be done by logging into and navigating to Cloud Manager → VM Instances → Select your desired VM Instance/Server → Click Restart

If rebooting the server doesn't resolve the issue and free up CPU/Memory, then you will have to increase the CPU/Memory. Alternatively, if it is a specific application that is consuming an excessive amount of resources, you can try reaching out to the developer to find out the best way to limit resource consumption. It is very possible that the developers of the application have a workaround for issues like this.

Ideally, servers should be rebooted every few days, but if your server has been running for 7 or more days consecutively, it should be rebooted.

Next, you should check the Storage of your server. . You can check the storage by clicking on File Explorer --> This PC

While in This PC, if you look under Devices and drives, you will see each of the drives for that server as well as the amount of storage they have left. Ideally, there should be at least 10GB of storage left. There should be more than that if you end users download larger files. As the amount of free storage becomes extremely low, the server performance will become sluggish, and potentially crash.

Now, you’re going to perform the exact same steps in this section, but on the File Server.

Checking Users Physical Location Relative To Server Location

Lastly, the users physical location in relation to the region that the server is deployed must be examined.

To check where your servers are deployed, navigate to and expand Cloud Manager --> VM Instances. Examine the Region (Zone) section

In the screenshot above, all the servers are deployed in the South Carolina region. In order to have the best connection, the end-user must be physically near South Carolina. A few states over is fine. The issue comes when a end-user is thousands of miles away from the region where the server is deployed. An example of this would be an end-user trying to login to a server that is deployed in the South Carolina region, but they are physically located in Los Angeles, or Finland. The latency between the end-user and the servers will be too high, which results in an extremely

sluggish experience.

To resolve this, if the deployment is multi-region (Click here for more information on Multi-region deployments), then the end-user can download a new RDP file from, which will automatically be preconfigured with the region that is physically closest to them, utilizing our Nearest Connection Point Feature.

If the deployment is not multi-region, then the user will either have to physically be closer to the region where the server is deployed, or they will have to experience sluggish performance due to the high latency that comes as a result of being too far.

Did this answer your question?