Group Based Settings

Using this section, user can perform group-based settings. User can add group based settings to their scenarios from here. User can apply following type of settings through Group based settings window of Scenario GUI:

• Think Time
• Session Pacing
• Inline Delay
• Logs & Reports
• Transaction
• HTTP
• IP Settings
• Proxy
• SSL
• Inline Resources
• Page Reload
• Click Away
• Ramp Down Settings
• Virtual Users
• Advanced
• Script Parameter
• RTE Settings
• JMeter Settings

Think TimePage

Think Time is the page view time after a page is downloaded. User can apply page think time across all groups, or specified groups, or individual page(s) of a group.

To setup Think Time configuration, click Group Based Settings link on Scenario Setting window and then click Think Time tab. The default window is displayed.

Think Time Options

• No Think Time: When enabled, no think time is applied between pages. 

• Random (Internet type distribution) think time with median of value specified in seconds: The think time is taken randomly in internet type distribution pattern with median of the value specified. For internet type distribution, median is roughly around ¼th of the mean.

• Constant think time of value specified in seconds: When enabled, a provided constant think time is applied.

• Random (Uniform distribution) think time from specified range in seconds: When enabled, a random value is selected from the provided think time range.

• Custom think time returned by C method: When enabled, a custom think time is used as returned by the specified method.

Override Recorded Think Time

This setting overrides the setting of the page think time for the particular pages. To override recorded think time, following options are available:

• Use recorded think time: When enabled, same think time is used as captured in the script recording.

• Multiply recorded think time by some value: When enabled, think time (captured in the script recording) is multiplied with the provided value.

• Use random percentage of recorded think time: When enabled, a random value between the provided minimum and maximum percentage is applied.

Add Group

If user wants to provide think time option to any specific group, then he/she needs to select a group from the Add Group option. Following window is displayed:

User can select any specific page of the script and can apply the above settings for that particular page. The options available are same as above.

Session Pacing

Pacing is related with rate of speed. Load on the server does not simply depend upon the number of concurrent users, pace at which a virtual user is generating session is also equally responsible for the load on the server. Pacing is a key element in load determination, it is important that Pacing configuration for a scenario is realistic.

Session pacing is an interval between two sessions executed by a virtual user. This is used to simulate the real life scenario where user accesses application after some interval. It provides control for the load to be generated once number of users is provided. Session pacing is applied after every session. It can also be applied before first session of the user to randomize hitting of application when users are ramped up.

Session pacing is applicable to FCU scenario only as in FCU, users created during ramp up and then these users execute script (called sessions) with a delay between sessions based on session pacing setting.

In case of FSR, it is not applicable, as in FSR, session rate is fixed. Users are created to generate the target session rate. Once user completes session, user is removed.

After a virtual user has completed executing a test script, it would start executing the next iteration of the session associated with its scenario group. The timing of next iteration of session execution depends upon the pacing configuration of the session.

To setup Session Pacing, click the Session Pacing tab under the Group Based Settings section on Scenario Setting window, the Session Pacing window is displayed.

Start New Session

This specifies when the next session is started after a VUser completes previous session. It can have one of the possible values:

• As soon as the previous session ends: The new session begins as soon as possible after the previous iteration ends. This mode is good for loading the SUT maximally. (This is the Default mode)
• After the previous session ends: The new session starts after the end of previous session. There are following options:
  • With fixed delay: The next session is started after a fixed delay. Specify the delay in seconds.
  • With random (Internet type distribution) average delay: The delay is random average delay of the time specified in seconds.
  • With random (Uniform distribution) delay: The delay is of random but uniform distribution and within the range specified in seconds.

• Once every interval (Provided that the previous session ends by that time else next session starts as soon as previous session ends):
  • At fixed interval: The next session starts after a fixed interval of time specified in seconds.
  • At random (Internet type distribution) average interval: The delay is random average delay of the time specified in seconds.
  • At random (Uniform distribution) interval: The delay is of random but uniform distribution and within the range specified in seconds.

Example: Consider a situation where previous session took 10 seconds and user has pacing time of 15 seconds. In this case, next session would be started after 5 seconds of completing the last session. This mode tries to keep the average session rate same even if the server response time changes. This is more similar to real life situations where the typical session rate (sessions/hours) does not change for an application if the response time is increased. If the last session takes more than pacing time, next session would be started immediately after completing previous session.

