Properties used by GrinderScript.Net

This page contains a summary of all the properties used by GrinderScript.Net. You use these in addition to the normal Grinder properties.

Some tips & tricks before you begin

To start using GrinderScript.Net with Grinder you must specify the assembly containing your load tests in the grinder.script property. Please remember to include the .dll extension, otherwise Grinder will not bind your script to GrinderScript.Net, e.g. grinder.script=GrinderScript.Net.Verifier.dll
Please note that GrinderScript.Net requires that you use the DCR instrumentation engine in Grinder. Make sure the property grinder.dcrinstrumentation=true is present in your grinder.properties file, and everything will be fine.
Remember to use \\ (two backslashes) when you specify a path separator in a property.
The properties with None as the Default value in the table below are mandatory, the rest are optional.
Its recommended that you use an assembly qualified type name for type name properties, to make sure GrinderScript.Net can find and load the type from this symbolic name.
These properties are plain Java properties, so you must specify them using the normal Java property format, see this .properties file description if you're in doubt.
Property names are case sensitive.
If you specify the same property several times the last line wins.
You can use these properties as a starting point for your own grinder.properties file.
The Grinder does not require you to name your grinder.properties file grinder.properties, its just the default name used until you override it. You can select any property file in The Grinder Console, or specify a file name as an option in your Grinder Agent start up script. See The Grinder user documentation for further details.

List of properties

Core properties
You use these properties to control the core functionality of GrinderScript.Net
Property	Description	Default value
grinderscript-dotnet.workerType	This is the type name of the actual class implementing your load test. This is mandatory if you uses GrinderScript.Net's default script engine. The property "grinder.threads" controls how many instances of this type The Grinder will spin up in each worker process. You are free to use another strategy than this property to choose the actual load test type. You do this by implementing your own script engine type and specify it's type name in the "grinderscript-dotnet.scriptEngineType" property, see below.	None
grinderscript-dotnet.scriptEngineType	The Grinder uses a script engine to load the actual worker types that implements your load tests. GrinderScript.Net's default script engine uses the property "grinderscript-dotnet.workerType" to control the actual worker type to load. You can replace it if you want to use your own instantiation strategy, or if you need special initialization of the worker process before the load test starts.	GrinderScript.Net.Core.DefaultScriptEngine, GrinderScript.Net.Core
grinderscript-dotnet.binFolder	By default GrinderScript.Net load assemblies from The Grinder's Worker process active folder. This utilizes The Grinder's ability to automatically distribute all the load test files from the Console machine to all the Load Agent machines. On the other hand this can cause a huge startup overhead if your setup contains a lot of content. If you specify "grinderscript-dotnet.binFolder", GrinderScript.Net will look for assemblies in that folder in addition to The Grinder's Worker process active folder. The worker process's active folder is checked first, then the folder you specify. This property is optional.	None

Properties related to test scenario composition
You can write your load test as long and complex as you like, within the limitation of the .Net framework. But you, as a craftsman, are of cause reluctant to organize your code in such a big ball of mud. You probably like to follow the single responsibility principle and other well established patterns and practices to write reusable and maintainable code in your load tests also. GrinderScript.Net comes with a worker that helps you split your load test into small, well focused classes that you can compose into huge and complex load test scenarios if you need to. You use this worker by setting the property "grinderscript-dotnet.workerType=GrinderScript.Net.Core.Framework.ScenarioWorker, GrinderScript.Net.Core" and compose your load test scenario by using the properties described in this section. Each property prefixed with grinderscript-dotnet.scenarioWorker.n., where n is a positive integer, configures on test worker in your load test scenario.
Property	Description	Default value
grinderscript-dotnet.scenarioWorker.n.typeName	This is the type name of the actual class implementing the n-th load test in the scenario.	None
grinderscript-dotnet.scenarioWorker.n.loadFactor	Positive integer indicating how heavy the n-th worker will be used in the test scenario. Default = 1, so all test workers are weighted equally.	1
grinderscript-dotnet.scenarioWorker.random	Should the scenario run the workers in a random order, or sequential? Default = false (Run the workers sequential)	false
grinderscript-dotnet.scenarioWorker.seed	Seed to use for random selection. If specified each run with the same workers and load factors will run in the same order. Default is [DateTime.Now.Ticks], producing a possible new run combination each time.	[DateTime.Now.Ticks]
grinderscript-dotnet.scenarioWorker.firstElement	In what range should we scan for workers? First element to use. You can adjust this to just use a sub range of test workers in a huge list of possible test workers.	1
grinderscript-dotnet.scenarioWorker.lastElement	In what range should we scan for workers? Last element to use. You can adjust this to just use a sub range of test workers in a huge list of possible test workers. You MUST adjust this if you plan to compose test scenarios with mote than 100 test workers.	100

Properties related to data pool configuration

The default GrinderScript.Net script engine can load and configure data pools from properties. This section describes the properties you use to configure your data pools.

Property

Description

Default value

grinderscript-dotnet.datapoolFactory.n

GrinderScript.Net's default script engine load all data pools specified in "grinderscript-dotnet.datapoolFactory.n" properties, where n is a positive integer. Each property "grinderscript-dotnet.datapoolFactory.n" specifies the name of the data pool to configure. You use this name to reference the data pool in your code. You also substitute the [Poolname] part of each property below with this name when you configure the n-th data pool.

None

grinderscript-dotnet.datapool.[Poolname].valueType

Name of the type of the datapool values returned by this data pool. The IDatapool interface is an open generic type, and you'll bind the open type to your value type to retrieve and use the values in a type safe manner with calls to NextValue().

None

grinderscript-dotnet.datapool.[Poolname].factoryType

