Database Search

match allmatch any Look in all areasLook in current areas Check all datesPrevious dayPrevious 3 daysPrevious weekPrevious fortnightPrevious monthPrevious 2 monthsPrevious 3 monthsPrevious half-yearPrevious year

TechHome

Terminal Server

• How to Size a Winframe Server
• Setup of WinBatch EXEs on Servers
• Winbatch and SSL Servers
• Winbatch with Systems Management Server

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Using WinBatch to Perform System Sizing on a Winframe Server

Keywords:    citrix winframe

---

Synopsis:

NOTE: This white paper was provided by Wilson WindowWare, Inc. This paper is provided for informational purposes only and the information is subject to change without notice.

Details:

Overview

NOTE: Graphics are not included in this file. To view the graphics, please see the white paper in its entirety on the Citrix Web site at www.citrix.com.

Appropriately sizing a WinFrame server to meet current and future usage requirements can be a challenging exercise. Acquiring a server that is too big for the job is a waste of capital, while a server that is too small or does not provide the expandability needed for the planned growth of the company is false economy.

Many Citrix customers want to know how many simultaneous user connections to WinFrame they will be able to support on a certain server platform. This is a legitimate question; however an immediate, accurate answer is almost impossible to give.

There are many variables to consider when sizing a WinFrame server. Will 32-bit applications be used or will there also be 16-bit Windows or DOS applications? Are the applications processor- and/or memory-intensive or are they mainly "light" applications? Will the WinFrame server be a primary domain controller (PDC) or a backup domain controller (BDC)? If so, how large is the domain? Will the WinFrame server be used for other functions (for example, file server, print server, fax server, Web server, firewall, SQL server, etc.)? Will there be power users executing two or more applications simultaneously or only typical users executing one application at a time?

This document describes how to use Wilson WindowWare, Inc.'s WinBatch application to perform a system sizing analysis of a WinFrame server platform.

Requirements

Hardware Requirements

1. Intel Pentium or Pentium Pro server with appropriate processors and memory to accommodate a specific targeted number of concurrent users

2. Personal computer with 32MB of RAM (minimum) capable of running the 32-bit WinFrame client

Software Requirements

1. Citrix WinFrame Version 1.6 or higher with Service Pack 5 or higher

2. Citrix ICA Win32 Client

3. Wilson WindowWare, Inc.'s WinBatch Version 97D or higher

WinBatch Installation

WinBatch comes on a CD. To install WinBatch on the WinFrame server's console, insert the CD and run SETUP.EXE. Follow the installation process for WinBatch. It may take several minutes to install WinBatch on WinFrame.

System Configuration

Overview

1. Performing system configuration using WinBatch is a three step process:

2. Develop a WinBatch macro (msword.wbm)

3. Develop a WinBatch script (msword.wbt)

4. Use the WinBatch script and Performance Monitor to perform system sizing.

A Windows 95 or Windows NT PC with 32 to 64MB of RAM is used as the WinFrame client. Install the WinFrame client on the PC and create multiple entries to connect to the WINFRAME server. To accommodate 50 concurrent user connections to the WinFrame server, configure 50 unique connections on the WinFrame client as shown below.

Make five connections, one at a time, from the WinFrame client to the WinFrame server. This starts a WinBatch script for each connection and the WINFRAME sessions are minimized to the client's task bar. This scenario simulates five users actively using WinFrame.

When five individual sessions are actively running the WinBatch script, start Performance Monitor on the WinFrame console. This creates a log file that captures processor and memory statistics. Add these statistics to the table and then continue with the next set of five connections. The log file now contains statistics for ten user connections.

Without using a scripting utility such as WinBatch, you would need dozens of actual users to simulate load on the WinFrame server. Using WinBatch, you can simulate as many user connections as you want on an ad hoc basis, without seeking help from human resources.

The result of this exercise is a table that depicts actual processor and memory utilization statistics given varying user loads in five-user increments. When average processor and/or memory utilization rises near 90%, the WinFrame server is reaching its peak in maximum user connections.

Developing the WinBatch Macro

