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 Time

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: When enabled, no session pacing is applied. The new session begins as soon as possible after the previous iteration ends.
  • After the previous session ends: When enabled, the new session starts after the end of previous session. There are following options:
    • With fixed delay: The next session is started after the provided value for fixed delay.
    • With random (Internet type distribution) average delay: The next session is started after a random average delay of the provided time.
    • With random (Uniform distribution) delay: The next session is started after a random delay of the time range specified.
  • Once every interval (Provided that the previous session ends by that time else next session starts as soon as previous session ends): When enabled, if a session is completed within the specified time, then next session will wait for the remaining time. If the first session exceeds the specified time, next session will be started as soon as previous session ended.

There are following options:

    • With fixed delay: The next session is started after the provided value for fixed delay.
    • With random (Internet type distribution) average delay: The next session is started after a random average delay of the provided time.
    • With random (Uniform distribution) delay: The next session is started after a random delay of the time range specified.

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): When enabled, a delay is applied before start of first session. This delay is calculated by randomized mean pacing time.

Simulate a new user on each session:When enabled, a new user is simulated for each iteration of a session. User can also clear/persist the parameters settings after completion of the session.

Inline Delay

It is the delay applied between two consecutive inline URLs while sending the request. 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: When enabled, no inline delay is applied between inline objects. 
  • 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.
    • Add additional delay with specified limit: This mode is used to add additional delay in case the internet median inline delay is minimal.
    • Limit Delay Range: Here, user needs to define the range for the inline delay. If the inline delay is within this range, then actual + additional delay is applied. If the inline delay (actual + additional) is less than the minimum value assigned, then minimum value is considered. If the inline delay (actual+ additional) is more than the maximum value specified, then maximum value is considered.
  • Constant inline delay of value specified in seconds: When enabled, a provided constant inline delay is applied.
  • Random (Uniform distribution) inline delay from specified range in seconds: When enabled, a random value is selected from the provided inline delay range.
  • Custom inline delay returned by C method: When enabled, a custom think time is used as returned by the specified method.

Advanced Setting

Specify the range to apply delay while reusing the connection. (To apply some block time).

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. If applied on a group, this can trace a particular virtual user accessing a particular page.

Reporting

In the Reporting section, you can specify how much percentage of DDR records need to be logged in the database:

Enable drill down reports (diagnostics) for  % of sessions

In this field, you can specify the percentage of sessions for which data will be captured. By default, the value of this field is set to 1%.

  • Value can be specified in the range of 1% to 10%. If configured outside this range, Netstorm will set and update this value to 1% by giving an appropriate message.
  • If this field is not configured, it will be considered with default value as 1%.
  • For debug tests, 100% sessions will be captured in the drill down reports. Debug test is a smoke or validation test with following schedule:
    • Maximum 10 Virtual Users or 100 session/minute rate
    • Maximum duration of 5 minutes or 100 sessions

In a distributed testing (using multiple generators) environment, each generator will check its own schedule for decision on Debug test. For example, if you are using 10 generators with total VUsers of 100, then each generator will be running 10 VUsers and test will be classified as a debug test

Tracing

Tracing are the important logs, such as request, response, response body, parameterization information showing in pagedump UI. Tracing is having following parameters:

Trace Level:This defines the level of the logs displayed in pagedump UI.

  • No trace enabled (default): When enabled, pagedump option is not displayed in pagedump UI
  • Only URL names are enabled: When enabled, only URL information is displayed in page request in pagedump UI
  • Only request and response are enabled: When enabled, request and response is displayed in pagedump UI
  • Only request, response and parameter substitution are enabled: When enabled, request, response, and parameter information is displayed in pagedump UI
  • 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 file: 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: User can specify how many sessions to be dumped. User needs to provide percentage and numbers. 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. 

 NoteIn 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. 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.

Log Level: Logs are categorized into the following:

  • Standard logs: The standard log sends a subset of functions and messages sent during script execution to a log. The subset depends on the Vuser type.
  • Extended logs: Extended log sends a detailed script execution messages to the output log.
  • Debug logs: A debug log records database operations, system processes, and errors that occur when executing a transaction or running tests.

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: Using this option, no logs except RTG files will be created.
  • 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

This denotes where the logs are stored/displayed. There are following options:

  • Log only to screen (default): When enabled, logs are displayed on the screen.
  • Log only to file: When enabled, logs are saved in a file.
  • Log to both screen and file: When enabled, logs are saved in a file as well as displayed on screen.

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.

Advanced

