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.

Figure: Think Time

Think Time Options

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

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

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

• Random (Uniform distribution) think time from a 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 thinking the time for the particular pages. To override recorded think time, the following options are available:

• Use recorded think time: When enabled, the 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 by the provided value.

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

Session Pacing

Pacing is related to the rate of speed. Load on the server does not simply depend upon the number of concurrent users, the pace at which a virtual user is generating sessions is also equally responsible for the load on the server. Pacing is a key element in load determination, it is important that the 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 the user accesses the application after some interval. It provides a control for the load to be generated once a number of users are provided. Session pacing is applied after every session. It can also be applied before the first session of the user to randomize the hitting of the application when users are ramped up.

Session pacing is applicable to the FCU scenarios only as in FCU, users created during ramp up and then these users execute the script (called sessions) with a delay between sessions based on the 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.

Figure: Session Pacing Page

Start New Session

This specifies when the next session is started after a VUser completes the 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 the previous session took 10 seconds and user has a pacing time of 15 seconds. In this case, the next session would be started after 5 seconds of completing the last session. This mode tries to keep the average session rate the 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, the next session would be started immediately after completing the previous session.

Introduce delay before the first Session too (By randomized mean pacing time): When enabled, a delay is applied before the start of the 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. Users can also clear/persist the parameter 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 set up inline delay, click the Inline Delay menu item under the Group Based Settings section on Scenario Setting window, the Inline Delay window is displayed.

Figure: Inline Delay Window

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

Figure: Advanced Settings-Inline Delay

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.

Figure: Logs And Reports Window

Enable Virtual User Trace: It is used to trace virtual users to look for errors that occur with certain virtual users. If applied to 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:

Figure: Reporting-Logs and Reports

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 a default value of 1%.
• For debug tests, 100% of sessions will be captured in the drill-down reports. Debug test is a smoke or validation test with the following schedule:
  • Maximum 10 Virtual Users or 100 session/minute rate
  • The maximum duration of 5 minutes or 100 sessions

In a distributed testing (using multiple generators) environment, each generator will check its own schedule for a 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 the test will be classified as a debug test

Tracing

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

Figure: Trace Level- Logs and Reports

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

• No trace enabled (default): When enabled, page dump 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 the 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 fails: 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 to 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: The user can specify how many sessions are to be dumped. The user needs to provide percentages and numbers. It can have the following options.

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

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

In percentage mode, up to 2 decimal values 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. Users can specify different settings for different scenario groups. If for a group settings are not defined, then it takes the same settings as for the default group.

Figure: Logging- Logs and Reports

Logging contains the 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 for 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 levels are enabled
• All logs (standard, extended, and debug) are enabled

Log Destination

This denotes where the logs are stored/displayed. There are the 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.

Figure: Advanced- Logs And Reports

Transaction

In this section, the user can define the 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.

Figure: Transactions( Group Based Settings)

HTTP Setting

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

Users can perform the following settings in this section:

• HTTP Versions
• Authentication
• Caching
• Connection(s) Settings
• Advanced Settings
• Keep Alive Settings
• HTTP Header

Figure: HTTP( Group Based Setting)

HTTP Version

Figure: HTTP Version(HTTP)

Protocol Version: LOAD TEST 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. Is a binary protocol (as opposed to text based HTTP/1.1)
• Auto: Auto mode is there just in case user is not sure about which protocol in there.

Other Options

Enable HTTP Live Streaming (HLS) protocol: LOAD TEST now supports the 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.

• Enable Server Push: It allows a web server to send resources to a web browser, before the browser requests for them. This helps websites load faster. LOAD TEST now supports scripting and testing of Server Push in HTTP/2.
• Max Concurrent Streams from Server: This refers to the 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 the following settings:

Figure: Authentication

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

Figure: Caching(HTTP)

You can specify the following cache settings:

• Enable browser cache 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 the 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 the 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 URL responses in the HTTP cache table. The HTTP cache table/user table is unique for every user. Users 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. The user needs to specify the table name and size.

Connection(s) Settings

This section contains the following settings:

Figure: Connection(s) Settings

User Settings: These options are used to set a number of parallel connections for a 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 the following settings:

Figure: Advanced Settings-HTTP

• Enable Network Cache Stats: If website contents are cached by network caches, it is expected the web page will load faster. This will particularly help in the Net cloud for analyzing network cache performance efficiencies to various load generators located at different geographies. To categorize the request that is served from the network cache, we discover the separate transaction for that at run time by using the provided suffix. For example, if the transaction is started with the name “payload” and the request is served from the network cache, then the transaction name will be “payload_NetCache”.
• Send transaction name in HTTP header: To send the custom header (default is CavTxName) along with the 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 the main and inline URL
• Enable save location header value on any response code: By default, the location header is displayed with a 3xx response code. But sometimes, the location header is displayed with other response codes also and there could be a need to handle the location header. So enabling this check box handles location codes other than the 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 assumes 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. Users can also enable/disable specific header(s) by selecting/clearing the check box.
• Disable Reuse of TCP/IP Address: By selecting this option, the user can disable the reuse of TCP/IP Address. By default, the reuse of TCP/IP Address is disabled.
• Use recorded host in host header: When enabled, Recorded Host is used in the ‘HOST’ header. By default, the mapped/actual host is used in the ‘HOST’ header.
• Fail page if the embedded URL of a page fails: When enabled, the page status is set as ‘failed’ if the 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, the 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 the empty body also: When enabled, if the body is empty then the header will not be passed.
  • Add prefixes and suffixes to the body before calculating MD5 checksum: The user can add any prefix and suffix, such as { } or @ @.