Recording a macro is very similar to recording a television show on a VCR. On a VCR, you press Record to begin recording, Stop to stop recording, and Play to play back the show that you recorded. Note that this example uses the older version of the WinMacro macro recorder utility.

In WinBatch, you click Begin Macro Record to record a series of keystrokes. Then you click End Macro Record to end the macro recording. By adding the recorded macro into a WinBatch script, you can play back the recorded keystrokes to simulate the actual usage of an application. For example, you can record a macro using Microsoft Word. In this case, the macro might be named MSWORD.WBM. The .WBM extension signifies a WinBatch macro. Executing the macro (by incorporating the macro into a WinBatch script) simulates a user working in Microsoft Word.

IMPORTANT: It is important to note that WinBatch can only effectively capture keystroke commands. Mouse movements are not captured in the WinBatch macro.

Follow the steps below for creating a WinBatch macro. This process can be difficult to perform, so please follow these steps very carefully. All steps are performed at the WinFrame console.

To create a WinBatch macro:

1. Launch the application you would like to automate (for example, Microsoft Word). The application should not be fully maximized. Make sure that the bottom inch of the Program Manager screen can be seen.

2. Launch the WinBatch Macro Processor utility. It appears minimized in the bottom left-hand corner of the screen.

3. Press ALT+TAB so that the desired application is in the foreground but the minimized Macro Recorder utility can still be seen at the bottom of the screen.

4. Click once on Macro Processor at the bottom of the screen.

5. Click Begin Macro Record. Enter a unique name for the macro (for example, MSWORD.WBM) in the text box and click OK.

   NOTE: The macro can only be saved in the \Winbatch\WinMacro directory. You can move it to another directory later if desired.

6. Click once on the title bar of the application so that the application is highlighted. Begin using the application using keystrokes only. Do not use the mouse under any circumstances when using the application because mouse movements or clicks will not be recorded. Instead, press the ALT key to highlight a menu item; use the arrow keys to move up, down, left, and right through the menus, and press ENTER when you want to make a selection.

7. When you are finished using the application, close the application using only keystrokes.

8. Click once on Macro Processor and then click End Macro Record.

9. Execute File Manager. Highlight the \Winbatch\WinMacro utility. Click once on the macro just created (MSWORD.WBM). Copy the macro to a new file name (script). For example, if your macro is called MSWORD.WBM, copy the file to a new file called MSWORD.WBT.

Developing the WinBatch Script

Follow the steps below to edit a WinBatch script. This process can be difficult to perform, so please follow these steps very carefully. All steps are performed at the WinFrame console.

1. Execute Notepad. Open the WinBatch script you created above (MSWORD.WBT). Depending on what functions you performed within the macro, the format of the script will be similar to the following:

   ; Recorded Macro N:\APPS\WINBATCH\WINMACRO\MSWORD.WBM
   
   SendKey(`{ALT}fon:\apps\winbatch\winmacro\document.txt{ENTER}{DOWN}{DOWN}`)
   SendKey(`{DOWN}{DOWN}{DOWN}{ENTER}**********{ENTER}{ENTER}Now{SPACE}I{SPACE}`)
   SendKey(`am{SPACE}continuing{SPACE}to{SPACE}type{SPACE}in{SPACE}{ENTER}`)
   SendKey(`this{SPACE}document.{SPACE}{SPACE}I{SPACE}will{SPACE}now{SPACE}`)
   SendKey(`sav{BACKSPACE}{BACKSPACE}{BACKSPACE}close{SPACE}the{SPACE}{ENTER}`)
   SendKey(`document{SPACE}without{SPACE}saving{SPACE}mu{SPACE}{BACKSPACE}`)
   SendKey(`{BACKSPACE}y{SPACE}changes.{ENTER}{ENTER}Here{SPACE}goes.....`)
   SendKey(`..{ALT}fxn{ALT}frn:\apps\winbatch\winmacro\msword.wbt{ENTER}`)
   
   ; End Recorded Macro
   