Introduce delay before first Session too (By randomized mean pacing time): By enabling this check box, a delay can also be applied before start of first session. This delay is calculated by randomized mean pacing time.

Simulate a new user on each session: By selecting this option, a new user is simulated on each session. Further, there are options, such as always, never, and session failure, to clear user parameters and user cookies.

Add Group

To provide Session Pacing option to any specific group, select a group from the Add Group option. 

Inline Delay

Inline delay is to calculate the interval between loading of two inline objects of a page.  The settings are similar to page think time. To setup inline delay, click the Inline Delay menu item under the Group Based Settings section on Scenario Setting window, the Inline Delay window is displayed.

Inline Delay Options

• No Inline Delay: No time is spent in viewing the inline objects. This is the default option selected. 

• Random (Internet type distribution) inline delay with median of value specified in seconds:The inline delay is taken randomly in internet type distribution pattern with median of the value specified. For internet type distribution, median is roughly around ¼th of the mean.

• Constant inline delay of value specified in seconds: By selecting this option, constant inline delay can be taken for each page. The time needs to be specified in seconds.

• Random (Uniform distribution) inline delay from specified range in seconds: It randomly takes the value of inline delay from the range specified in uniform distribution.

• Custom inline delay returned by C method: Enter the method name to customize the inline delay.

Advanced Setting

User can also specify a range (in seconds) for minimum connection reuse delay.

Logs & Reports

This section is used to configure Logging settings, Tracing settings, and Reporting settings for scenario groups. Each test run is assigned a sequentially generated number. For each test run, a log directory is created by the name TRxxx, where xxx is the test run number under the logs directory. Test run logs directory contains logs. Logs are created for storing record of any test run.

Click the Log & Reports menu item under the Group Based Setting section, a logging window is displayed which contains Logging, Tracing and Reporting sections.

Enable Virtual User Trace: It is used to trace the virtual users to look for errors that occur with certain virtual users and not with others. If applied on a group, this can trace a particular virtual user accessing a particular page. Enable virtual user tracing by selecting this check box. By default, it is selected.

Reporting

Various kinds of reports can be generated for a test run by NetStorm and to enable these reports, user can select various levels of reports.

Report Level

• Summary and Progress Report: The report level includes Summary & Progress reports.
• Summary, Progress Report and runtime graphs are generated (which is default): The report level includes Summary, Progress, Detailed, Failure, Page Breakdown reports.
• Summary, Progress Report, runtime graphs and Drill Down Report is generated: The report level generates .csv files in TR when user uses reporting setting in scenarios. These .csv files import the data into the database. User needs these .csv files to recreate the database. It generates the drill down report into the Report Selection GUI.

Tracing

NetStorm logs important messages. These logs are called traces. NetStorm user just has to enable the traces to see them. Tracing settings are group based. User can specify different settings for different scenario groups. If settings are not defined for a group, then system takes same settings as for default group.

Trace Level: Possible options of trace-level can be:

• No trace enabled (default): When enabled, pagedump option is not displayed in pagedump UI
• Only URL name are enabled: When enabled, only URL information is displayed in page request in pagedump UI
• Only URL request and response files are enabled: When enabled, request and response is displayed in pagedump UI
• URL request, response and parameter substitution are enabled: When enabled, request, response, and parameter information is displayed in pagedump UI
• URL request, response, parameter substitution and page dump are created: When enabled, request, response, parameter information, and page dump is displayed in pagedump UI

Trace Destination: It specifies where the logs are logged. Possible values are:

• Log only to screen: When enabled, logs are displayed on the screen. This is applicable only for “Only URL names are enabled” option in Trace level
• Log to file only: When enabled, logs are saved in a file
• Log to both screen and logs: When enabled, logs are saved in a file and displayed on screen

Trace Session: It specifies the condition when the trace messages are logged. Possible options are:

• Trace complete sessions (default): When enabled, trace information of all executed pages is displayed in pagedump UI
• Trace only fails page/Transaction: When enabled, trace information of all failed pages / transactions is displayed in pagedump UI
• Trace complete session if any page or transaction is fail: When enabled, trace information of all pages / transactions of failed sessions is displayed in pagedump UI
• Trace Page, if header octet stream found in Response: Octet stream refers some binary data in response, such as

  “Content-Type: application/octet-stream”
  Content-Disposition: attachment; filename="picture.png"

  The user is required to save it (for example, picture.png) on the disk. By using this option, a user can save up to 1024 parameters values and save up to 10240 bytes of data

• Include inline URL in request and response: When enabled, inline URL information is displayed in request / response in pagedump UI

Trace Session Limit: This field is for limit option. User can specify how many sessions to be dumped. Provide number as well as percentage. It can have following options.

• All sessions (default): When enabled, trace information of all executed sessions is displayed in pagedump UI
• Specific percentage of sessions: It specifies how much percentage of executed sessions needs to be dumped.
• First specified sessions: It specifies how many executed sessions from the beginning needs to be dumped.

This field can be percentage or some number. It depends upon the limit mode field. If limit field option is percentage, the value is in percentage. If limit field option is in number, the value is just some number. 

In percentage mode, up to 2 decimal value are allowed (0.01 (min) – 100 (max) pct value).

 When the tracing to file option is enabled, messages are logged to docs directory in TRxxx/page_dump/docs in the Test run number and csv file is created for page dump in TRxx/reports/csv/page_dump.csv. Also, these file data can be viewed during running test after the completion of the test run.

Trace Limit: This section is used to configure maximum number of parameters per page and maximum length of the parameter value that can be viewed in page dump.

• Max Trace Entries: Specify the maximum number of parameters per page.
• Max Trace Length: Specify the maximum length of the parameter value that can be viewed in page dump.

Logging

Logging settings control what logs are logged in the test run log. Logged messages have a log level associated with it. Log level specifies the verbosity of the message. Messages with higher log level represent higher level of verbosity. At run time, the log messages are enabled by checking appropriate logging settings. Logging settings are group based. User can specify different settings for different scenario groups. If for a group settings are not defined, then it takes same settings as for default group.

Logging contains following options:

Log Level

Log level specifies up to which level logs are enabled. All messages belonging to log-level and below are enabled. Possible options of log level are:

• No logs enabled
• Only logs logged with Standard Log Level are enabled (default)
• Logs with Standard and Extended log level are enabled
• All logs (standard, extended and debug) are enabled

Log Destination

Destination specifies where the logs are logged. Possible options are:

• Log only to screen (default)
• Log only to log file
• Log to both screen and log file

By default, Standard logs are logged to screen (standard out). All other logs messages are disabled. Logs coming on standard out are redirected to Test Run output file (TRxxx/TestRunOutput.log) if test is run from GUI. When the logging to file option is enabled, messages are logged to TRxxx/log. Where, xxx is the Test run number. Also, these messages can be viewed only after the completion of the test run.

Transaction

In this section, user can define maximum number of page instances allowed in one transaction. To do this, go to Advance Settings and specify the maximum number of pages that are allowed in one transaction. By default, it is 24.

HTTP Setting

To setup HTTP Setting, click the HTTP menu item under the Group Based Settings section on Scenario Setting window, the HTTP Setting window is displayed.

Protocol Version: NetStorm supports the following HTTP versions:

• HTTP/1.1: This widely used protocol runs on the top of TCP/IP suite of protocols. It provides faster delivery of Web pages than the original HTTP and reduces Web traffic. 

• HTTP/2.0: It is a major revision of HTTP. It is a binary protocol (as opposed to text based HTTP/1.1) 

• Auto: Auto mode is used just in case user is not sure about which protocol is there.

Other Options 

Enable HTTP referrer header:  HTTP referrer identifies the address of the webpage that is linked to the resource being requested.

Change referrer on redirection: This is used to change referrer in case of redirection (3xx status code). By default, it is disabled.

Enable HTTP Live Streaming (HLS) protocol: NetStorm also supports recording of a script using Media Streaming (HLS) protocol. HTTP Media Streaming (HLS) is an HTTP-based media streaming communications protocol, used to deliver the media content by breaking the overall stream into a sequence of small HTTP-based files. As the stream is played, the client may select from a number of different alternate streams containing the same material encoded at a variety of data rates, allowing the streaming session to adapt to the available data rate.

