• System Architects/ Notes System Administrators who are charged with design and implementation of a Notes System to meet specific user growth and workload needs.
• Application developers who develop/debug complex applications where performance and scalability is important.
• Notes Administrators who need to upgrade to newer versions or point releases of Lotus Domino and newer versions and patches of Application program which reside on Domino.

• Easy Setup - GroupSizr configures your experiments by providing the user with point and click interfaces. GroupSizr lets you define acceptance criteria and error handling, among other things.
• Modular construction (and licensing) - There are many components that make up a thorough or complete test system. This Sizer system is the most advanced test system in the industry, and constructed with modular components. The users of these systems have very diverse test interests and the advantage that modular construction offers is the ability to selectively deploy and license the components that are relevant. This ability translates into lower cost of ownership, lower learning curves, scalability to meet specific needs, and of course results in high usability of the product. This complete test system (collection of all components) is what we call the GroupSizr Suite.
• Ease of Use : GroupSizr exposes a powerful set of functions with an intuitive user interface. This transforms performance testing which until now was a "black art" to an easily accomplishable task.
• Reproducibility of Results: GroupSizr has been designed top-down to the rigorous standards of a benchmarking tool. This results in more accurate correlation and reproducibility of results from different iterations of the same test.
• High efficiency and low cost of ownership: The workload generator module (Sizer) can simulate more than one thousand of users on a single PC, thus minimizing the need for expensive lab resources. The Sizer runs on the Microsoft Windows NT or Microsoft Windows 2000 operating systems and on Intel hardware, which results in lower test infrastructure costs. Even on a low end PC, the Sizer can create about 1500 users (PIII 400MHz 128MB), depending on workload. "Faster" PCs and sparser workloads would allow even higher number of simulated users. Using our LoadDirector technology, you can scale the user creation capabilies to create very a large collection of simultaneous users (We have run the workload generators to create up to 100k Users on a rack of PCs).
• Superior Test Management Capabilities. Ability to control experiments by using command verbs and run-time point-and-click interfaces which save valuable experiment time while providing relevant results.
• Run-Time Interactivity: The interactivity features allow a user to understand the characterisitics of the System Under Test during experiment run-time, ie. well before test completion. This reduces testing time. GroupSizr provides the ability to truncate or cancel experiments which may not be relevant without the need to have them finish.
• Statistical Synopsis of experiments: GroupSizr provides a statistical synopsis of the experiment by manipulating run-time data. This synopsis gives an in-depth understanding of the characteristics of the System Under Test during a certain experiment.
• Multi-platform: GroupSizr can target any Notes Server and Application under test running on any Operating System or hardware platform supported by Lotus. This enables the user to compare performance of different hardware and Software platforms.
• Multi-protocol : GroupSizr can work with any protocol that is being used between the Notes client and the server. Since GroupSizr piggy backs to the Notes RPC through the API, this is seamless and no special setups are necessary.
• Secure: GroupSizr is auto-secure based on the Notes Ids that are being used by the client. If password is set on the Notes ID, GroupSizr prompts for passwords without echoing them to the terminal.
• V3/V4/V5/V6(prerelease) compatible. GroupSizr runs on several versions of Lotus Notes, ranging from V3 to pre-release versions of V6. It auto-configures itself at install time to understand your Notes Client settings and configuration. Technovations constantly provides updates to match new versions of Domino as and when Lotus releases these versions and updates.
• Supports long test runs: GroupSizr is capable of doing long experimental runs by using the REWIND command verb and by accommodating long script files.
• Rich Text fields: GroupSizr is capable of attaching rich text fields to Notes, in addition to plain text files.
• GroupSizr provides the ability to provide flexible text patterns for random data being input to Notes, thus giving the user a level of control to define the content that gets into the fields of the Notes database under test. This is done by supplying such data in the NOTESIZR.TXT file which is resident in the Notes program directory.

Other commercially available tools also play events fast enough using the graphical interface to mimic "one fast user". They do not create sessions on the server, which are extremely important to produce accurate performance characteristics. GroupSizr comes very close to mimicking the activity of real users by creating sessions and giving the users the capability of configuring a benchmark test with the utmost flexibility.

Here are some unique capabilities of GroupSizr:

• Plays commands not only to create static workloads but generates traffic dynamically against the System Under Test.
• GroupSizr can be customized to work with specific database designs and forms. This level of customization is important to understand the performance and sizing characteristics of not only the Notes System, but the application designed on top of Notes. Tools which work only with a standard template may not be very representative of real customer environments.
• Can target up to 50 Domino Servers or Databases simultaneously from a single workload generator.
• Can target multiple number of Forms and Views in any given database, all from a single workload generation point.
• Allows the user to define Test Acceptance Criteria before starting User Simulation.
• Gives logging facilities which allow developers to debug application programs.
• Gives user the ability to define Error Handling which can control the course of the experiment.
• Allows user to automatically desynchronize themselves for more realistic simulations.
• Allows users to define timeouts for user operations.
• Graphically and Numerically Presents Run-Time performance and status views during test.
• Presents performance results in a easy to understand concise form.
• Provides a documentation wizard to convert your test info into a results page which is committed into a Notes database for on-line or off-line browsing and analysis.
• GroupSizr provides the ability to provide flexible text patterns for random data being input to Notes, thus giving the user a level of control to define the content that gets into the fields of the Notes database under test.
• GroupSizr also has other features which can be used to mimic the activity of real users more realistically than other testing paradigms.
• Allows simulation of multiple scripts in the context of a single test.
• Allows the test user to define custom collections to analyze test activity.
• Has constructs to create normal or bursty tests.
• Has an automatic Report Writer and Configuration Manager that produces an HTML report for each test.

GroupSizr has a built-in command checker which checks for validity of commands as they are supplied through a scriptfile. This validation mechanism mainly identifies syntactic errors and semantically malformed lines for some commands. !s and *s at the beginning of a new line are treated as comment characters and the rest of the corresponding lines are ignored. The commands are not case-sensitive and allow themselves to be abbreviated to the first 3 characters.