2. When you launch the WinBatch script, you must make sure that the desired application is executing before the script can be used. Therefore, you need to add a "run" statement at the top of the script file. See the example below:

   Run ("c:\apps\office\winword.exe","")
   
   ; Recorded Macro N:\APPS\WINBATCH\WINMACRO\MSWORD.WBM
   
   SendKey(`{ALT}fon:\apps\winbatch\winmacro\document.txt{ENTER}{DOWN}{DOWN}`)
   SendKey(`{DOWN}{DOWN}{DOWN}{ENTER}**********{ENTER}{ENTER}Now{SPACE}I{SPACE}`)
   SendKey(`am{SPACE}continuing{SPACE}to{SPACE}type{SPACE}in{SPACE}{ENTER}`)
   SendKey(`this{SPACE}document.{SPACE}{SPACE}I{SPACE}will{SPACE}now{SPACE}`)
   SendKey(`sav{BACKSPACE}{BACKSPACE}{BACKSPACE}close{SPACE}the{SPACE}{ENTER}`)
   SendKey(`document{SPACE}without{SPACE}saving{SPACE}mu{SPACE}{BACKSPACE}`)
   SendKey(`{BACKSPACE}y{SPACE}changes.{ENTER}{ENTER}Here{SPACE}goes.....`)
   SendKey(`..{ALT}fxn{ALT}frn:\apps\winbatch\winmacro\msword.wbt{ENTER}`)
   
   ; End Recorded Macro
   

3. Users do not continually use applications at super-human speed. Therefore, it is important to insert time delays (in seconds) within the WinBatch script to emulate user time delays. You may want to insert substantial time delays to account for users talking on the phone, taking a break, or speaking with a co-worker. You may want to consult with actual users to get recommendations for appropriate time delays within the script. For example, you might want to insert a five minute time delay (300 seconds) at the start of the script. See the example below:

   Run ("c:\apps\office\winword.exe","")
   
   TimeDelay (300)
   
   ; Recorded Macro N:\APPS\WINBATCH\WINMACRO\MSWORD.WBM
   
   SendKey(`{ALT}fon:\apps\winbatch\winmacro\document.txt{ENTER}{DOWN}{DOWN}`)
   SendKey(`{DOWN}{DOWN}{DOWN}{ENTER}**********{ENTER}{ENTER}Now{SPACE}I{SPACE}`)
   SendKey(`am{SPACE}continuing{SPACE}to{SPACE}type{SPACE}in{SPACE}{ENTER}`)
   SendKey(`this{SPACE}document.{SPACE}{SPACE}I{SPACE}will{SPACE}now{SPACE}`)
   SendKey(`sav{BACKSPACE}{BACKSPACE}{BACKSPACE}close{SPACE}the{SPACE}{ENTER}`)
   SendKey(`document{SPACE}without{SPACE}saving{SPACE}mu{SPACE}{BACKSPACE}`)
   SendKey(`{BACKSPACE}y{SPACE}changes.{ENTER}{ENTER}Here{SPACE}goes.....`)
   SendKey(`..{ALT}fxn{ALT}frn:\apps\winbatch\winmacro\msword.wbt{ENTER}`)
   
   ; End Recorded Macro
   

4. There is one more modification you need to make to the WinBatch script. The script must run in an endless loop if you want to emulate continuous human usage. To do this, assign the script a subroutine name and then call the subroutine at the end of the script, thus repeating the script in an endless loop. See the example below:

   :word
   
   Run ("c:\apps\office\winword.exe","")
   
   TimeDelay (300)
   
   ; Recorded Macro N:\APPS\WINBATCH\WINMACRO\MSWORD.WBM
   
   SendKey(`{ALT}fon:\apps\winbatch\winmacro\document.txt{ENTER}{DOWN}{DOWN}`)
   SendKey(`{DOWN}{DOWN}{DOWN}{ENTER}**********{ENTER}{ENTER}Now{SPACE}I{SPACE}`)
   SendKey(`am{SPACE}continuing{SPACE}to{SPACE}type{SPACE}in{SPACE}{ENTER}`)
   SendKey(`this{SPACE}document.{SPACE}{SPACE}I{SPACE}will{SPACE}now{SPACE}`)
   SendKey(`sav{BACKSPACE}{BACKSPACE}{BACKSPACE}close{SPACE}the{SPACE}{ENTER}`)
   SendKey(`document{SPACE}without{SPACE}saving{SPACE}mu{SPACE}{BACKSPACE}`)
   SendKey(`{BACKSPACE}y{SPACE}changes.{ENTER}{ENTER}Here{SPACE}goes.....`)
   SendKey(`..{ALT}fxn{ALT}frn:\apps\winbatch\winmacro\msword.wbt{ENTER}`)
   
   ; End Recorded Macro
   GoSub word
   