User can perform following settings in this section:

• HTTP/2.0 Settings
• Authentication
• Caching
• Connection(s) Settings
• Advanced Settings
• Keep Alive Settings

HTTP/2.0 Settings

This section contains following settings:

Enable Server Push: HTTP/2 Server Push allows a web server to send resources to a web browser, before browser requests for them. This helps websites load faster. NetStorm now supports scripting and testing of Server Push in HTTP/2.

Max Concurrent Streams from Server: This refers to maximum number of connections that can be established in parallel to a particular host.

Initial Window Size: Specify the initial window size. By default, it is 1024 MB.

Maximum Frame Size: Specify the maximum frame size. By default, it is 16 KB.

Header Table Size: Specify the header table size. By default, it is 4 KB.

Authentication

This section contains following settings:

Enable HTTP Authentication using NTLM: NTLM stands for NT LAN Manager. NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product. The NTLM protocol suite is implemented in a Security Support Provider, which combines the LAN Manager authentication protocol, NTLMv1, NTLMv2 and NTLM2 Session protocols in a single package. To enable HTTP Authentication using NTLM, select the NTLM version and other details.

Enable Kerberos Authentication: This is a computer network authentication protocol that works on the basis of ‘tickets’ to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. To enable Kerberos authentication, select this check box.

Caching

This section contains following settings:

Enable browser cache: This is used to enable browser caching for a percent of users (Pct-user 0 to 100 (up to 3 decimal)) with following option:

• No caching across sessions for same user

HTTP cache table size: User needs to define the http cache table size in MB.

Enable master cache table: This is used to enable master cache table.

Connection(s) Settings

This section contains the following settings:

Here, user can specify maximum connections (server, proxy, and user) per virtual user setting. For browser settings, it is set by default

Advanced Settings

This section contains following settings:

Enable Network Cache Stats: Network caching is the technique of keeping frequently accessed information in a location close to the requester. By selecting this check box, user can enable the network cache statistics. It is disabled by default.

Enable end transaction based on NetCache hit: This is used to end the transaction with the _Netcache suffix. User can also provide other suffix to be added in transaction.

Enable send transaction name in http header: This is send transaction name into request as HTTP request header.  After enabling this, the innermost transaction name is provided into http request.

Enable save location header value on any response code: By default, location header is displayed with 3xx response code. But sometimes, location header is displayed with other response codes also and there could be a need to handle location header. So enabling this check box handles location code other than 3xx response code.

Consider Error Codes – 1xx, 2xx, and 3xx as OK: If there is any error generated with error codes 1xx, 2xx and 3xx then NetStorm assume that the request is successful. This is enabled by default.

Use all headers as recorded in flow files: When enabled, recorded headers is used to send the request. If this check box is not enabled, then NS use them depending upon the % given in user definition file.

Disable Reuse of TCP/IP Address: By selecting this option, user can disable the reuse of TCP/IP Address. By default, reuse of TCP/IP Address is disabled.

Use recorded host in host header: By selecting this, Recorded Host is used in ‘HOST’ header. By default, mapped host is used in the ‘HOST’ header.

Fail page if embedded URL of a page fails: By selecting this option, the page fails if embedded URL of a page fails.

Add MD5 checksum HTTP header in the request based on the body of the HTTP request: An MD5 checksum is a 32-character hexadecimal number that is computed on a file. When enabled, MD5 checksum HTTP header is added in the request based on the body of the HTTP request.

• Header Name: Specify the name of the header for which the checksum is to be calculated.
• Add Header in case of empty body also: When enabled, if body is empty then header will not be passed.
• Add prefix and suffix to the body before calculating MD5 checksum: User can add any prefix and suffix, such as { } or @ @.

Keep Alive Settings

This section contains the following keep alive settings:

IP Settings

There is a need for NetStorm to support multiple sources IP addresses for following reasons:

1. Real users use different source IP addresses and hence to emulate the real-world scenarios, NetStorm should be able to generate virtual users with different source IP addresses.