Show runtime progress of runlogic: When enabled, user can see the flow of execution of script. This displays information, such as actual Vs expected PVS of individual flow or overall in “View” menu of Web Dashboard UI.

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. When enabled, HTTP live streaming in implemented with the specified bandwidth.

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: This uses a secure challenge/response mechanism that prevents password capture or replay attacks over HTTP. However, the authentication is per connection and will only work with HTTP/1.1 persistent connections. For this reason, it may not work through all HTTP proxies and can introduce large numbers of network roundtrips if connections are regularly closed by the web server. When enabled, HTTP authentication is implemented using the selected version of NTLM (NTLMv1, NTLM2, or NTLMv2).
  • Enable Kerberos Authentication: SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) is a GSSAPI “pseudo mechanism” that is used to negotiate one of a number of possible real mechanisms. SPNEGO’s most visible use is in Microsoft’s HTTP Negotiate authentication extension. The negotiable sub-mechanisms include NTLM and Kerberos supported by Active Directory. At present HttpClient only supports the Kerberos sub-mechanism. When enabled, kerberos authentication is implemented.

Caching

Using the Caching options, you can enable browser cache, refresh cached data, and define the size of your cache table. Expand the Caching section to display the settings:

 

You can specify the following cache settings:

  • Enable browser cache for: This option is used to enable HTTP caching for Vusers. Specify the percentage of total users for which HTTP caching needs to be enabled.
  • No caching across sessions for same user: If you enable this option, HTTP caching will take place within the session for the same user. When disabled, HTTP caching will take place across the sessions for same user.
  • Enable client freshness: Enable this option to ensure that the cached data is fresh.
  • HTTP cache table: Enable this option to save the caching related headers and main URLs responses in the HTTP cache table. The HTTP cache table/user table is unique for every user. User can change the size of this table.
  • Master cache table: Enable this option to save the responses of embedded URLs in the master cache table. The master table is shared among all the users. User needs to specify the table name and size..

Connection(s) Settings

This section contains the following settings:

User Settings: These options are used to set number of parallel connections for user at a time.

  • Max Con Per Server
  • Max Con Per Proxy
  • Max Con Per User

Browser Settings: All options are disabled with this settings.

Advanced Settings

This section contains following settings:

  • Enable Network Cache Stats:If a website contents are cached by network caches, it is expected the web page will load faster. This will particularly help in Netcloud for analysing network cache performance efficiencies to various load generators located at different geographies. To categorise the request that is served from network cache, we discover the separate transaction for that at run time by using the provided suffix. For example, if transaction is started with name “payload” and request is served from network cache, then transaction name will be “payload_NetCache”.
  • Send transaction name in http header:To send the custom header (default is CavTxName) along with transaction name as a value in the request header. There are two options:
    • To send the header for the main URL only
    • To send the header for main and inline URL
  • 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 Success: 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, all request header(s) is sent with the request. User can also enable/disable specific header(s) by selecting/clearing the check box.
  • 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: When enabled, Recorded Host is used in ‘HOST’ header. By default, mapped/actual host is used in the ‘HOST’ header.
  • Fail page if embedded URL of a page fails: When enabled, the page status is set as ‘failed’ 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:

  • Keep Alive Connections: To specify percentage of keep alive connections per virtual user.
  • Keep Alive Timeout: To specify the keep alive time out for idle TCP connection.
  • Average Keep Alive Requests Per Connection: How many requests can be processed on single keep alive connection. By default unlimited requests can be processed on keep alive connection. User can also specify the range.

IP Settings

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

  • 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.
  • 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:

  • 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.
  • 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: When enabled, no proxy is required to access the web server.
  • 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 and Port: 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. 
  • SSL Proxy and Port: 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.
  • Use same proxy server for both protocols: When enabled, same proxy server for both HTTP and HTTPs protocols is used. All protocols use same server and port.
 NoteTo 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” option 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. For multiple IPs, use semicolon. Example: 67.218.96.155;10.208.30.4;www.cavisson.com.
  • Proxy authentication credential: This is required for user authentication to access proxy server. When enabled, user needs to provide the User Name and Password.

 54

 NotePassword 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. SSL is used to provide communication security over a network.

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 %: Session reuse is one of the most important mechanism to improve TLS performance. To avoid a full TLS handshake each time a client request a resource, it is possible for the client to request an abbreviated handshake, saving a complete round-trip and avoiding the costliest part of the full TLS handshake. Specify the percentage of users for enabling the SSL reuse.
  • 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: Server Name Indication (SNI) is an extension to the TLS (Transport Layer Security) by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process.
  • Selecting/Removing SSL Ciphers: A cipher suite is a set of algorithms that help secure a network connection that uses Transport Layer Security (TLS) or Secure Socket Layer (SSL). User can add/remove ciphers as per need.

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.

  • Do not fetch inline resources(images, js, css etc): When enabled, no dynamic inline URLs are captured in the network. It captures only the main URL.
  • Fetch Recorded Inline resources: When enabled, only dynamic inline resources specified in the script are captured.
  • Fetch inline resources based on main URL response: When enabled, all dynamic inline resources based on main URL’s response are captured.

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