5. Once you are done editing the WinBatch script, save your changes and close Notepad.

6. Test the script at the WINFRAME console by using the Program Manager Run option. If the script (and macro) are created properly, the script executes in an endless loop.

   NOTE: Several WinBatch macros can be incorporated into the same WinBatch script. For example, you can have an MSOFFICE.WBT script that includes the MSWORD.WBM, MSEXCEL.WBM, and MSPPT.WBM macros inside of it. Simply copy and paste the individual macros into the script file. You will need to insert a "run" statement (see Step 2 above) before each macro and you may also want to insert time delays before each macro to emulate human behavior.

Using WinBatch Script and Performance Monitor to Perform System Configuration

The following sections discuss the methodology used to perform system configuration.

System Configuration Process

As described in the overview of the system configuration process, a connection is made from the WinFrame client to the WinFrame server. A WinBatch script is executed (using the Run option in Program Manager) and the entire WinFrame session is minimized to the client's task bar. Then four more WinFrame sessions are started (one by one) on the WinFrame server and the same WinBatch script is executed each time. A total of five unique WinFrame sessions simultaneously execute the WinBatch script in an endless loop. This simulates five people actively using an application on WinFrame.

Once five sessions are active, run Performance Monitor on the WinFrame console. A log file is created that captures processor and memory statistics. Once these statistics are gathered and recorded into the table, you can continue with the next set of five connections. A Performance Monitor log is created again, now capturing statistics for ten total user connections, and then 15, 20, 25, and so on.

The result of this exercise is a table that depicts actual processor and memory utilization statistics given varying user loads in five-user increments. When average processor and/or memory utilization approaches 90%, the WinFrame server is reaching its maximum number of user connections.

Creating a Log File in Performance Monitor

Performance Monitor creates a log file that allows you to monitor specified counters over a fixed period of time. For example, you can monitor processor and memory utilization over a ten minute period and find the minimum, maximum, and average utilization rates for each of the counters.

To create a log in Performance Monitor:

1. Execute Performance Monitor.

2. From the View menu, select Log.

3. Click the button with the plus (+) sign. This allows you to add appropriate objects to your log. In the Objects field, highlight Memory and click Add. Again in the Objects field, highlight System and click Add. Click Done.

4. From the Options pull-down menu, click Log and then type the path and file name for your log file. You may want to create a separate directory to store your log files (for example, M:\LOGS) and you may want to name your log file so that it reflects how many sessions are currently active (for example, 5USERS.LOG, 10USERS.LOG, etc.). At the bottom of the screen, change the interval to five seconds. This allows 120 total polls over a ten minute period.

5. Click Start Log. Make note of the start time so you can stop logging ten minutes from the start time. Data is collected every five seconds. The size of the log file will increase with each poll.

6. After ten minutes have elapsed, from the Options pull-down menu, click Log and then click Stop Log. The approximate size of your log should be 300-350KB (assuming a five second poll interval over ten minutes).

7. From the View pull-down menu, click Chart.

8. From the Options pull-down menu, click Data From. The Data From screen appears.

9. Click Log File and then click the small box to the right with the three dots inside. Select the path and filename of the log file you just created. Click OK twice.

10. Click the button with the plus (+) sign. Highlight Memory and the Pages/sec counter. Click Add. Highlight System and the % Total Processor Time counter. Click Add. Click Done.

    A line graph is created; however, it is more important to look at the numerical statistics rather than the line graph itself. Note that each counter displays Average, Minimum, and Maximum values.

