Launching dsTest

dsTest can be launched by any user in the devsol user group and it can be launched from any directory that you choose other than the installation directory /usr/local/devsol. The devsol group and one member user account, devsol (default password devsol), are established during installation. Log and results files are placed in the directory from which dsTest was launched and it is therefore a good practice to be consistent in your choice of directory so that you can more easily locate those files.

dsTest may be configured to start automatically upon installation and server restarts. Refer to Running dsTest as a Service.

dsTest is a memory resident application, and will allocate the amount of memory it requires based upon the specified test parameters. Other applications may affect dsTest performance and the number of subscribers specified. It is recommended that dsTest run as the sole application on your server when the tests are being performed to avoid competition for server resources such as memory.

At least 400MB of free memory is required to start dsTest and run simple tests with a minimal number of subscribers.

dsTest checks for compatibility with dsFilter during startup. If dsTest determines that it is incompatible with the installed dsFilter, you may be required to update dsFilter before you can start dsTest.

dsTest checks for license compatibility when it is launched. If the version of your current license is not the same as or greater than the software version, dsTest will fail to launch.

If you have installed a node-locked license, only one instance of dsTest may be running on a platform and it must be running in the native OS (i.e., not in a virtual machine).

If you are operating with a floating license, dsTest will launch in standby mode by default. In this mode it does not check out any resources from the floating license but can dynamically check out the resources required when you load a test configuration. Alternatively, you may check out a level of transactions-per-second (TPS) when dsTest is launched by using the -t option described below, and that TPS will remain checked out until dsTest is terminated. See the Licensing topic for a full discussion on how you can manage your licensed resources.

An instance of dsTest will consume approximately 85% of the available memory when launched unless the -U option is included. If you plan to run more than one instance of dsTest in the native OS you can use this option to divide the platform's memory between dsTest instances as appropriate.

RPM-based systems (e.g., RHEL) enable the OS firewall by default. Both the firewall and Security-Enhanced Linux (SELinux) may block dsTest operations or at the very least prevent you from achieving maximum performance during your test. If your platform is running in a protected environment and you have root privileges you can follow the instructions below; otherwise, consult your IT department.

You can disable the firewall service in RHEL by entering the following commands (using root privileges):

If you do not disable the firewall, you must ensure that the ports that will be used by the protocols involved in your test are open through the firewall as well as the administrative ports used by dsClient and dsTest. Refer to this FAQ for the ports that must be open to allow dsClient and dsTest to communicate.

We also recommend that SELinux be disabled, especially if you are using SCTP. Locate the SELINUX setting and change it to disabled:

After changing either of these configuration items, you must reboot the server for the changes to take effect.

If troubleshooting dsTest issues, you may want to start dsTest with the nohup command. Using the '&' alone doesn't redirect the console output so if there are any standard or error messages, those are displayed on the terminal. nohup will redirect the console output to nohup.out, preserving those messages to aid troubleshooting efforts.

>nohup dsTest ...

You can include the options described below in your launch command at the command prompt, you can include them in a dsTest.opt file placed in the directory from which dsTest is launched, or you can include them in the configuration file used when dsTest is run as a service. Either of the latter two options will ensure that dsTest is consistently launched with the same options. Any options specified on the command line will override those defined in the options file.

n = 0 (false) or 1 (true, default) to indicate if OM intervals should be written to the OM database.

Specifies the path and file name of one or more XML configuration files to be loaded. Configuration files may also be loaded using the dsClient Terminal source command. Configuration files are validated against the schema when they are loaded. If validation fails dsTest will print the error message and then terminate.

Specifies the path and name of the file that contains a list of User Dictionary files to be used.

Specifies the path and name of the file that contains a list of Base Dictionary files to be used.

Provides information regarding the floating (hosted or non-hosted) license resources. This option will not launch dsTest, and can be executed while dsTest is running. Including the date option causes dsTest to print the date and time in its response. For more information, refer to this FAQ.

Specifies dsTest's management IP address - the address dsClient applications, or automation tools, use for XML/TCP communication with dsTest - and is required to be supplied at least once. The value provided is written to /usr/local/devsol/config/ManagementIP and will be retrieved there if omitted in the future.

This address should not be used for test traffic. Each instance of dsTest running on a platform must specify a different management address.

You can optionally specify which port dsTest will use for the high priority XML/TCP socket by appending the port number to the management address. When omitted the default ports will be used.

If the management address is omitted but was never set the following error is displayed: Failed to initialize control interface: No such file or directory Please insure another instance of the application is not already running

Limits the number of interfaces or sockets that can be configured (default is 2000).

Specify the number of measurement database files that will be created/retained (default is 10). -o0 (zero) specifies that no database files are to be created.

Specifies the lowest level of log messages that may be discarded. If log messages are being queued due to the load on the server, this option will prioritize log messages with levels above log level and allow dsTest to re-allocate message buffers if necessary to preserve those messages.

Specifies the base memory ratio (default .05) that determines memory allocation between the memory available for buffers and queues versus the memory available for subscribers and nodes. This option can be useful when DUT response time or network latency requires additional queuing of request or response messages. Increasing the buffer size, however, will result in a corresponding reduction in the capacity of the application.

Specifies the port number used by dsTest's RESTful API. When omitted the default port will be used.

Specifies the port number dsTest will use for the low priority XML/TCP socket, which is used for notifications and commands that do not affect test operations. When omitted the default port will be used.

Indication that more than one instance of dsTest is allowed to be run on the platform (applies to floating license only).

Specifies the level of TPS to be checked out from a floating license by this instance of dsTest. If the TPS currently available in the license is not sufficient dsTest will print an error message and exit.

Specifies the maximum memory available to dsTest rather than allowing the application to determine how much memory is available to it. This option should be used when dsTest is installed on a platform that is running other applications and contention for memory becomes an issue. Limiting the memory available to dsTest may reduce the application's capacity below the limits of your license.

Returns the dsTest version without launching dsTest. This option can be executed without a license.

Initiates a memory access performance test of n bytes. Memory access speed is the primary factor regulating dsTest performance and this option provides the ability to compare the speed of different server platforms. dsTest reports the test result and exits when the test is complete. This option can be executed without a license, making it especially useful when deciding which of your available platforms is best suited to dsTest.