Name of the type implementing the data pool factory, that is the class providing the values for this data pool. GrinderScript.Net provides one factory implementation, "GrinderScript.Net.Core.CsvDatapoolValuesFactory`1, GrinderScript.Net.Core". This factory loads data pool values from a csv file. You specify the file name in the property "grinderscript-dotnet.datapool.[Poolname].csvFile", see below. Please note the `1 in the type name. This is used to represent the fact that all data pool value factory types are open generic types, that GrinderScript.Net will close with the valueType when it's instansiated. (And, yes, it's ok if this explanation don't make sense to you, as long as you remember the `1 in the type name.)

None

grinderscript-dotnet.datapool.[Poolname].random

Should the data pool deliver the values in a random order, or in the original order? Default = false (Deliver the values in the original order.)

false

grinderscript-dotnet.datapool.[Poolname].seed

Seed to use for a random data pool. If specified each run with the same data pool configuration will pick values from the data pool in the same order. Default is [DateTime.Now.Ticks], producing a possible new sequence each time.

[DateTime.Now.Ticks]

grinderscript-dotnet.datapool.[Poolname].distributionMode

You can configure GrinderScript.Net to distribute the vaules in the data pool to the load test workers and processes in tree different ways.

ThreadShared	In this mode each load test process sees all the values in the data pool. Inside each process all the load test workers share the values between them. Thus each worker asking for a new value will get a unique value inside this load test process, but they might share the value with other workers in other load test processes in the run.
ThreadUnique	In this mode each load test worker in each load test processes sees its own unique subset of the data pool values. This is usefull when your load test manipulate the state of the data the data pool values binds to, thus leaving the value "uesless" for another worker. You must also use the "grinderscript-dotnet.agentCount" property, see below, if you use this mode with several load test agents.
ThreadComplete	In this mode each load test worker in all processes sees all the values in the data pool.

ThreadShared

grinderscript-dotnet.datapool.[Poolname].circular

Used to control what should happen when all the values in the pool has been used in a worker process. When circular is true (the default) the data pool wraps and start with the first value again. If it's false, an exception will be thrown.

true

grinderscript-dotnet.datapool.[Poolname].csvFile

The name of the csv file with the values used by this data pool. Mandatory for data pools where you use the factory type "GrinderScript.Net.Core.CsvDatapoolValuesFactory`1, GrinderScript.Net.Core"

None

grinderscript-dotnet.datapoolFactory.firstElement

In what range should we scan for data pools? First element to use. You can adjust this to only configure a sub range of data pools in a huge list of possible data pools.

grinderscript-dotnet.datapoolFactory.lastElement

In what range should we scan for data pools? Last element to use. You can adjust this to only configure a sub range of data pools in a huge list of possible data pools. You MUST adjust this if you plan to configure mote than 100 data pools.

100

grinderscript-dotnet.agentCount

How many load test agents are participating in thee load test? You must specify this if you use a data pool with distributionMode=ThreadUnique in a load test run with more than one load test agent. (You should think that The Grinder could provide this value, but we have not found a way to retrieve it from The Grinder yet...)

Properties for running .cs script files directly
Currently you only need to configure your cs script file and set these two properties with these fixed values: grinder.script=GrinderScript.Net.CsScript.dll grinderscript-dotnet.workerType=GrinderScript.Net.CsScript.CsScriptWorker, GrinderScript.Net.CsScript The location of
Property	Description	Default value
grinderscript-dotnet.csScriptWorker.script	The actual .cs script file. The location is relative to the location of the assembly specified in 'grinder.script'	None

Miscellaneous properties
There are some features in GrinderScript.Net that you seldom need to use. These properties control those features.
Property	Description	Default value
grinderscript-dotnet.launchDebugger	It's tricky to start a load test run from within Visual Studio for debugging purposes, since The Grinder Agent spawns the worker processes with a custom built command line. Set this property to true to instruct GrinderScript.Net to call System.Diagnostics.Debugger.Launch() as soon as the bridge is launched into the CLR, so you can debug the test execution from there. The Visual Studio Just-In-Time Debugger window should appear on the agent machine(s) shortly after you start the test run.	false
grinderscript-dotnet.bridgeVerbose	Set this to true if you are experiencing problems when running your load test, and there is no indications about the problem in The Grinder Agent logs or console window. This will cause Jni4Net to log details about the runtime environment to The Grinder Agent process console. Hopefully this information will make it easier to troubleshoot the issue.	false
grinderscript-dotnet.loggerEnabledCacheTtl	GrinderScript.Net's logging is integrated into The Grinder's logs. Normally you do not change the log level configuration during a load test run. GrinderScript.Net can cache the log level information in the CLR, to avoid round trips to the JVM to read these values. This property control how long the log level configuration is cached. A value of -1 (the default) causes the values to be cached for the whole run, 0 indicates no caching at all and all positive integers indicates the cache time to live in milliseconds.	-1
grinderscript-dotnet.verificationWorker.testsPrRun	This property is mainly for internal use in GrinderScript.Net. We use a grinder.properties file with the properties "grinder.script=GrinderScript.Net.Core.dll" and "grinderscript-dotnet.workerType=GrinderScript.Net.Core.Framework.VerificationWorker, GrinderScript.Net.Core" to verify that GrinderScript.Net is working properly in our Grinder installation. This property controls how many separate test calls is performed pr iteration. Playing with this property will give you a feeling about the overhead of calling back and forth between Java and the CLR. When using the default value of 1, each Grinder iteration will just cause one call from the CLR back to the JVM. In this setup the overhead of the initial Grinder call from the JVM to the CLE will have a huge impact on the number of TPS. Setting this to a higher value will reduce this impact and will give you n indication about the maximum load you will be able to generate.	1