Keep Alive Settings

This section contains the following keep-alive settings:

Figure: Keep Alive Settings

• Keep-Alive Connections: To specify the 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 a single keep-alive connection? By default, unlimited requests can be processed on a keep-alive connection. Users can also specify the range.

HTTP Header

Figure: HTTP Header

We have the following options for this:

• Enable HTTP referrer Header: HTTP referrer identifies the address of the webpage that is linked to the resource being requested.
• Change referer on redirection: This is used to change the referrer in case of redirection
• Send transaction name in the HTTP request header: To send the custom header (default is CavTxName) along with the 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 the main and inline URL.
• Enable save location header value on any response code: By default, the location header is displayed with a 3xx response code. But sometimes, the location header is displayed with other response codes also and there could be a need to handle the location header. So enabling this check box handles location codes other than the 3xx response code.
• Use all header as recorded in flow files: When enabled, all request header(s) is sent with the request. Users can also enable/disable specific header(s) by selecting/clearing the check box.
• Use recorded host in Host Header: When enabled, Recorded Host is used in the ‘HOST’ header. By default, the mapped/actual host is used in the ‘HOST’ header.
• 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, the MD5 checksum HTTP header is added to 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 the empty body also: When enabled, if the body is empty then the header is not passed.
• Add prefixes and suffixes to the body before calculating the MD5 checksum: The user can add any prefix and suffix, such as { } or @ @.

IP Settings

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

• Real users use the 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, the system can run short of IP addresses/port combinations for creating new connections. Ports are limited to 64K and hence having several sources of IPs may be required.

There is a need for NetStorm to support multiple servers’ IP addresses for the 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:

Figure: IP Settings(Group Based Settings)

Setup the 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, the user can specify the source IP share mode and other settings, such as the selection of IP version mode and enable / disabling source IP stats.

Figure: Advance Settings

Source IP Share Mode

IPs from the list can be shared with the virtual users. There are the 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 the 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 the user selects Admin as a 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 the 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 the user selects Admin as the source IP address as there would be only one IP address.

Other Settings

• IP Address Version Mode: The user can specify the version mode either IPv4 or IPv6. If the version mode is not known, the user can select “Auto”. This automatically selects the version mode, which is used by the interface.
• Enable Source IP Stats: When enabled, the 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.

Source IP Selection Mode Select any of the following as per the requirement:

• No servers address checking with client address.

• Server address (actual servers to be hit) need not be a NetOcean address.

• Server address (actual servers to be hit) must be NetOcean address.

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 another 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 the Scenario Setting window, and the Proxy window is displayed.

Figure: Proxy(Group Based Settings)

The proxy settings window has the 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 the user selects this option, the proxy settings which are set for the system are applied. In case the system proxy is already defined, those settings are loaded for any view/update. Else, it appears as in the case of manual proxy configuration. Users can configure system proxy settings and save them. System proxy setting would be configurable only from default scenario settings when the user logs in as Admin. It is applicable to the 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 the 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 a web server using the Secure Sockets Layer (SSL) protocol. SSL is an encrypted protocol that creates a secure connection from one 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 the same proxy server for both protocols: When enabled, the same proxy server for both HTTP and HTTPS protocols is used. All protocols use the same server and port.

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

Figure: Proxy Authentication Credential

Password and Confirm password values are encrypted and verified at the back end. Earlier, a user was not able to perform proxy configurations for a particular test, but now the user can configure a 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.

Figure: SSL( Group Based Settings)

There are following settings under this section:

SSL Certificate Settings

This section is used to perform SSL certificate settings.

Figure: 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

Figure: Cipher Suites

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

Advanced Settings

Figure: Advanced Settings(SSL)

• Average SSL Reuse %: Session reuse is one of the most important mechanisms to improve TLS performance. To avoid a full TLS handshake each time a client requests 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 SSL reuse.
• SSL Clean Close: SSL clean close only. By default, it is disabled.
• SSL Ciphers: It contains a 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.

Figure: Inline Resources

Steps to apply Auto Fetch

1. Go to the Global Settings section
2. Click the Inline Resource menu item
3. Select a group from Add Group option
4. Select the page from the 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.

Figure: Inline 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 a maximum number of counts if its response time is greater than the specified time out.

Figure: Page Reload

• 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 the whole page including the embedded URL. This means to say, if the main and all embedded URL response time is greater than the given timeout then reload the page.

Figure: Add Page Reload

In the above screenshot:

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

Figure: Click Away

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.

Figure: Ramp Down Settings

Ramp down condition can be applied in the following ways:

• Allow current sessions to complete: Ramp-down settings are applied to allow completion of the current session but with the 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 the 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 the current page to complete: Ramp-down settings are applied to allow completion of the current page but with the 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:

Figure: Virtual User

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:

Figure: Advanced(Group Based Settings)

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

Figure: Debug Logging

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.

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.

Figure: Request Body Encryption

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

Figure: Script Parameter

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

This section displays a list of all declared parameter variables used in scripts. Users can initialize the value for the corresponding attribute.

Data Directory

Figure: Data Directory

RTE Settings

Remote Terminal Emulation (RTE) supports the 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 terminals – SSH and Telnet.

Figure: RTE Settings

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.

Figure: JMeter Setting

Key Pointers

• The default value of the 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.