Here are the currently supported set of command verbs and the syntax for the commands.

• OPEN : This command opens the Database Under Test. The name of the database and the name of the server which hosts the database are implied by the SETUP options (Basic Setup screen).

Syntax : OPEN 1
• CLOSE : This command closes the Database Under Test. The database name is supplied using the "Basic Setup" screen as in the case of the OPEN command.

Syntax : CLOSE 1
Database to be closed is again implied as in the case of the OPEN command.
• ADD : This command is used to add notes to the database.

Syntax : ADD #Notes #SmFldSt #SmFldRand #BigFldSt #BigFldRand #Att1 #Att2 #Att3
This command works against a form which has 2 fields in it. A "Small" field and a "big" field. The command is best explained with an example.
Example: ADD 10 100 10 1000 100 att1.doc att2.tmp att3.exe

In the above example, 10 Notes will be added to the database. Each note will have a random small size field length of anywhere from 100 to 110 bytes, with the larger field being anywhere from 1000 to 1100 bytes in length (at random). The file will also consist of 3 attachments with file names att1.doc, att2.txt and att3.exe. These files are all expected to be found in the current execution directory.

If the arguments for the number of attachments is not supplied to the command, then the note will be added without attachments. If no arguments are specified for the field sizes, a zero length field will result by default.

The specific fields and the form which will be written to are specified in the "Database Design Settings" on the Basic Setup screen.

• UPDATE : This command is used to update notes that already exist in the database.

Syntax: UPDate #Notes #SmFldSt #SmFldRand #BigFldSt #BigFldRand #Att1 #Att2 #Att3
The syntax and explanation is exactly the same as in the case of the ADD command above.
This command changes the fields of existing notes within the database.

As in the case of the ADD command, the specific fields and the form which will be updated are specified in the "Database Design Settings" on the Basic Setup screen.

• DELETE : This command deletes random notes in the database.

Syntax : DELETE #Notes
Example: DELETE 10
The above command deletes 10 random notes from the given database. This deletes real notes in the database and this is done by maintaining a free list map constructed at startup and maintained in memory throughout the run.
• READ : This commands reads a random number of notes from the database.

Syntax : READ #Notes
Example: READ 5
The above example randomly reads 5 notes from the given database.
• NAVIGATE : This commands uses the given view to navigate through peer levels.

Syntax: NAVIGATE #ofNavigates #NumberofPeers
Example: NAVIGATE 2 10

The above command invokes the Navigate command twice and thumbs through 10 peers in the given view.

• FTSEARCH : This command performs a Full Text Search on the database for supplied queries. The target database for this command is the Database Under Test specified as part of the basic SETUP.

Syntax : FTSEARCH #Searches Log Res* Res Res Query1 Query2 Query3 Query4 Query5
This command has a 3 reserved fields (*denoted by the "Res" string). These fields should have numbers in them. There are 5 query components that can be specified as input to each search.
Examples:
• FTSEARCH 1 0 0 0 0 Windows
• FTSEARCH 1 1 0 0 0 Windows
The above examples search the full text database for all occurrences of "Windows". In the first case, the number of matches found are not logged, but in the second case, the results of the search are logged to runlog (NOTESIZR.LOG by default).
• DBOPEN : This command opens a specific database as specified by the user. The name of the database and the name of the server which hosts the database are supplied as arguments to the command.

Syntax : DBOPEN 1 0 0 0 0 <ServerName> <DatabaseName>
Example: DBOPEN 1 0 0 0 0 Tokyo JSCHMOE.NSF

This example opens the database JSCHMOE.NSF on the server Tokyo.

• DBCLOSE : This command closes a specific database as specified by the user. The name of the database and the name of the server which hosts the database are supplied as arguments to the command as in the case of OPEN.

Syntax : DBCLOSE 1 0 0 0 0 <ServerName> <DatabaseName>
Example: DBCLOSE 1 0 0 0 0 Tokyo JSCHMOE.NSF

This example closes the database JSCHMOE.NSF on the server Tokyo.

• DBADD : This command is used to add notes to any database on any server.

Syntax : DBADD #Notes #SmFldSt #SmFldRand #BigFldSt #BigFldRand <ServerName> <DbName> #Att1
This command works against a form which has 2 fields in it. A "Small" field and a "big" field. The command is best explained with an example.
Example: DBADD 10 100 10 1000 100 Tokyo JSCHMOE.NSF att1.doc

In the above example, 10 Notes will be added to the database JSCHMOE.NSF on the server Tokyo. Each note will have a random small size field length of anywhere from 100 to 110 bytes, with the larger field being anywhere from 1000 to 1100 bytes in length (at random). The file will also consist of an attachment with file name att1.doc. This attachment file is implied to be found n the current execution directory.

If the argument for the attachment is not supplied to the command, then the note will be added without it. If no arguments are specified for the field sizes, a zero length field will result by default.

As in the case of the ADD command, the specific fields and the form which will be written to are specified in the "Database Design Settings" on the Basic Setup screen.

• UPDATE : This command is used to Update notes in any database on any server.

Syntax: DBUPDATE #Notes #SmFldSt #SmFldRand #BigFldSt #BigFldRand <ServerName> <DbName> #Att1
The syntax and explanation is exactly the same as in the case of the DBADD command above.
This command changes the fields of existing notes within the database.

As in the case of the DBADD command, the specific fields and the form which will be written to are specified in the "Database Design Settings" on the Basic Setup screen.

• DBDELETE : This command deletes random notes in any database on any server.

Syntax : DBDELETE #Notes 0 0 0 0 <ServerName> <DatabaseName>
Example: DBDELETE 10 0 0 0 0 Tokyo JSCHMOE.NSF
The above command deletes 10 random notes from the given database JSCHMOE.NSF on the server Tokyo. This deletes real notes in the database
• DBREAD : This commands reads a random number of notes from any database on any server.