Inline Pattern: It is used to capture specified inline resources based on domain / URL pattern.

Domain

  • Include Inline Resources for specified domain: It allows capturing of all inline resources of the specified domain pattern only, rest will be discarded.
  • Exclude Inline Resources for specified domain: It allows capturing of all inline resources except the specified domain pattern.

URL

  • Include Inline Resources for specified URL Pattern: It allows capturing of all inline resources of the specified URL pattern only, rest will be discarded.
  • Exclude Inline Resources for specified URL Pattern: It allows capturing of all inline resources except the specified URL pattern.

Page Reload

To reload the page again and again up to maximum number of count if its response time is greater than the specified time out.

  • 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: When enabled, the page completion takes the normal idle time.
    • Use specified idle time: In this case, the page completion is done in accelerated mode by using an idle time specified by the user.
  • Stop Immediately: When enabled, the current session stops immediately without any delay.

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.

There are two modes:

  • User Context: If the script has C code, it is run in this mode.
  • Thread Per User: It is a collection of Virtual users where each VUser is considered as a thread. It is used for ramping up/ramping down users as specified in scenario when script is run in thread mode. User need to configure settings for Thread pool in Global Settings -> Advanced -> Advanced Settings

Stack Size: The stacksize attribute shall define the minimum stack size (in bytes) allocated for the created threads stack.

Free Stack after session: When enabled, it clears stack size after every session.

Advanced

There are following settings under this section:

  • HTTP No Activity Time Out:This is used to set the timeout 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 used for execution of JavaScript.
    • Disabled: JavaScript is not executed (default)
    • Enabled: JavaScript is executed but parameters are not applied on the DOM after JavaScript is executed. Parameters will continue to be applied in page source. Further, user has two options: Save Javascript enabled URL responses and Save all enabled URL responses.
    • Use Updated DOM for Parameters: JavaScript is executed and parameters are applied on the DOM after JavaScript is executed. Further, user has two options: Save Javascript enabled URL responses and Save all enabled URL responses.
  • After an old user completes a session, user connection remains open: Provide the time when user has completed a session but needs to wait for some time before closing all the connections.
  • URL Idle time: This is to set the URL idle timeout in case of RMI protocol.
  • Perform DNS Lookup before making connection: This functionality is used to enable DNS lookup at the time of establishing connection.

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:

63

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.

SR MODULEMASKDescription
1MM_HTTP1Debug logging of HTTP request and responses
2MM_POLL4Debug logging of epoll event
3MM_CON8Debug logging of connection make and break
4 MM_TESTCASE16Debug logging of test case related logs such as for goal based scenario
5 MM_VARS32Debug logging of all variables
6MM_TRANS64Debug logging of Transaction Parsing
7Combined in MM_TRANS128Debug logging of Transaction Execution
8MM_RUNLOGIC256Debug logging of RunLogic
9MM_MESSAGES512Debug logging of Message communication between master to client and parent to childs
10MM_REPORTING1024Debug logging of report modules (applicable for summary.html only presently)
 
// The MASKS for below MODULES should also be there.
11MM_GDF2048Debug logging of GDF
12MM_OAAM4096Oracle Authentication and Authorization Module
13MM_COOKIES8192Debug logging of Cookies
14MM_IPMGMT16384Debug logging of IP Management, Source IP, Server IP selection.
15MM_SOCKETS32768Debug logging of Socket communication, Cav Modem related code
16MM_LOGGING65536Debug logging of logging
17MM_API131072Debug logging of API,s
18MM_SCHEDULE262144Debug logging of test phases (schedule) RAMPUP_MODE, RAMPUP_RATE, RAMPDOWN, WARMUP, Run Phase, think time, session pacing
19MM_ETHERNET524288Debug logging of Ethernet packet send and receive
20MM_HASHCODE1048576Debug logging of creation of hash-code
21MM_SSL2097152Debug logging of SSL module
22MM_MON4194304Linmon/Tcpmon/Server Stats/Custom Monitor
23MM_WAN8388608Code related to WAN simulation
24MM_CHILD16777216Child
25MM_PARENT33554432Parent/master

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

This feature is used when user wants to overwrite the value of declare parameters.

Example: If a script having a declare parameter “Var1” and user wants to overwrite its value from the scenario, then user can assign value to that variable in UI.

This section displays a list of all declare parameter variables used in scripts. User can initialized the value for the corresponding attribute.

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.