2. When NetStorm generates a very high connection rate, system can run short of IP addresses/ports combinations for creating new connections. Ports are limited to 64K and hence having several sources IPs may be required.

There is a need for NetStorm to support multiple servers IP addresses for following reasons:

1. Real servers use different IP addresses and hence, to emulate the real-world scenarios, NetStorm should be able to connect to different servers with different server IP addresses.
2. When NetStorm generates a very high connection rate, system can run short of IP addresses/ports combinations for creating new connections on server side. Ports are limited to 64K and hence having several destination IPs may be required.

To setup IP configuration, click Group Based Settings link on Scenario Setting window and then click IP Settings tab. The following window is displayed:

Setup following configuration settings:

Source IP Selection Settings

This section provides different options for selecting the source IP. Select any one option from the list of available options:

• Use only Admin IP address: Only the Admin IP address is used as source IP for load generation while running a test in NetStorm.
• Use all Load Interface IP addresses: All the Secondary IPs listed within the Primary (Admin) IP are used for load generation.
• Use specific Load Interface IP addresses: The specified number of load interface IP addresses are captured from top within the Secondary IPs list. For example, if there are 50 IPs in the secondary IPs list and user has mentioned to use only 10 IPs, then top 10 IPs will be used for load generation and rest will be ignored.
• Use IP Addresses from the specified file: The IPs specified in a file can be used for IP spoofing. User needs to store the IPs in a file and can use it by using the Browse button.
• Use following IP Addresses: User needs to select the IP address list from the drop-down and provide the Start IP address and Number of IP addresses to be used. Make sure IPs should belong to same interface and number of IPs to be used should be within the range of IPs. For example, in IP address list, if Start IP is 199.99.95.1 and Max IPs are 10, then user can specify the Start IP as 199.99.95.1 and number of IP addresses as 1 to 10. Specifying number beyond 10 will not be allowed in this case.

Advance Settings

This section contains some advance level settings based on the source IP selection. Here, user can specify the source IP share mode and other settings, such as selection of IP version mode and enabling / disabling source IP stats.

Source IP Share Mode

IPs from the list can be shared within the virtual users. There are following options used for IP sharing:

• All virtual users share a pool of IP addresses: All the virtual users will share the IPs from the pool of IP addresses. Suppose there are 100 virtual users and listed IPs are 10, then all the 100 virtual users will share all the listed IPs for load generation. This option is not available if user selects Admin as source IP address as there would be only one IP address.
• All virtual users get a unique IP address: No virtual users will share the IPs from the pool, a unique ID is assigned to them instead. Suppose there are 100 virtual users and listed IPs are 10, then those 10 virtual users can use the unique 10 IPs out of 100 listed IPs. This option is not available if user selects Admin as source IP address as there would be only one IP address.

Other Settings

• IP Address Version Mode: User can specify the version mode either IPv4 or IPv6. If version mode is not known, user can select “Auto”. This automatically selects the version mode, which is used by the interface.
• Enable Source IP Stats: When enabled, user can see data distribution in the graph, such as how much load is generated from each IP, how many virtual users used that IP, and so on.

Note:

There is a scenario that multiple scripts are using a single assigned IP. In order to get the correct analysis, all of these scripts are grouped under a single request group.

Proxy

A proxy server is a server that acts as an intermediary for requests from clients seeking resources from other servers. A client connects to the proxy server, requesting some service, such as a file, connection, web page, or other resource available from a different server and the proxy server evaluates the request as a way to simplify and control its complexity.

Click the Proxy menu item under Group Based Settings section on Scenario Setting window, the Proxy window is displayed.

Proxy settings window has following controls to configure proxies to access web servers:

No proxy: By selecting this option, no proxy is applied to access the web server. This is the default option.

Use system proxy settings: If user selects this option, the proxy settings which are set for the system is applied. In case system proxy is already defined, those settings are loaded for any view/update. Else, it appears as in case of manual proxy configuration. User can configure system proxy settings and save them. System proxy setting would be configurable only from default scenario settings when user login as Admin. It is applicable on user profile.

Use manual proxy settings: In manual proxy settings, set up the proxy manually.

The Manual proxy section contains the following options:

Manual proxy configurations