Syntax : DBREAD #Notes 0 0 0 0 <ServerName> <DatabaseName>
Example: DBREAD 5 0 0 0 0 Tokyo JCHMOE.NSF
The above example randomly reads 5 notes from the database JCHMOE.NSF on the server Tokyo.
• DBNAVIGATE : This commands uses the given view (in the Database design Settings of the "Basic Setup" screen in GroupSizr) to navigate through peer levels. It works against any database on any server.


Syntax: DBNAVIGATE #ofNavigates #NumberofPeers 0 0 0 <ServerName> <DatabaseName>
Example: DBNAVIGATE 2 10 0 0 0 Tokyo JSCHMOE.NSF

The above command invokes the Navigate command twice and thumbs through 10 peers in the given view. The database used for this navigate operation is JCHMOE.NSF on the server Tokyo.
 

• MAIL: The MAIL command is used to synthesize and push mail to the router. This could be used in conjunction with other commands to develop the overall workload or could be used independently to test the transfer/delivery capabilities of the mail router.

Syntax: MAIL #Memos #SubjSt #SubjEnd #BodySt #BodyEnd "<To Whom>" att1 att2
Examples:
• MAIL 10 10 100 1000 100 Group1 TEMP1.DOC TEMP2.DOC
• MAIL 10 10 100 1000 100 "John Doe" TEMP1.DOC TEMP2.DOC
The above commands send 10 mail messages with subject sizes randomly picked between 10 and 110 bytes and body size between 1000 and 1100 bytes. They also send 2 local attachment files (TEMP1.DOC and TEMP2.DOC). The first command sends mail to a group called "Group1" and the second command sends the mail to a specific user. Note that these user or group entries have to be registered in the Name and Address Book.

If you would like to send to random number of users rather than to specific ones, you can use the RANDOM construct in the MAIL command. Here is an example.

• MAIL 10 100 100 1000 100 RANDOM
Before executing a run with the above command, you need to go through a couple more steps.
1. Determine which users you want to send messages in random. For example, you may want to send messages to Sandy, John and Joe.
2. Register these names in the MAILLIST.TXT file. An example file comes with your installation. Note that if you want to include the full registered name of the destination user, you need to use the FIRSTNAME_LASTNAME format.
The MAIL command with the RANDOM construct picks up a random recipient entry from the MAILLIST.TXT file every time the command is encountered and sends mail to that user. If you want to define frequency (more messages sent to one user over another), all you need to do is to add more entries for that user within the MAILLIST.TXT file.
 
• REPLICATE : This command replicates the notes in a local database with a replica on a remote database.


Syntax: REPLICATE Res Log Res Res Res ReplCmd ReplicaServer DbtoReplicate
Example: REPLICATE 1 1 0 0 0 REPL TOKYO NOTESIZR.NSF

The above command would replicate the database called NOTESIZR.NSF (resident locally) with a replica on the remote server called TOKYO. It would also log all details of the replication to the GroupSizr Log.

Other examples:

REPLICATE 1 1 0 0 0 PULL TOKYO NOTESIZR.NSF

REPLICATE 1 1 0 0 0 PUSH TOKYO NOTESIZR.NSF

REPLICATE 1 1 0 0 0 REPL TOKYO

REPLICATE 1 1 0 0 0 PUSH TOKYO

REPLICATE 1 1 0 0 0 PULL TOKYO

In the last 3 examples, since a database was not specified, all the databases on the local machine will be replicated with corresponding replicas on the server TOKYO.

• NABADDNOTE - NAN : This command is used to populate Person entries into the name and address book (this works with the NAB design in Notes 4.5/Domino and previous Notes versions).


Syntax: NAN NoofPersonRecs UsrOffset res res res LastNamePattern

Example: NAN 300000 100000 0 0 0 JoeUser_

If the above command is executed, it will add 300K entries into the database under test. The target database design is assumed to be in the Name & Address Book format. The user names for the entries start with the text pattern "JoeUser_100001" (because of the LastNamePattern and UsrOffset parameteres specified above) and the last entry will have the text pattern "JoeUser_400000".

• NABUPDATENOTE - NUN : This command is used to update Person entries into the name and address book. This works similar to the NABADDNOTE command, except that it updates an entry which already exists in the database.


Syntax: NUN NoofPersonRecs UsrOffset res res res LastNamePattern

Example: NUN 200 500000 0 0 0 JoeNewUser_

If the above command is executed, it will update 200 random entries in the database under test. The user names for the entries start with the text pattern "JoeNewUser_500001" (because of the LastNamePattern and UsrOffset parameteres specified above) and the last entry will have the text pattern "JoeNewUser_500200".

• NABADDGROUP - NAG : This command is used to populate Group entries into the name and address book


Syntax: NAG NofGrps GrpOffset NofUsrs UsrOffset resrvd GrpNamePattern LastNamePattern

Example: NAG 100 30 1000 200000 0 TestGroup_ JoeUser_

If the above command is executed, it will add 100 entries into the database under test as group records. The target database design is assumed to be in the Name & Address Book format. The Group names for the entries start with the text pattern "TestGroup_31" (because of the GrpNamePattern and GrpOffset parameteres specified above) and the last group entry will have the text pattern "TestGroup_130". Each group entry will consist of a 1000 PersonName fields starting with the text pattern of "JoeUser_200001" and ending with the pattern "JoeUser_201000".

• NABUPDGROUP - NUG : This command is used to update Group entries into the name and address book.


Syntax: NUG NofGrps GrpOffset NofUsrs UsrOffset resrvd GrpNamePattern LastNamePattern

Example: NUG 10 40 3000 500000 0 NewTestGroup_ NewJoeUser_

If the above command is executed, it will update 10 entries into the database under test as group records. The target database design is assumed to be in the Name & Address Book format. The Group names for the entries start with the text pattern "NewTestGroup_41" (because of the GrpNamePattern and GrpOffset parameteres specified above) and the last group entry will have the text pattern "NewTestGroup_50". Each group entry will consist of a 3000 PersonName fields starting with the text pattern of "NewJoeUser_500001" and ending with the pattern "JoeUser_503000".