11. Record these statistics into the table you create and repeat the process for the next set of five connections. See "Recording Statistics into a Table" later in this document for a sample table.

Analyzing a Log File

The most important statistic to look at with each counter selected is Average utilization. This statistic averages that counter's utilization over the entire length of time of the log. You may want to document Minimum and Maximum utilization to understand the best-case and worst-case utilization statistics of a particular counter.

When you have an average CPU (% Total Processor Time) of 90% or above, you are reaching the acceptable capacity of your WinFrame server before users begin to notice a significant degradation in performance. Memory is much easier to add to a server than processors and is relatively inexpensive. If you are experiencing high Pages/sec values, simply add more memory. However, when your processor statistics are in the 90th percentile, your system may not be capable of adding another processor. If this is the case, it may be time to expand into an additional WinFrame server and to take advantage of Citrix's Load Balancing Option Pack.

Recording Statistics into a Table

It is important to record your Performance Log statistics in a table. By capturing logs in five-user increments, you can see how additional (simulated) users affect your WinFrame server. You should see a gradual increase in average utilization for each group of five users.

The table below is only a sample. It does not convey actual WinFrame statistics. It does, however, illustrate what a system sizing table might look like. Do not feel restricted to the two counters recommended in this document - % Total Processor Time and Pages/sec. Feel free to capture and record statistics for any additional Performance Monitor counters you feel are applicable to your configuration.

Processor Utilization Percentage Memory Utilization Percentage
(% Total Processor Time) (Pages/sec)

# Sessions Average Minimum Maximum Average Minimum Maximum

5 15% 5% 77% 6 0 119
10 18% 7% 82% 16 5 122
15 25% 10% 75% 30 11 127
20 36% 14% 88% 36 22 139
25 46% 18% 95% 44 40 164
30 53% 20% 88% 55 51 173
35 59% 26% 92% 62 59 188
40 67% 35% 96% 69 64 192
45 74% 44% 97% 77 69 199
50 82% 57% 98% 88 75 206

The % Total Processor Time is the average percentage of time that all the processors on the system are busy executing non-idle threads. On a multiprocessor system, this is 100% if all processors are always busy, 50% if all processors are 50% busy, and 25% if all of the processors are 25% busy. It can be viewed as the fraction of the time spent doing useful work. Each processor is assigned an idle thread in the idle process, which consumes those unproductive processor cycles not used by any other threads.

Pages/sec is the number of pages read from the disk or written to the disk to resolve memory references to pages that were not in memory at the time of the reference. This is the sum of Pages Input/sec and Pages Output/sec. This counter includes paging traffic on behalf of the system cache to access file data for applications. This value also includes the pages to and from non-cached mapped memory files. This is the primary counter to observe if you are concerned about excessive memory pressure (that is, thrashing), and the excessive paging that may result.

Summary

When performing this system configuration exercise, you do not have to start with five concurrent sessions. If you have a server that you believe should support 60 concurrent users, for example, you may want your first Performance Monitor log to capture 30 concurrent users, followed by 35, 40, 45, 50, 55, and 60. Exactly how much data you want to collect is entirely up to you.

Appropriately sizing a WinFrame server can be a challenging exercise. By using Wilson WindowWare's WinBatch utility, you can create macros and scripts to simulate user load without inconveniencing actual users. Using Performance Monitor to capture a log file for each five user increment is a great way to monitor your system, and to determine the optimal number of concurrent users your system is capable of before placing WinFrame into a production environment.

If you would like to contact Wilson WindowWare regarding WinBatch, please call (800) 762-8383. To learn more about WinBatch, you may consult their Web site at http://www.windowware.com.

If you would like to request on-site assistance, please contact a local Citrix reseller or call your Citrix sales representative at (800) 437-7503 to inquire about Citrix's on-site professional services.

---

Article ID:   W13488

Filename:   How to Size a Winframe Server.txt

File Created: 2001:02:24:15:24:46

Last Updated: 2001:02:24:15:24:46