AppStream Applications Test
AWS AppStream Multi-session Host allows administrators to stream desktop applications to multiple users securely from the cloud and enables administrators to deploy applications in a scalable and cost-effective manner without the need for physical hardware. The multi-session host allows multiple users accessing the same instance of an application concurrently. This feature optimizes resource utilization and potentially reduces costs while offering a scalable and secure solution. To ensure seamless delivery of the applications hosted on the target host, administrators should continuously monitor how well the resources are utilized, the rate at which I/O operations are performed and if the users encountered any delay while accessing the applications. This check can be easily done using the AppStream Applications test.
This test auto-discovers the applications running on the target host and for each application, reveals the utilization of CPU and memory resources. In addition, this test also reports the rate at which the I/O read and write operations are performed while accessing each application. This test also alerts administrators to maximum and average delay (if any) occurred when the users were providing their inputs to each application.
Target of the test : An AWS AppStream Multi-session Host
Agent deploying the test : An internal agent
Outputs of the test : One set of results for each application that is being monitored
Parameters | Description |
---|---|
Test Period |
How often should the test be executed. |
Host |
The host for which the test is to be configured. |
Port |
The port at which the target host listens. |
Report By Domain name |
|
Show Only Active Apps |
Using this flag, you can indicate whether the test should monitor active applications alone or all applications running on the target host. By default, this flag is set to No, indicating that this test will monitor all applications, by default. However, to monitor only the applications that are actively running on the host, you can set this flag to Yes. |
Show Only Desktop Process |
By default, this flag is set to No. If this flag is set to Yes, then the detailed diagnosis of this test will list the resource-intensive processes/applications accessed by a user along with the exact published desktop that has been used by the user to access the application. |
Show Only Whitelist Apps |
In some highly secure virtual environments, administrators whitelist an index of business-critical and most commonly used applications that are permitted to be present and active on the target host. The goal of whitelisting is to protect the target server from potentially harmful applications and prevent any unauthorized files from executing. Application whitelisting places control over which applications are permitted to run on the target server and is controlled by the administrators, rather than the end-user. In such environments, administrators may wish to monitor only the applications that are whitelisted on the target host. To achieve this, administrators can set the Show Only Whitelist Apps flag to Yes. By default, this flag is set to No indicating that this test monitors all applications executing on the target server. By default, eG Enterprise offers a comma separated list of pre-defined applications specified against the WhiteListProcesses option in the [EXCLUDE_APPLICATIONS] section of the eg_tests.ini file available in the <eG_INSTALL_DIR>/manager/config folder. Setting the Show Only Whitelist Apps flag to Yes will enable this test to monitor only the applications that are listed against the WhiteListProcesses option. If administrators wish to add or remove one or more applications to/from this pre-defined list, then, they can do so by specifying the applications against the WhiteListProcesses option. |
Enable Browser Monitoring |
By default, this flag is set to No, indicating that the eG agent does not monitor browser activity on the host. If this flag is set to Yes, then, whenever one/more IE (Internet Explorer) browser instances on the target host are accessed, the detailed diagnosis of the Processes running measure will additionally reveal the URL being accessed via each IE instance and the resources consumed by every URL. Armed with this information, administrators can identify the web sites that are responsible for excessive resource usage by an IE instance. |
Exclude |
By default, this parameter is set to none. This means that the test will monitor all the applications that are launched on the target host, by default. However, ff you want this test to disregard certain applications when monitoring, then provide a comma-separated list of process names that correspond to the applications that you want to ignore, against this parameter. For instance, your specification can be: winword.exe,js.exe,taskmgr.exe. Your specification can include wild card patterns as well. For example: *win*,js*,*task |
DD Frequency |
Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency. |
Detailed Diagnosis |
To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:
|
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Processes running |
Indicates the number of processes of this application currently executing on this instance. |
Number |
This value indicates if too many or too few instances corresponding to an application are executing on the host. Use the detailed diagnosis of this measure to identify all the users executing this application, PID and parent PID of each user, utilization of CPU, memory, working set memory, handles and threads by each users. Comparing the users will help you to identify which user is utilizing the maximum memory, CPU etc. In addition, you can also find out how well the I/O read and write operations were performed when each user accessed the published application, the count of page faults and the delay occurred while accessing the application. |
CPU usage |
Indicates the percentage of CPU used by the published application. |
Percent |
A very high value could indicate that the specified application is consuming excessive CPU resources. Use the detailed diagnosis of this measure to identify all the users executing this application, PID and parent PID of each user, utilization of CPU, memory, working set memory, handles and threads by each users. Comparing the users will help you to identify which user is utilizing the maximum memory, CPU etc. In addition, you can also find out how well the I/O read and write operations were performed when each user accessed the published application, the count of page faults and the delay occurred while accessing the application. |
Memory usage |
This value represents the ratio of the resident set size of the memory utilized by the application to the physical memory of the host system, expressed as a percentage. |
Percent |
A sudden increase in memory utilization for an application may be indicative of memory leaks in the application. Use the detailed diagnosis of this measure to identify all the users executing this application, PID and parent PID of each user, utilization of CPU, memory, working set memory, handles and threads by each users. Comparing the users will help you to identify which user is utilizing the maximum memory, CPU etc. In addition, you can also find out how well the I/O read and write operations were performed when each user accessed the published application, the count of page faults and the delay occurred while accessing the application. |
Handle count |
Indicates the number of handles opened by this application. |
Number |
An increasing trend in this measure is indicative of a memory leak in the application. |
Number of threads |
Indicates the number of threads that are used by the application. |
Number |
|
I/O data rate |
Indicates the rate at which this application is reading and writing bytes in I/O operations. |
KBytes/Sec |
This value counts all I/O activity generated by each instance of the application and includes file, network and device I/Os. |
I/O data operations |
Indicates the rate at which this application is issuing read and write data to file, network and device I/O operations. |
Operations/Sec |
|
I/O read data rate |
Indicates the rate at which this application is reading data from file, network and device I/O operations. |
KBytes/Sec |
|
I/O write data rate |
Indicates the rate at which this application is writing data to file, network and device I/O operations. |
KBytes/Sec |
|
Page fault rate |
Indicates the total rate at which page faults are occurring for the |
Faults/Sec |
This measure is a good indicator of the load on the application. A page fault occurs when a thread refers to a virtual memory page that is not in its working set in main memory. This may not cause the page to be fetched from disk if it is on the standby list and hence already in main memory, or if it is in use by another application with whom the page is shared. |
Working set memory |
Indicates the current size of the working set of this application. |
MB |
The Working Set is the set of memory pages touched recently by the threads in a process/application. If free memory in the server is above a threshold, pages are left in the Working Set of an application even if they are not in use. When free memory falls below a threshold, pages are trimmed from Working Sets. If they are needed they will then be soft-faulted back into the Working Set before leaving main memory. Comparing the working set across applications indicates which application is taking up excessive memory. Use the detailed diagnosis of this measure to identify all the users executing this application, PID and parent PID of each user, utilization of CPU, memory, working set memory, handles and threads by each users. Comparing the users will help you to identify which user is utilizing the maximum memory, CPU etc. In addition, you can also find out how well the I/O read and write operations were performed when each user accessed the published application, the count of page faults and the delay occurred while accessing the application. |
Input delay for processes - max |
Indicates the maximum amount of time lag detected between the user's input through any input device (e.g., mouse, keyboard) and the time at which this application detected the input. |
Seconds |
Poor application performance is one of the most difficult problems to diagnose by the administrators. Traditionally, diagnosis was done by collecting CPU, memory, disk I/O and a few other metrics. The data collected from traditional metrics were not sufficient to figure out the root cause of poor performance of the applications since the variations measured by the metrics were large. In virtual environments where multiple users accessed an application from remote at the same time, users faced difficulties in accessing the application whenever there was an increase in the count of users. The more the users are accessing the application, the higher was the CPU usage of the systems in the environment and the higher was the user input delays i.e., the users were forced to wait for a longer duration to interact with the application. The user input delay is measured by how long any user input (such as mouse or keyboard usage) stays in the queue before it is picked up by a process. These two measures capture such user input delays at the application/process level. These insights enable administrators to accurately identify which application/process is responding slowly to user requests. These measures will be reported only on Windows 2019 (and above). Ideally, the values of these measures should be 0 or very low. |
Input delay for processes - avg |
Indicates the average amount of time lag detected between the user's input through any input device (e.g., mouse, keyboard) and the time at which this application detected the input. |
Seconds |