• RCONSOLE: This command is used to execute remote console operations.

Syntax: RCONSOLE #Ops Log Res* Res Res Cmdw1 Cmdw2 Cmdw3 Cmdw4 Cmdw5
This command has 3 reserved fields (*denoted by the "Res" string).
The syntax is similar to the FTSEARCH command.
Examples:
• RCONSOLE 1 0 0 0 0 show tasks
• RCONSOLE 1 1 0 0 0 show tasks
The above commands accomplish the execution of the command "show tasks" on the remote console of the given server. In the first command, the results of the remote console command are not logged, but in the second case, the results are logged to the log file (NOTESIZR.LOG by default).

Other Examples of the RCONSOLE command

RCONSOLE 1 1 0 0 0 SHOW TRANS

RCONSOLE 1 1 0 0 0 SHOW USERS

RCONSOLE 1 1 0 0 0 LOAD ROUTER

RCONSOLE 1 1 0 0 0 TELL ROUTER QUIT

RCONSOLE 1 1 0 0 0 ROUTE LONDONHUB

RCONSOLE 1 1 0 0 0 LOAD REPLICA

RCONSOLE 1 1 0 0 0 REPL TOKYO

RCONSOLE 1 1 0 0 0 REPL TOKYO\NAMES.NSF

RCONSOLE 1 1 0 0 0 PULL TOKYO\NAMES.NSF

RCONSOLE 1 1 0 0 0 PUSH TOKYO\NAMES.NSF

RCONSOLE 1 1 0 0 0 UPDALL -F NOTESIZR.NSF

RCONSOLE 1 1 0 0 0 UPDALL -V NOTESIZR.NSF

The last few commands illustrate how you can bypass the default scheduling algorithms in the Notes Name and Address books to do scheduled Replication, View Indexing and Full Text Indexing using the RCONSOLE command.

• REWIND : This command allows a pattern in the scriptfile to be iterated a number of times.

Syntax : REWIND #Iterations
Example : REWIND 300
This example specifies that all lines in the script file which occur after the REWIND command will be iterated 300 times.

• RUNFOR - This command is used to specify the length of time for each run.


Syntax: RUNFOR #seconds

Example RUNFOR 3600

The above example command would halt a test after an hour f testing. The RUNFOR command overrides the REWIND command.

• PAUSE : This command is used to create event lists using the script file. It takes at least one argument which specifies the number of seconds to pause. It could optionally be overloaded with a second argument which is used to create randomness in the PAUSE times for different threads and different instances of the PAUSE command within the same script.

Syntax : PAUSE WaitLowerLimit(seconds) [WaitUpperLimit(seconds)]
Examples :
• PAUSE 3 //will make the execution thread pause for 3 seconds
• PAUSE 5 10 // will cause a random wait anywhere between 5 and 10 seconds
Tip: The PAUSE command could optionally be used to customize desynchronization of script activity.

GroupSizr supports additional arguments for the PAUSE command to control script execution based on certain server events. The extended syntax for the new PAUSE command is show below:

Syntax2: PAUSE seconds [seconds] res res res UNTIL Pattern0 [Pattern1] ..
Example2: PAUSE 10 15 0 0 0 UNTIL Indexer

In the above example, the script is forced to pause UNTIL the "Show Tasks" command indicates that the Indexer is running. Remember that the text pattern could be anything which shows up when you do a "Show Tasks" command on the console, and is case sensitive.

Syntax3: PAUSE seconds [seconds] res res res UNLESS Pattern0 [Pattern1] ..
Example3: PAUSE 10 15 0 0 0 UNLESS Router

In the above example, the script is forced to pause UNLESS the "Show Tasks" command indicates that the Router is running. This command is used to pause the script until the Router is loaded (externally or programmatically). Again, remember that the text pattern could be anything which shows up when you do a "Show Tasks" command on the console, and is case sensitive.

The "PAUSE UNTIL" and the "PAUSE UNLESS" commands give you a greater flexibility to run extended test sets without operator attendance.
 

For those users who want to target specific Notes Forms, Views, Fields, and with specific content instead of randomly generated data, GroupSizr provides a powerful set of advanced commands. These commands enforce more syntax. These commands have the following general features:

• Can Taget 50 Servers and/or Databases Simultaneously. The Database name and the Server name are parameters supplied to the command.
• Can write to 5 forms per database.
• Can operate of 5 views per database
• Can target any note based on its Notes ID
• Can write to 15 text fields in any note
• Can write to 5 Numeric fields in any note
• Can write to 1 time field into any note
• Can attach up to 5 files to any note.
• Can take stimulus input from user defined values or from files