• HTTP Proxy: An HTTP proxy is a category of network setting that can be configured in network (or Internet) accessing applications. Specify the HTTP proxy in the following format: http://ip:port. Port number ranges from 1 to 65535. By default, it is 80. 

• SSL Proxy: It routes traffic from a client to web server using the Secure Sockets Layer (SSL) protocol. SSL is an encrypted protocol that creates a secure connection from a client to another client or server. Specify the SSL proxy in the following format: https://ip:port

Port number ranges from 1 to 65535. By default, it is 443.

To have the same proxy server for both HTTP and HTTPs protocols, select the Use same proxy server for both protocols check box. All protocols are using same server and port for all the protocols.

• Exceptions: Exceptions option gets enabled in case Manual proxy configuration check box is selected. To bypass proxy server for local address, user first needs to specify the local address for example, 168.1.0/24 in the No Proxy for text box then needs to select the Bypass proxy server for local address check box.

• Proxy authentication credential: User’s credentials are verified here. If user selects the Proxy authentication credential check box, the following options are displayed. Enter the User Name, Password and Confirm Password.

Password and Confirm password values are encrypted and are verified at the back end.Earlier, a user was not able to perform proxy configurations for a particular test, but now user can configure proxy for a particular test and access proxy enabled environment / website.

SSL

Secure Sockets Layer (SSL) is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral.

There are following settings under this section:

SSL Certificate Settings

This section is used to perform SSL certificate settings.

• Select the SSL certificate file or upload it from the system
• Select the SSL Key file from the drop-down list.

Cipher Suites

Select the available SSL ciphers from the left and move to selected SSL ciphers or vice versa by using the arrow buttons. User can search for the SSL ciphers too.

Advanced Settings

Average SSL Reuse %: Percentage of SSL sessions to be reused. By default, it is 100.

SSL Clean Close: SSL clean close only. By default, it is disabled.

SSL Ciphers: It contains list of certificates, these certificated can be added/removed using the arrow buttons.

Set TLS SNI (Server Name Indication) extension in the ClientHello message: This allows a server to present multiple certificates on the same IP address and TCP Port number and hence allows multiple secure websites to be served by the same IP address. SNI is used at the time of handshake.

Inline Resources

NetStorm fetches URL based on the recorded scripts. But many web applications have dynamic contents which changes based on the time, place and other factors. Also, contents may change from release to release. So, to do realistic testing and to avoid reordering of script with every release, Auto Fetching of embedded objects is required. So, the concept of auto fetch is used to fetch embedded URLs from real site.

Fetch option: It specifies fetch option of the session:

• Fetch Every time

• Disable Auto Fetch

To setup Auto Fetch, click the Auto Fetch menu item under the Group Based Settings section on Scenario Setting window, the Auto Fetch window is displayed.

Steps to apply Auto Fetch

1. Go to Global Settings section
2. Click Inline Resource menu item
3. Select a group from Add Group option
4. Select page from Page Name drop down menu
5. Select fetch option
6. Click Add button

Inline Pattern

It is used to define a pattern to include/exclude in the response generated by the server. To fetch only main page objects excluding inline images, js, css etc. select the Get Only Main Page Objects (Do not fetch inline images, js, css etc) check box.

Domain

• Inline Include Domain Pattern: Specify the domain pattern that needs to be included while hitting the inline URL. Domain value can be a regular expression like *.cavisson.com.
• Inline Exclude Domain Pattern: Specify the domain pattern that needs to be excluded while hitting the inline URL. Domain value can be a regular expression like *.cavisson.com.

URL

• Inline Include Url Pattern: Specify the URL pattern that need to be included while hitting the inline URL. Url value can be a regular expression like *.jsp.
• Inline Exclude Url Pattern: Specify the URL pattern that need to be excluded while hitting the inline URL. Url value can be a regular expression like *.jsp.

Page Reload

Page Reload means to download the same web page again, which is currently on screen, in case if it changes at the server side since it was last downloaded. User can stop loading of the current page after the timeout and loading same page again. Click the Page Reload menu item under the Group Based Setting section, the Page Reload window is displayed.

