We used the Login VSI test suite to simulate the user experience for several profile types under the typical workload for that type. The following table summarizes the test results that we obtained for the compute hosts using the various workloads and configurations:
User density per host—The number of users per compute host that successfully completed the workload test within the acceptable resource limits for the host. For clusters, this number reflects the average of the density that is achieved for all compute hosts in the cluster.
Average CPU usage—The average CPU usage over the steady-state period. For clusters, this number represents the combined average CPU usage of all compute hosts.
Average active memory—For ESXi hosts, the amount of memory that is actively used, as estimated by the VMkernel based on recently touched memory pages. For clusters, this is the average amount of guest physical memory that is actively used across all compute hosts over the steady-state period.
Average IOPS per user—IOPS calculated from the average disk IOPS over the steady state period divided by the number of users.
1 VMware recommends a maximum configuration of 200 VMs per node. This result represents a 49 percent increase in performance over the previous testing performed on AMD EPYC 7502 processors.
We populated each compute host with 309 virtual machines for a total of 927. With all user virtual machines powered on before the start of the test, the CPU usage was approximately 8 percent.
The following figure shows the performance data for 309 user sessions per host. The CPU reached a steady-state average of 85 percent during the test cycle when all users were logged in.
Figure 11. CPU usage percentage
Note: When viewing the CPU Usage metric within VMware vSphere, we observed a number of CPU spikes during testing. We have investigated whether this was impactful to the workload and determined that it was not. This appears to be a measurement and reporting issue, and not one of performance. If additional insight is received from AMD or VMware this document will be updated.
CPU core utilization had a steady-state average of 70.8 percent and peaked at 76 percent, indicating that there was still headroom for extra CPU cycles per core.
Figure 12. CPU core utilization percentage
The CPU readiness percentage was low throughout testing, indicating that the VMs had no significant delays in scheduling CPU time. The readiness steady-state average was 2.77 percent while the peak was 3.38 percent and remained below the threshold of 5 percent.
Figure 13. CPU readiness percentage
Memory usage
In regard to memory consumption for the cluster, out of a total of 2,048 GB of available memory per node, memory usage was not an issue. The compute hosts reached a maximum memory consumption of 1,171 GB with active memory usage reaching a max of 544 GB. There was no ballooning or swapping at any point during the test.
Figure 14. Consumed memory (GB) Figure 15. Active memory (GB)
Network usage
Network bandwidth was not an issue on this test, which ran with a steady-state peak of approximately 3,012 Mbps. The busiest period for network traffic was just after all user logins had completed. The host reached a peak of 2,331 Mbps during the deletion and re-creation of the instant clones. The steady-state average was 1,814 Mbps.
Figure 16. Network usage (Mbps)
IOPS
The following figure displays the disk IOPS figure for the vSAN datastore. The graph clearly displays the initial logging in of the desktops, the steady-state and logging out phases, and finally the re-creation of the desktops after testing was complete.
The cluster reached a maximum total of 15,477 disk IOPS (read + write) during the instant clone re-creation period after testing and a steady-state average of 3,273 disk IOPS (read + write). The steady-state peak was 7,141 disk IOPS (read + write).
Figure 17. Cluster disk IOPS
Disk I/O latency
Disk I/O latency was not an issue during the Login VSI testing period of this test run. The maximum latency reached on the vSAN datastore was approximately 1.34 ms (read + write) during steady state. This was well below the 20 ms threshold that is regarded as potentially troublesome. The average latency during steady state was 1.54 ms (read + write).
Figure 18. Cluster latency (ms)
User experience
The Login VSImax user experience score shown in the following figure for this test was not reached, indicating that there was no deterioration in user experience based on the number of users we tested.
The following figure shows the user experience summary for this test:
Figure 19. User experience summary
The following table defines the Login VSI user experience metrics:
Table 10. Description of Login VSI metrics
Login VSI metrics
Description
VSImax
VSImax shows the number of sessions that can be active on a system before the system is saturated. It is the point where the VSImax V4 average graph line meets the VSImax V4 threshold graph line. The intersection is indicated by a red X in the Login VSI graph. This number gives you an indication of the scalability of the environment (higher is better).
VSIbase
VSIbase is the best performance of the system during a test (the lowest response times). This number is used to determine what the performance threshold will be. VSIbase gives an indication of the base performance of the environment (lower is better).
VSImax v4 average
VSImax v4 average is calculated on the number of active users that are logged into the system, but removes the two highest and two lowest samples to provide a more accurate measurement.
VSImax v4 threshold
VSImax v4 threshold indicates at which point the environment's saturation point is reached (based on VSIbase).
Analysis
2,048 GB of memory installed on each node is more than sufficient for the number of desktops tested.
The feature of instant clones where the virtual machines are deleted and re-created after the users log out led to the highest workload on each host, higher than at any point during the actual test period itself. The CPU reached the same maximum levels at it did during testing, and memory, network, and datastore metrics all surpassed the levels seen during the actual test period.
We used the VMware Horizon Blast Extreme remote display protocol with the dynamic encoder enabled during testing.
The data collection interval was 1 minute for any non vSAN datastore metrics. All vSAN metrics data collection intervals were 5 minutes.
