Scalability of 64-bit Terminal Server Platforms

Posted by Benny Tritsch on April 24, 2007 – updated on July 17, 2007

[Introduction] [Test Environment] [Tools and Scripts] [Methodology] [Results] [Conclusions]
[Appendix 1: Performance Counters Used] [Appendix 2: Step-by-Step Description]

Methodology

The goal of this test was to identify the maximum number of users a memory-constrained terminal server could manage before system responsiveness degraded beyond an acceptable limit of approximately 15 seconds to open a window.

For each test scenario, the test engineer used vRD Load Edition to start the test sequence on each of the load generators using visionapp Remote Desktop from the controller PC. vRD Load Edition was configured to automatically log in one user after the other with an interval of 60 seconds between logins. A simple script in the Startup folder of All Users controlled a predefined sequence of starting applications.

• 10 seconds after successful user login: Notepad.exe – ComputerWorld.txt: ANSI text file, 8.4 kilobytes
• 30 seconds after successful user login: Acrobat Reader – vCC_Admin_EN.pdf: Adobe Acrobat PDF document, 3.8 megabytes
• 50 seconds after successful user login: Microsoft Word – vPMS_Inst_EN.doc: Microsoft Word document, 3.1 megabytes

By concurrently using 10 load generators and starting the test sequences on the individual load generators with only a couple of seconds delay, 10 user log on to the system within approx. 20 seconds. After one minute another 10 users log on to the system until the test sequence is finished – after 20 or 40 test users per load generator.

Figure: A typical situation after a test user logged in and opened three documents using Notepad, Adobe Acrobat Reader and Microsoft Word.

Each user session showed a memory footprint of approx. 60 megabytes when all applications were launched. During all the following performance counters were monitored and stored into a log file:

• Memory: Available MBytes
• Memory: Free System Page Table Entries
• Memory: Page Faults/sec
• Memory: Pages/sec
• Memory: Pool Nonpaged Bytes
• Memory: Pool Paged Bytes
• Physical Disk: Avg. Disk Queue Length
• Process: Working Set
• Processor: % Interrupt Time
• Processor: % Processor Time
• Processor: Interrupts/sec
• Server: Pool Nonpaged Bytes
• Server: Pool Paged Bytes
• System: Context Switches/sec
• System: Processes
• System: Processor Queue Length
• Terminal Services: Active Sessions

NOTE: Collecting data – the test engineers used Windows Performance Monitor on the server to gather system information.

NOTE: To insure a common starting state, all test user profiles were deleted and all systems were rebooted prior to running any test iteration.

Next