• A page has to be reloaded if its response time is greater than given timeout in milliseconds.
• Reload can be attempted at random number between provided minimum and maximum range.
  • If response time is found less than given timeout, it means that the page is reloaded successfully
  • If all the attempts are completed, then it has to wait for normal execution of a page
• There are 3 option to reload a page:
  • First, given timeout is only for main URL of a page. Means to say, if main URL response time is greater than given timeout then reload the page. Currently, the timeout is allowed only for main URLs.
  • Second, given timeout is given for each URL (either it is main or embedded). In this case, page reload can be done in following way:
• If main URL response time is greater than given timeout, reload the page
• If embedded URL response time is greater than given timeout, reload the embedded or main URL
• Third, Timeout is given for whole page including embedded URL. Means to say, if main and all embedded URL response time is greater than given timeout then reload the page.

In the above screen shot:

Group Name: Group name can be ALL and Page ALL. For a group, Page can be ALL.

Page: The page which is to be reloaded. User can select all pages also.

Min & Max Reloads: A random number between minimum & maximum, which is used to get reload attempt

Timeout in milliseconds: Timeout to decide a page is reloaded or not.

Click Away

Click Away is done to leave the current sequence of page execution and redirect current page to a different page. Next page can be -1 to indicate end of script.

Click the Click Away menu item under the Group Based Setting section, the Click Away window is displayed.

In the above screen shot:

Group Name: Group name can be ALL and Page ALL. For a group, Page can be ALL

Page: Page index from where to click away. (Must be a valid page index)

Next page: Page which has to execute on Page Click Away. (Only -1 can be given for Simple Scenario)

Percentage: Percentage is how many (%) pages is to be clicked away

Time in Seconds: Timeout for click away

Call check page or not:  Check Page should be called or not <0/1>

Transaction Status: This field defines the status of transaction either Success or ClickAway

Note:

• Percentage for the “Click Away” a page if Main URL download time is greater than click away time given.
• Open transaction needs to be closed with Click Away if clicking away to the exit page (i.e. -1).
• User has to be very careful if he/she is using click away & transaction.
• It may be possible that a transaction is started on page 3 & closed on page 5, but user clicked away a page 2 → 4. In that case, transaction is not started but configured to end. Some warning message is displayed to console.
• If both Reload and Click Away is given, checks Reload first, then Click Away.
• If RunLogic is given & Click Away is also given, then next page is -1 (End of script).
• Page status is set to ClickAway in report if ClickAway condition is matched.
• Open transaction needs to be closed with Click Away if clicking away to the exit page (i.e. -1)

Ramp Down Settings

It defines various methods in which virtual users are ramped down. Click the Ramp Down Settings tab under the Global Settings section on Scenario Setting window, the Ramp Down Settings window is displayed.

Ramp down condition can be applied in following ways:

• Allow current sessions to complete: Ramp down settings are applied to allow completion of current session but with following conditions:
  • Use normal Think Times: In this case, the think time already specified for each page is used and complete the session.
  • Disable all future Think Times: In this case, all the future think times are disabled, all pages are executed and session is completed.
  • Hasten completion by disregarding all Think Times: In this case, the current session is completed in accelerated mode by ignoring all the think times.
  • Hasten completion by disregarding all Think Times and use idle time: In this case also, the current session is completed in accelerated mode by ignoring all the think times. Specify an idle time in seconds. By default, it is 3 seconds.

• Allow current page to complete: Ramp down settings are applied to allow completion of current page but with following conditions:
  • User normal idle time: In this case, the page completion takes the normal idle time.
  • Hasten completion by using idle time: In this case, the page completion is done in accelerated mode by using an idle time specified by the user.

• Stop Immediately: The current session stops immediately.

Virtual User

There are following settings under this sections:

Run Script Mode: This is used to run script mode for Legacy and User Context. In case of user context, specify the stack size and select the check box to free the cache after session completes.

Advanced

There are following settings under this section:

HTTP No Activity Time Out: This section is to set the time out for the idle connection. If user has sent the request but could not get the response in specified time, then request is Timed out.

Number of Retries on connection, SSL or request failure: This section is to the provide the number of retries a VUser can do when there is a connection failure, SSL failure, or request failure.

Perform no validation on response: NetStorm performs some validations (size of response) on response.  By enabling this, NetStorm do not perform any validation on response.