• The parameters to each command are supplied as name-Value Pairs.
• You do not need to enter the full canonical for of the command to make it work. Parameters can be overloaded when required. This will make your script more readable.
• You can supply stimulus using the <file> directive. Using this approach will make your script more readable.
• If you have white-space embedded in the data that you supply to GroupSizr (for example, if you have a form name which is "Test Form", you MUST use the <file> directive. So, an example Name-Value pair will look like - formName=<file>formdata.txt - where the contents of the file "formdata.txt" witl be "Test Form".

• NVADD
• NVUPDATE
• NVDELETE
• NVREAD
• NVOPEN
• NVCLOSE
• NVNAVIGATE
• NVFTSEARCH

• NVADD - Adds Notes to a given Database and to a specific Server

Example Syntax: NVADD serverName=Tokyo&databaseName=NOTESIZR.NSF&
formName=SampleForm&textField1=SummaryField&tfValue1=Test&
textField2=SampleText&tfValue2=TestTest

The above command is a different form of the ADD and DBADD commands that we have presented above. *VERY IMPORTANT NOTE* The example syntax presented above spans multiple lines just for editorial clarity. In the real script, the entire command would be in a single line. Now let us look at how to develop a command where we can write more data into the note using the NVADD command.

NVADD serverName=Tokyo&databaseName=NOTESIZR.NSF&formName=SampleForm&
textField1=Field1&tfValue1=Test&textField2=Field2&tfValue2=TestTest&
textField3=Field3&tfValue3=Test3&textField4=Text4&tfValue4=TestTest4&
textField5=Field5&tfValue5=Test5&textField6=Text6&tfValue6=TestTest6&
textField7=Field7&tfValue7=Test7&textField8=Text8&tfValue8=TestTest8&
textField9=Field9&tfValue9=Test9&textField10=Text10&tfValue10=TestTest10&
textField11=Field11&tfValue11=Test11&textField12=Text12&tfValue12=TestTest12&
textField13=Field13&tfValue13=Test13&textField14=Text14&tfValue14=TestTest14&
textField15=Field15&tfValue15=Test15&
numberField1=Number1&nfValue1=12345&numberField2=Number2&nfValue2=12345&
numberField3=Number3&nfValue3=12345&numberField4=Number4&nfValue4=12345&
numberField5=Number5&nfValue5=12345&
attach1=attachment1.txt&attach2=attachment2.txt&attach3=attachment3.txt&
attach4=attachment4.txt&attach5=attachment5.txt

In the above example, we have developed a command that can write data to 15 text fields, 5 Number Fields and 5 attachments.

Note that if you do not explicitly supply a database name, form name and server name to the NVADD command, these values will be sourced automagically from the values that you supplied as part of GroupSizr "Basic Setup".
 

• NVUPDATE - Updates Notes on a given Database and to a specific Server.

This command has the same syntax as the NVADD command, except that the command will update an already existent note using user stimulus, rather than adding a new note to the database.

In addition to or instead of specifying just the formName for a note to be picked up to be updated in random (default), the user can taget a specific note using the noteID construct. To accomplish this, the NoteID has to be specified as Hex (HexaDecimal) quantity. Having a ...&noteID=12EF&.. argument as part of the command is all you need instead of the ..&formName=Form1&.. argument.
Note that specifying the noteID argument for the NVADD command has no effect because Notes generates the Note ID by itself for a new note.

If you want to update a note in a certain view, then you would supply the name of the view from which the note has to picked for the UPDATE operation. You would do this by specifying the name of the View as a parameter using the ..&viewName=<VIEWNAME>&.. connotation.

Note that if you specify both a viewName and a formName in your specification, the viewName will have precedence and will override the formName specification.

• NVREAD - Reads Notes on a given database and Server.

This command takes the name of the form as a parameter and reads a random note which belongs in that category.
Example Syntax: NVREAD serverName=Tokyo&databaseName=NOTESIZR.NSF&formName=SampleForm
NVREAD serverName=Tokyo&databaseName=NOTESIZR.NSF&noteID=324D
NVREAD serverName=Tokyo&databaseName=NOTESIZR.NSF&viewName=SampleView

If you want to force GroupSizr to read a specific note instead of picking out one in random, you can specify the ..&noteID=<NOTEID>&.. parameter.

If you want to read a note in a certain view, then you would supply the name of the view from which the note has to picked for the UPDATE operation. You would do this by specifying the name of the View as a parameter using the ..&viewName=<VIEWNAME>&.. connotation.

Note that if you specify both a viewName and a formName in your specification, the viewName will have precedence and will override the formName specification.

• NVDELETE - Deletes a Note on a given database and server.

This command can be used to delete a note which belongs in a certain view, uses a certain form or by pinpointing to it uniquly using a NoteID.
Example Syntax:
NVDELETE serverName=Tokyo&databaseName=NOTESIZR.NSF&formName=SampleForm
NVDELETE serverName=Tokyo&databaseName=NOTESIZR.NSF&viewName=SampleView
NVDELETE serverName=Tokyo&databaseName=NOTESIZR.NSF&noteID=3245

This command works very similarly to the NVREAD command. Please read the other NV commands until this far to understand the syntax and workings of this command.

• NVOPEN - Opens a handle to a specifc database and server.

Example: NVOPEN serverName=Tokyo&databaseName=NOTESIZR.NSF
• NVCLOSE - Closes s a handle to a specifc database and server.

Example: NVCLOSE serverName=Tokyo&databaseName=NOTESIZR.NSF
• NVNAVIGATE - Refreshes and Traverses a certain view on a specific database and server.

Example:
NVNAVIGATE serverName=Tokyo&databaseName=NOTESIZR.NSF&
viewName=SampleView&type=NEXT_PEER

This command works with a given view, rebuilds the view (to update it) if required, and traverses through it like a user would. There are 2 ways a user would traverse the set of notes, Flat or Hierarchical. To specify the "type" of navigate we want GroupSizr to do, we have the "type=" Name-Value pair. type=NEXT_PEER navigates flatly whereas type=NEXT navigates hierarchically if there is such hierarchy.

• NVFTSEARCH - Does a Full Text Search on a given database and server.

Example:
NVFTSEARCH serverName=Tokyo&databaseName=NOTESIZR.NSF&query=windows
In this case, note that we have specified not only the database and server on which to conduct the full text search, but also the query as part of the "query=" parameter.
Again, as mentioned earlier, if you have a query string which has white-spaces in ti, you can use the <file> directive to source the contents of the search string from a file.

Manipulating and using the SETUP Applet

The SETUP applet allows you to set up and customize the test per your specifications. The SETUP applet has several tab panels that allow such customization and this subsection will explain these in more detail.

The total number of users (Simultaneous Notes Clients) that need to be simulated for the test that we are about to conduct can be specified by either entering this in the "Concurrent Users to Simulate" field or by using the dropdown button to pick from preset choices.

Choosing how to handle errors

The SETUP screen allows the user to specify actions on errors generated during test.
By default, all errors are ignored (but reported) and tests continue in spite of them. This setting can be used if you can allow a margin for errors to hapen during test.
The test can be configured where test users are dropped as they encounter errors. This setting may be useful to figure out the optimal number of users that can be fielded by the server or application.
The test can be configured to terminate the test when any user encounters errors. This setting is frequently used during reliability and regression testing of applications.
There is also a mode where you could choose to retry Notes Operations whenever errors occur. This setting mimics the way some real applications work.

Choosing a script file to use for test

The Script File is used to play scripts which contain commands which instruct the GroupSizr run-time kernel about operations that we want to play through each simulated user. You can also view or edit the script file from here.

Choosing the Notes/Domino Server and Database Under Test

The Notes Server Name could be "local", which is used to test local Notes Database services. This field could also be used to specify remote Notes servers. The database under test is one that has the design qualities specified by fields in the advanced setup screen (which we shall examine next). The template NOTESIZR.NSF is supplied with the GroupSizr media and serves as the default server under test.

Before we start a new test, let us look at some of the other settings that can be manipulated as part of test SETUP.

The Form Name is the name of the form that you want to target. There are 2 text fields, a Time Field and a View that you can specify for the tests. If you DO NOT want to use any of these fields, you can blank the input to ignore the field altogether.

The Log File is used to Log information about each command into a file that can be analyzed later. This "Per Operation Result Log" is written in Comma Separated Variable (CSV) format which can be imported into popular spreadsheet programs.

What follows is a section of the log file created during this test.

Time:9989, USER#: 48, 0 ms, -REA
Time:9989, USER#: 48, 0 ms, -REA
Time:10001, USER#: 47, 6 ms, -ADD
Time:10042, USER#: 47, 41 ms, -ADD
Time:11609, USER#: 46, 15 ms, -ADD
Time:11622, USER#: 46, 13 ms, -ADD
Time:12693, USER#: 45, 14 ms, -ADD
Time:12741, USER#: 49, 4574 ms, -PAU
Time:13024, USER#: 45, 331 ms, -ADD
Time:13024, USER#: 49, 283 ms, -REA
Time:13024, USER#: 49, 0 ms, -REA
Time:13024, USER#: 49, 0 ms, -REA

The Time: field shows the relative time in Milliseconds from test start time. The User#: field is the identity of the simulated user for the experiment. This is followed by a field which shows the Round-Trip Response-Time for this operation, and the last field show the type of operation that was performed by the user.

The location of the NOTES.INI is an informational text box which gets set automatically at install time. If you have multiple vrsions of Notes running at the same time, this message may be useful to figure out the exact location where GroupSizr is installed and running.

Specifying Time-outs for Operations.

The Operation Time-out parameter defines the length of time that a request will wait to be serviced when inactivity occurs. If the request takes longer than this specified time, the request will terminate and an error will result. This error can be caught and thrown if desired or can terminate the user or experiment, as defined in the "Error Handling" panel. Note that if you anticipate the operation to take a long period of time, you would need to set this parameter to be high enough value. Note that you can set the timeout value to "0" and override this function.
 

Customizing the creation of users for test

It may be important in certain test scenarios to replicate the pattern in which users get created during test. GroupSizr gives you the ability to ramp up users by allowing you to specify the Minimum frequency and Maximum frequency of creation.

For example, if you wanted users to be created between 5 seconds and 20 seconds, you would specify 5 seconds in the "Minimum Frequency Text box" and 20 Seconds in the "Maximum Frequency Text box". Note that the users will still be created at random.

If you want to create users at a constant rate (rather than being random as in the above example), you can do this by keeping the values in the  "Minimum Frequency Text box" and " "Maximum Frequency Text box" the same.
 

User De-synchronization:

This panel also allows user to be automatically desynchronized so that not all users are generating requests at the same time. This is recommended to mimic real world behavior. A user can also defeat automatic de-synchronization and put de-synchronization commands manually in the script. file. This is done by having PAUSE commands at the top of the script file. As an example a "PAUSE 0 300" command at the top of the script file starts user activity randomly between 0 and 5 minutes.

Automatic de-synchronization can be disabled to enable very quick user RampUp. This can be useful to try quick tests with large number of users without necessarily waiting for GroupSizr to RampUp over an extended period of time.
 

Logging transactions to check Data Integrity of Server. This checkbox enables the logging of data for integrity checking, which is described in a later section. Note that this feature will write data to local storage (LOG.DAT file in GroupSizr program directory) and can impair ability to generate high loads. Also, this will write significant volumes of data depending on the length of the test and the workload offered to the server.
 
 

Ignoring Pause directives in script:

This is a shortcut to quickly run tests without pauses. This could be desirable in many scenarios, especially during debug of scripts or application. In such cases the Sizr is usually in "single user mode" - number of users simulated = 1.
There are other cases where this is used to simulate very large loads by ignoring all the "Pause" events in the script.
 

Defining when to start simulating test activity:

By default, each user after becoming active will start simulating test activity as defined by the basic test script or the test script assigned to that user. This is the natural and the best way of conducting tests because this is exactly the pattern that happens in real life.

However, there are sometimes specific needs to understand the impact of a large number of users hitting a server at the same time. Such tests can be used to determine the health of the server under extremely bursty workloads. GroupSizr can enable these tests by proving the test user the ability to "start simulating user activity only after all users are ramped up". In this case, GroupSizr will wait for all users to become active and then will hit the server with an active workload.

This "Automatic De-synchronization" feature can also be used creatively in cases where such bursty tests are being designed. Since the bursty tests by definition defeat user de-synchronization, the "Automatic de-synchronization" option can be turned off for such tests to enable users to become active as fast as the workload generator can ramp up the users.
 

By default, the collections are started when the test starts - user hits the "start test" button - and ends when test activity ends.

Collections can also be started "after user Rampup". This method analyzes the data that is collected only after all users have been activated. The time between the first user becoming active to the last user becoming active is the total RampUp time.

In some cases, you may want to enable collections after a specific period of time. You can do this by using the third option and by specifying the time. Note that the time is specified in Milliseconds.

As in the case where the test user can define the start of collections, the time when the collections can be ended can also be customized using this panel. Collections can be started "before user RampDown". This method analyzes the data that is collected until the time when the first user exits from the experiment. The time between when the first user completes test activity to the time when the last user completes such activity is defined as RampDown time.

In some cases, you may want to enable collections until a specific period of time. You can do this by using the third option and by specifying the time when you want to end collections. Note that the time is specified in Milliseconds.

Irrespective of how you define the collection/marshalling of test statistics, the test harness will still collect the data for all operations and record them in the log. So, the customization of test statistics can be used as a way to use GroupSizr to "pre-analyze test data" without sacrificing the ability to do post-test analysis.

Once you have completed the required setups in this screen, you can proceed to execute the test by depressing the Start Test button (in the Vital Settings/Controls panel). This will start the experiment and pop the display to monitor run-time events.
 
 
 
 

Advanced Test Settings

 

 
 

Assigning individual scripts to users.

During some tests, there comes a need to simulate users who do very different things. For example, when you are trying to mimic some users whose jobs are technical in nature and others whose jobs are administrative in nature, etc., it can be quite painful to come up with a single script which models the collective behavior of these users. One solution is to run different test instances for each user type and then merge the result sets. But even this approach can be quite tedious, error prone and requires excessive manual coordination. Technovations has invented a new and simple paradigm so you do not have to endure such pains any more.

GroupSizr gives you the ability to simulate such users by eliminating the need for modeling/result set merging. This is enabled by simulating multiple scripts in the same run. There are 3 approaches to accomplishing this:

Assigning by Pattern:

Here is how this is done:

• First, the test user checks the box that indicates that the user intends to "Assign individual scripts to test users".
• Second, defining a pattern (in the "By Pattern Text box") for the files that contain the directives that need to be simulated for the users. For example, if you have a pattern like "mult_" as shown above, this pattern will be used by GroupSizr to read individual files. If there is a file called mult_1.scr, this will be assigned to User#1. If there is a file called mult_37.scr, this script file will be assigned for User#37, and so on. So, in a 1000 user simulation scenario, it is possible to simulate the 1000 users each with its own script.

Let us assume that we need to simulate 25 users of a certain type and 975 users of a certain different type. In this case, we create 25 files as described above (say mult_1.scr through mult_25.scr with directives for User#1 through User#25 respectively). The basic script file that will be used for the test will consist of directive for the rest of the 1000 users (975).

GroupSizr will specifically search for the mult_*.scr pattern while assigning the individual scripts to users. When it cannot find a file that matches the specific pattern, it will assign the basic script pointed to by the "script file" field to that user. For example, if mult_26.scr does not exist (according to our example, it will not be), then the basic script is assigned to User#26.

Assigning by File

It is also possible to assign explicity using a text file. This is accomplished by specifying the bonding between a script and a simulated user. Picture below shows a file which defines such bonding.

Note that if a bond has not explicitly been defined, the test will automatically allocate the "basic test script" (defined in the Control Panel Applet of Setup) for this particular user.

Assigning Scripts Randomly

In some cases, it may be desirable to allocate script users randomly as the user is being created. This can be accomplished by defining a text file that contains a set of scripts that will be picked up randomly by each user on creation. Here is a illustration of such a file:

Note that the probability of choosing a specific script is defined implicitly by the number of occurrences of such a script in the container file.
 
 

Test Stop Modes

There may be several reasons why you may want to stop a test, ranging from "Satisfactory collection of data" to "Test needs more refinements". In any of these cases, there are 2 ways to stop the tests. The "Soft Termination" mode issues a signal to all users to terminate tests after completing the current task at hand. The "Hard Termination" option specifies that the test should be terminated immediately and all activity should be truncated to instantly "obey" the termination directive.
 
 
 

Sending Mail to a List

When using the MAIL command to send mail, recipients can be specified as part of the command (as described in the script syntax section of this document). While this can be very useful, a even more useful paradigm would be to distribute the messages across a larger set of users, and equally importantly, to control the distribution statistically, but with a very simple interface. This can be accomplished using the MAILLIST file. The maillist file has a set of user entries which the MAIL command can pick from when it is instructed to pick users at RANDOM.
 
 

Creating very large Collection of Users (Tens of Thousands of Users)

 

Would you like to create more than 2000 users ?
Would you like to create users from multiple distributed test locations ?
Would you like to manage tests easily (from a setup and go perspective) ?
Would you like result sets merged automatically into one comprehensive report ?

If you answered yes to one or more of these questions, you need the power of Technovations Load Director and Load Module logic to do this. Use of Load Director and Load Modules are part of GroupSizr enterprise edition. The use of these are also part of the GroupSizr training sessions.
 

The next screen-shot shows the GroupSizr run-time monitor. On the left-hand side of the screen, you see a graphical picture of the throughput through the experiment (shown in solid blue) and an average of the throughput (in dotted blue). Throughput is expressed in Operations/Second and is graphed over time (abcissa or x-axis). At the bottom of the monitor screen is a test state indicator.

The "Control Panel" of the run-time monitor also gives the user controls which can be used to PAUSE TEST or STOP TESTs. If a test is PAUSEd while executing, it sends a signal to all simulated users to stop after completing their current request. Just remember that if you have a lot of simulated users and you have heavy load on the server, the PAUSE may not happen right away.

The STOP TEST command button stops the test in the middle of test execution. Even if you decide to stop tests by using the STOP TEST button, you will still be able to get detailed statistics up until the time that you stopped the test. There are 2 STOP TEST modes.

Soft Termination : This is a signal which instructs all simulated users to stop after the current command. Again, Just remember that if you have a lot of simulated users and you have heavy load on the server, the STOP may not happen right away. Hard Termination : This is a hard stop at the time the user decides to terminate the test. The simulated users are all terminated immediately.

Hard Terminate is enabled by default. Hard Terminate is enabled by the presence of a HARD.TRM file in the GroupSizr installation directory. If you want to enable Soft Termination, all you have to do is to rename or delete the HARD.TRM file to some other name.

The run-time screen has updates the display every 5 seconds. This display interval can be changed for your convenience.

Using the Run-Time Monitor Applet

This section will demonstrate the use of the Run-Time Monitor and the facilities that it provides for analysis and control.

Test Warmup Time is the time to setup the experiment. This starts from the time the user hit the "Start Test" button to the time when the first user is generated. Test Rampup Time is the time to start up all the users for the test. This is measured from the time when the first user starts up to the time when the last user is started up. Test Time is the time from when the last user is started up to the time when the first user completes or drops out of the test. Rampdown Time is the exact opposite to Rampup Time. This is the time from when the first user drops off or terminates to the time when the last user drops off or terminates.

In the viewing panel, there is a indicator which show the total number of Active users Vs. Specified Users. This shows you the progress through test Rampup, but there is a more important use for this. Consider te following example: You want to find out how many users you can put on your system without generating errors, etc. Let us for the moment think that this magic number is 632. Rather than conducting many tests to figure out this optimal number of users for your system, GroupSizr allows you to come up with the answer with a single experiment. How ? Just specify the number of user in the SETUP screen to a high number. In our case, let us set it to 800. Set the "Error Handling" in the SETUP screen to "Terminiate User on Errors". Start Test. As the test progresses, users who encounter errors are dropped off automatically. 632 users will be running on the system without errors and will be visible through the Run-time screen. And this is how you will know that your system can support 632 users.

The stats show the total number of each type of operation played against the system under test. The "Average Rate" is the Throughput metric which presents the total number of operations completed per unit time on the system under test. "Average Latency" is the metric which reveals Response Time details for different operations conducted against the System Under Test. This is an average number (in milliseconds). Other Numbers presented on this screen are the Standard deviation of response time about the average Response Time, which shows the variability of individual response times from the average. There are 3 discrete points on the Response Time graph that are captured and presented on this screen - The MIN, MAX and LAST values. These, along with the Standard Deviation can be used to get a quick synopsis of the test before going into more details.

The "ALL" category folds the metrics for the individual operations into an overall test average. It is possible that you may need more detailed statistical information than what is presented in this screen. For this exact reason, a complete audit trail of Response times and timestamps are maintained for each individual operation conducted through the test. This log is in comma delimited (spreadsheet-friendly) format which can be manipulated further if necessary.

From the Statistics screen, you will be given the option of documenting this test or to start a new one. If you choose to Start Another Test, you will be redirected to the Basic Setup screen. If you decide to document results, you will be directed to the screen which helps you define your results database configuration and to generate your test report..

Once you are done entering comments, you may want to commit results into the database. The Commit and report generation will take a few seconds, but at the end of the commit, you will be able to "View Results Database".

Reports can also be committed to a HTML file instead of commiting to a Notes Document. This commit to HTML is the recommended method because it enables the use of other analysis tools which are part of the GroupSizr suite. Here are the screens that show the commit to a HTML file.

And here is the demoReport.html file that was committed.

GroupSizr provides a mechanism to automatically document all test parameters and values of importance. This is useful for analysis at a later point of time.

Conducting tests to check data integrity of Notes/Domino servers

With Notes/Domino servers being available on many high end platforms, including mainframes, there is an increasing push to litmus test the quality of the servers on these platforms in particular, and on Enterprise class installations in general. An integrity check is one where there is check and balance mechanism to make sure that the data written to the server is indeed what the server committed to the database. From a methodology perspective, it can be described very simply in 2 steps.

1. The data that is being written to the server needs to be logged from the client side
2. The data that is committed on the server needs to be checked by comparing it against the data that was logged from the client side.

GroupSizr can be instructed to generate logs of all "Server invasive activity" in a structured text format. Server Invasive Activities comprise of any operations which do one of the following.

• Addition of documents to the server's database
• Update of documents on the server's database
• Deletion of documents on the database.

The Comparison Step. The comparison step would really consist of several parts.

1. Importing the data logged by GroupSizr. The data for all operations described above is always logged to the "LOG.DAT" file in the GroupSizr program directory. You can read this file with a standard text editor. However, the key is to import this into a Notes database. To do this, we have to create a new database into which this data needs to be imported. The best way of doing this is to
• Create a new database copy of the database under test, but one with no documents in it.
• Next, modify the design of the database by adding a few fields to the form(s) which are used in the test. The extra fields will serve as placeholders for imported data. Fields which need to be added are
• OPTYPE - placeholder for the operation type
• USERNO - for the simulated user number which worked on this document
• NOTESID - the unique ID which identifies this document in the target databse.
• SERVER - the server under test.
• DATABASE - the database under test.
• LOADGEN - Name of the Workload Generator system
• OS: The Operating system of the Workload generator system
• USERNAME: Username of the account using GroupSizr.
• Now go to the File...Import menu in Notes and import the data in LOG.DAT into the database for which you defined a template.
2. From the previous step, we already have the data from the Source. Also, we have this data in a Notes database. Now, we can write agents to compare the "Source data" with the data in the Database under test. The complexity of this part depends on exactly how much and how accurately you need to compare the data. In a simple case, you can just use the NoteIDs to go to a particular note in the destination and compare with the note that is indexed by the specified NoteID.

Conclusions

GroupSizr presents a powerful paradigm to setup, run, view and develop reports for experiments which simulate hundreds of users. It very easily adapts to your test plans to deliver data and results from your experiments which can be used for Capacity Planning, Performance Analysis and Tuning, Regression Testing and Patch Management. Also, you can debug applications against realistic user Workloads and configurations for Reliability and Availability.

If you are developing a mission critical application, you can performance engineer it using GroupSizr. Without it, you can only guess how good your application could be under load.
If you are deploying a mission critical application and tuning it to meet ever changing user workload needs, GroupSizr can not only make your deployment more robust, but also optimize your deployment cycle by providing you with the right testing technology as you incorporate new patches and versions of Application software.