Transcription
Technical WhitepaperScalability of 64-bit TerminalServer PlatformsAugust 2006Dr. Bernhard TritschWeb:http://drtritsch.comTwitter:@drtritsch
Copyright 2006 Bernhard Tritsch, All rights reserved.The information, concepts, and ideas contained in this document are the property of BernhardTritsch. No part of this document may be duplicated, photocopied, reproduced, translated,transferred to an electronic medium, or put in machine-readable form without the prior writtenpermission of Bernhard Tritsch.The information and data contained in this document are subject to change without notice.All brand names and product names used in this document are trademarks of their respectiveholders and are recognised as such.Tritsch: Scalability of 64-bit Terminal Server Platforms2
1Contents1Contents . 32Introduction . 43Test Setup . 53.1Test Environment . 53.2Testing Tools and Scripts . 73.2.1 Creating User Accounts . 73.2.2 Installing Applications and Providing Documents . 83.2.3 Creating the User Sessions . 93.2.4 User Profiles and Test Sequence . 103.3Testing Methodology . 114Analysis of the Results . 144.1Test Server with 4 GB RAM. 144.2Test Server based on AMD CPUs with 16 GB RAM . 164.3Test Server based on Intel CPUs with 16 GB RAM . 215Conclusions . 236Appendix . 246.1Performance Counters Analysed . 246.1.1 Background Information . 246.2Step-by-Step Description of a Test Run . 256.2.1 Setting up the Controller . 256.2.2 Setting up the Clients (Load Generators) . 256.2.3 Setting up the Server . 256.2.4 Testing . 266.2.5 Cleaning up . 27Tritsch: Scalability of 64-bit Terminal Server Platforms3
2IntroductionMicrosoft Windows Terminal Services allows users to run Windows-based applications on a remoteWindows Server 2003-based platform. The most important benefits of terminal servers are the rapidand centralized deployment of applications and the optimized access to data using low networkbandwidth. This allows users to become more productive by enabling access to current applicationson many different kinds of devices.In a server-based computing environment, all application execution and data processing occurs onthe server. Therefore it is useful and desirable for server manufacturers to test the scalability andcapacity of their servers to determine how many client sessions a server can typically support undera variety of different scenarios.It is widely recognized that an anticipated typical work scenario be simulated in a customized testenvironment prior to production installation. This test focuses on a real-world comparison between32-bit and 64-bit server platforms. Windows Server 2003 x64 Edition with Terminal Services inapplication server mode is able to break memory barriers imposed by the 32-bit edition. This,however, does not automatically imply that under all circumstances the number of terminal serverusers may be scaled up by using 64-bit technology. This whitepaper first describes the testenvironment and the methodology used. Then it provides detailed descriptions of the variousscalability test results. Finally it summarizes the results and compares them to existing terminalserver environments.Please note that the results and analysis contained here should not be interpreted in isolation. Theapplications used in the test executed in terminal server sessions and were only intended toconsume a reproducible amount of server resources. The tests assume a rather static quality, withusers only logging onto the system, starting three applications with corresponding documents, andsubsequently staying inactive for the rest of their session. This helps us to create reproducibleresults, but your results may vary.Tritsch: Scalability of 64-bit Terminal Server Platforms4
3Test SetupThe test environment consisted of hardware and software components. The hardware componentscommunicated through a dedicated Local Area Network (LAN). This configuration avoidsinterference with network traffic not associated with the test environment.3.1Test EnvironmentOne testing laboratory provided a simple setup using two types of servers: 2 Dell PowerEdge 850 Servers; 1 x Intel XEON 3.0 GHz Dual-Core CPU, 2 megabytesecond-level cache, 4 gigabytes of memory 10 Fujitsu Siemens Computers BX600 Blade Servers used as clients creating user load; 2 xIntel 2.8 GHz CPUs, 2 gigabytes of memory 1 IBM T43 Notebook used for test sequence control and monitoringAnother testing environment (Fujitsu Siemens Computers Support Laboratory) provided thefollowing test setup: 1 Fujitsu Siemens Computers Primergy BX630-A Server: 2 x AMD 1.8 GHz Dual-CoreCPUs, 16 gigabytes of memory 1 Fujitsu Siemens Computers RX300S2-A Server: 2 x Intel 2.8 GHz Dual-Core CPUs, 16gigabytes of memory 10 Fujitsu Siemens Computers BX300 Blade Servers used as clients creating user load; 2 xIntel 933 MHz CPUs, 2 gigabytes of memory 1 Fujitsu Siemens Computers E4010D Notebook used for test sequence control andmonitoringOther components of both the testing laboratories included a Gigabit Ethernet infrastructure.Refer to the following tables for a summary of the server system components.Tritsch: Scalability of 64-bit Terminal Server Platforms5
System ComponentHardware TypeQuantity2Operating SystemDescriptionDELL PowerEdge 850 ServerWindows Server 2003, R2Processors1Intel XEON 3.0 GHz Dual-Core, EM64TMemory4gigabytesDisk Subsystems1150 gigabytes, Adaptec DELL Array SCSINIC1Broadcom NetXtreme Gigabit EthernetSystem ComponentHardware TypeQuantity1Operating SystemDescriptionFUJITSU SIEMENS RX300S2-AWindows Server 2003, SP1Processors2Intel 2.8 GHz Dual-Core, EM64TMemory16gigabytesDisk Subsystems270 gigabytes, LSI Logic RAID 1 SCSINIC1Broadcom NetXtreme Gigabit EthernetSystem ComponentHardware TypeQuantity1Operating SystemDescriptionFUJITSU SIEMENS PRIMERGY BX630-AWindows Server 2003, SP1Processors2AMD 2.8 GHz Dual-Core, AMD64Memory16gigabytesDisk Subsystems236 gigabytes, LSI Logic RAID 1 SCSINIC1Broadcom NetXtreme Gigabit FiberFor all server systems used during the tests, the system information was documented by running thesystem tool msinfo32.exe.Tritsch: Scalability of 64-bit Terminal Server Platforms6
Figure 3.1: System Information of one of the servers used for the tests3.2Testing Tools and ScriptsTo assist with testing, we developed specific testing scripts and tools used on the different client andserver computers.3.2.1Creating User AccountsBefore the start of the tests, 250 local user accounts had to be created on each server platform.These test user accounts were added to the local Users group and Remote Desktop Users group.This was accomplished through a Visual Basic script.Tritsch: Scalability of 64-bit Terminal Server Platforms7
nMaxUsers 401strPassword "BigIron2006 !"Set objComputer CreateObject("Shell.LocalMachine")strComputer objComputer.MachineNameWscript.Echo "Computer name: " & strComputerWscript.Echo "Multiple users enabled: " & objComputer.IsMultipleUsersEnabledWscript.Echo "Remote connections enabled: " & objComputer.IsRemoteConnectionsEnablednCounter 1Do While nCounter nMaxUsersstrUser "v" & nCounterSet colAccounts GetObject("WinNT://" & strComputer & "")Set objUser colAccounts.Create("user", strUser)objUser.SetPassword strPasswordobjUser.SetInfowscript.Echo "User account " strUser " created"Set objNewUser GetObject("WinNT://" & strComputer & "/" & strUser & ",user")Set objGroup GetObject("WinNT://" & strComputer & "/Remote Desktop pt.Echo "Added User account " strUser " to Remote Desktop Users group"Set objGroup GetObject("WinNT://" & strComputer & ript.Echo "Added User account " strUser " to Users group"nCounter nCounter 1LoopListing 3.1: Script nuser.vbs, which creates 400 user accounts by using Windows Script Host. Thescript has to be executed in the context of a user session with administrator privileges.3.2.2Installing Applications and Providing DocumentsThe tests performed for this white paper are based on launching a sequence of applications andopening documents.The following applications were installed on the Terminal Servers. Microsoft Office 2003 Adobe Acrobat Reader 7NOTE: See “Setting up the Server” for more details on tuning the applicationsDuring the test three applications were launched using the following documents. Notepad.exe – ComputerWorld.txt: ANSI text file, 8.4 kilobytes Acrobat Reader – vCC Admin EN.pdf: Adobe Acrobat PDF document, 3.8 megabytes Microsoft Word – vPMS Inst EN.doc: Microsoft Word document, 3.1 megabytesDuring the tests, the applications showed specific memory footprints, all related to the documentsloaded. Winword.exe used between 13 and 18 megabytes, Notepad.exe used approx. 3 megabytes,and Acrobat Reader used almost 30 megabytes per session.Tritsch: Scalability of 64-bit Terminal Server Platforms8
3.2.3Creating the User SessionsDuring the test sequence, the user sessions are initiated from the load generators by visionappRemote Desktop Load Edition. An XML file on each client defines the IP address of the target serverand the user credentials (username and password).NOTE: It is no problem to open up to 40 user sessions from each of the load generators.The standard settings for this test sequence were the following: Number of load generators used for each test sequence: 10 Number of users per load generator: 20 to 40 Interval between user logons: 60 seconds (60,000 msec)Figure 3.2: One instance of vRD Load Edition with 20 users configured and displayed within vRDright after the start of a test sequence. At this time, no test user is logged in yet.Tritsch: Scalability of 64-bit Terminal Server Platforms9
?xml version "1.0" encoding "utf-16"? vRDLoadConfigurationFile Testcase ServerName "10.4.1.93" Domain VAFE0SD3 /Domain User v1 /User Password BigIron2006 ! /Password /Testcase Testcase ServerName "10.4.1.93" Domain VAFE0SD3 /Domain User v2 /User Password BigIron2006 ! /Password /Testcase /vRDLoadConfigurationFile Listing 3.2: XML sample file used to configure vRD Load Edition3.2.4User Profiles and Test SequenceIt is not possible to open the same physical document file from multiple user sessions.Consequently, it was necessary to provide individual document files for all users. For this purpose,individual user profiles were used, which allowed the required documents to be copied to eachuser's desktop and to launch its associated application.In order to create the user profiles automatically without using a domain controller, we added asimple script to the Startup folder of All Users. Its purpose was to copy all required document filesfrom a common source to each user’s desktop of as soon as the user logged in. After a delay of 10seconds, the ASCII document was loaded with Notepad.exe. After another 20 seconds, the PDFdocument was loaded with Adobe Acrobat Reader. Finally, after 20 seconds more, the Worddocument was loaded by Microsoft Word.NOTE: The average size of each user profile generated during the test was 7.3 MB.NOTE: The delays between the different actions in the script were controlled by calling thecommand-line tool Sleep.exe from the Microsoft Windows Server 2003 Resource Kit.We had to make sure that the paths for launching the 32-bit applications Adobe Acrobat Reader andMicrosoft Word were set properly. While the path on the 32-bit platform was “C:\Program Files\”, thepath on the 64-bit platform was “C:\Program Files (x86)\”. On the 64-bit platform, the login scriptlooked as follows:@echo offif not exist "%userprofile%\Desktop\ComputerWorld.txt" copy op"if not exist "%userprofile%\Desktop\vCC Admin EN.pdf" copy c:\Documents\vCC Admin EN.pdf"%userprofile%\Desktop"if not exist "%userprofile%\Desktop\vPMS Inst EN.doc" copy c:\Documents\vPMS Inst EN.doc"%userprofile%\Desktop"echo Document files copiedsleep 20start /B notepad.exe "%userprofile%\Desktop\ComputerWorld.txt"echo Tried to launch Notepad with ComputerWorld.txt (8.4 KB)sleep 20start /B "C:\Program Files (x86)\Adobe\Acrobat 7.0\Reader\AcroRd32.exe""%userprofile%\Desktop\vCC Admin EN.pdf"echo Tried to launch Acrobat Reader with vCC Admin EN.pdf (3.8 MB)sleep 20start /B "C:\Program Files (x86)\Microsoft PMS Inst EN.doc"Tritsch: Scalability of 64-bit Terminal Server Platforms10
echo Tried to launch Microsoft Word with vPMS Inst EN.doc (3.1 MB)pauseListing 3.3: The script BigIron.cmd in the Startup folder of All Users3.3Testing MethodologyThe goal of this test was to identify the maximum number of users a memory-constrained terminalserver could manage before system responsiveness degraded beyond an acceptable limit ofapproximately 15 seconds to open a window.For each test scenario, the test engineer used vRD Load Edition to start the test sequence on eachof the load generators using visionapp Remote Desktop from the controller PC. vRD Load Editionwas configured to automatically log in one user after the other with an interval of 60 secondsbetween logins. A simple script in the Startup folder of All Users controlled a predefined sequence ofstarting 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: AdobeAcrobat PDF document, 3.8 megabytes 50 seconds after successful user login: Microsoft Word – vPMS Inst EN.doc: MicrosoftWord document, 3.1 megabytesBy concurrently using 10 load generators and starting the test sequences on the individual loadgenerators with only a couple of seconds delay, 10 user log on to the system within approx. 20seconds. 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.Tritsch: Scalability of 64-bit Terminal Server Platforms11
Figure 3.3: A typical situation after a test user logged in and opened three documents usingNotepad, Adobe Acrobat Reader and Microsoft Word.Each user session showed a memory footprint of approx. 60 megabytes when all applications werelaunched.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 TimeTritsch: Scalability of 64-bit Terminal Server Platforms12
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 SessionsNOTE: Collecting data – the test engineers used Windows Performance Monitor on the server togather system information.NOTE: To insure a common starting state, all test user profiles were deleted and all systems wererebooted prior to running any test iteration.Tritsch: Scalability of 64-bit Terminal Server Platforms13
4Analysis of the Results4.1Test Server with 4 GB RAMTritsch: Scalability of 64-bit Terminal Server 55:414,0003,50012:59:44Memory\Available MBytes4,0003:54:1113:33:05Memory\Available 57:112003:55:412503:54:1125013:10:44Terminal Services\Active Sessions13:08:54Terminal Services\Active Sessions13:07:042 Intel CPU Cores, 4 GB RAM13:05:142 Intel CPU Cores, 4 GB RAM13:03:2432-bit – Windows Server 200313:01:3464-bit – Windows Server 2003 x6413:32:45One test was done comparing 64-bit and 32-bit versions of Windows Server 2003 R2 running on aDELL PowerEdge 850 Server with one Intel XEON 3.0 GHz Dual-Core processor and four gigabyteof RAM. Every minute, 10 new users were logged in to each test system until its resources areexhausted.14
Tritsch: Scalability of 64-bit Terminal Server 21:2530,00013:19:44Memory\Page :24System\Processor Queue :07:0413:05:1413:03:24Processor\% Processor 413:57:113:55:418,000,000,0006,000
Microsoft Windows Terminal Services allows users to run Windows-based applications on a remote Windows Server 2003-based platform. The most important benefits of terminal servers are the rapid and centralized deployment of applications and