Java Script: This is to enable JAVA type scripts.

After an old user completes a session, user connection remains open: This section is to provide the time when user has completed session but needs to wait for some before closing all his connections.

URL Idle time: This is to set the URL idle timeout in case of RMI protocol.

Perform DNS Lookup before making connection: NetStorm establishes connections on provided host but does not resolve the host on every request. In NetCloud, we need to resolve host on every request. So by enabling this, NetStorm resolves the host for every request (in single session).

Continue Session in Page Error

To allow that session should be continued when there is an error on page occurred, select the Continue Session on Page Error check box.

Debug Logging

There are following sections under this:

Debug level is used to specify what level of logs user wants to enable for logging. The value of the debug level ranges from 0 to 4.

• 0 – No debug logs enabled (Default)
• 1 – Level 1 debug logs enabled
• 2 – Level 2 debug logs enabled
• 3 – Level 3 debug logs enabled
• 4 – Level 4 debug logs enabled

Module Masks

Since NetStorm is having different modules, so for each module, there should be a mask specifying the particular module. If user selects the Select All Module Masks checkbox, all module masks are enabled.

The value of the module mask passed with the “MODULEMASK” setting in the scenario file. User already has some module mask for some modules of NetStorm. But there should be a particular modular mask for each module.

Table 4: Modular Mask for Modules

NI* – Not Implemented Yet

Request Body Encryption

Encryption, is the process of changing information in such a way as to make it unreadable by anyone except those possessing special knowledge (usually referred to as a “key”) that allows them to change the information back to its original, readable form.

Encryption is important because it allows you to securely protect data that you don’t want anyone else to have access to.

There are following configurations within this section:

• Enable Encryption of the Request Body: Upon selecting this checkbox, encryption of the request body is enabled.
• Encryption Algorithm: Select the encryption algorithm from the list. There are following options:
  • AES-128-CBC
  • AES-128-CTR
  • AES-192-CBC
  • AES-192-CTR
  • AES-256-CBC
  • AES-256-CTR

• After Encryption, Encode the Encrypted body in Base64: Upon selecting this check box, the encryption body is encrypted in Base64 post encryption.
• Encryption Key: An encryption key is a random string of bits created explicitly for scrambling and unscrambling data. Encryption keys are designed with algorithms intended to ensure that every key is unpredictable and unique. Specify the encryption key within the text area provided.
• Encryption Initialization Vector (IVec): An initialization vector (IV) is an arbitrary number that can be used along with a secret key for data encryption. This number, also called a nonce, is employed only one time in any session.
• Key/IVec is Base64 encoded: If the encryption key / IVec is base 64, select this check box.

Here, we are providing an example to illustrate this functionality.

For Enabling Body Encryption in Scenario

Upon saving the details, a confirmation message is displayed.

For Enabling Body Encryption in Script:

The output in request and response:

For Enabling Body Encryption in C API:

Output in progress report as:

Script Parameter

Using this section, user can specify the attribute name and values used in a script.

When a user applies multiple scripts in a test. If some scripts are parameterized and some are not, and user wants to apply same parameters in all the scripts in a group, then the user can implement this by clicking the Default button

RTE Settings

Remote Terminal Emulation (RTE) supports emulation of users who submit input to, and receive output from, character-based applications.

For Example, suppose that you have a server that maintains customer information for a maintenance company. Each time a field service representative makes a repair, he accesses the server database by modem using a terminal emulator. The service representative accesses information about the customer and then records the details of the repair that he performs.

An RTE Vuser types character input into a terminal emulator, submits the data to a server, and then waits for the server to respond. NetStorm supports two protocols for connection on remote terminal – SSH and Telnet.

JMeter Settings

To run JMeter, a user requires heap size. In this section, the user can set minimum and maximum heap sizes for running JMeter type scripts. This option is visible to the user only when JMeter is installed on the machine.

Key Pointers

• Default value of Min Heap Size is 512 MB and Max Heap Size is 512 MB
• Min Heap Size cannot be less than 512 MB.
• Max Heap Size cannot be less than Min Heap Size.
• Cannot insert alphabets and negative values in Min and Max Heap Size.