Frameworks

By default, NeoLoad provides a simplified User Path, based partly on the detected framework and partly on the type of Push application.

AMF polling

After the recording, a User Path using AMF polling is displayed as follows.

Note: AMF polling requests are identified as having a name with the POLL_XXX format.

Once processed by the NeoLoad Post-recording wizard, the User Path is modified as follows.

NeoLoad has made the following noticeable changes:

  • All the AMF polling requests have been grouped into a single polling request (POLL for example). This request has been placed in a loop (polling_while for example), which continues to loop until the NL-stopPolling variable generated by NeoLoad becomes true. Lastly, the loop itself has been placed in a secondary execution thread using a fork action (push_fork for example). For more information, see Polling requests

  • NeoLoad identifies the different types of message returned through the Push channel during recording. These different types of message are modelized by the Push messages (flex.samples.marketdata.Stock or flex.messaging.messages.AcknowledgeMessageExt for example).

  • The variable modifier init_polling initializes the NL-stopPolling variable, with the false value, to have the polling function work on every Virtual User iteration.

  • The polling_delay is the average of the time intervals between two polling requests in the original User Path.

  • The stop_polling variable modifier triggers the exit from the polling loop by modifying the value of the NL-stopPolling variable.

AMF streaming

After the recording, a User Path using AMF streaming is displayed as follows.

AMF streaming requests are identified as having a name with the <path> open and <path> close formats.

Once processed by the NeoLoad Post-recording wizard, the User Path is modified as follows.

NeoLoad has made the following noticeable changes:

  • The open Push request (/samples/messagebroker/streamingamf open for example) has been placed in a secondary execution thread, push_fork.

  • NeoLoad identifies the different types of message returned through the Push channel during recording. These different objects are modelized by the Push messages (flex.samples.marketdata.Stock or String for example).

  • The close Push request (/samples/messagebroker/streamingamf close for example) tells the server to stop Push. Upon receiving the request, the server closes the streaming request /samples/messagebroker/streamingamf open, allowing NeoLoad to move on to the next action. There are no other actions in the push_fork object so the secondary thread ends.

RTMP streaming

To be able to record RTMP requests, the Adobe RTMP option must be checked in the recording window.

After the recording, a User Path using the RTMP protocol is displayed as follows.

The RTMP Push channel is represented by the RTMPChannel object. Its recorded response contains all the messages sent by the server through the Push channel.

Once processed by the NeoLoad Post-recording wizard, the User Path is modified as follows.

NeoLoad has made the following noticeable changes:

  • The request representing the Push channel (RTMP_Channel for example) has been placed in a secondary execution thread (rtmp_channel_fork).

  • NeoLoad identifies the different types of message returned through the Push channel during recording. These different types of message are modelized by the Push messages (receive_flex.samples.marketdata.Stock for example here).

RTMPT streaming/polling

At the end of recording, launch a dynamic parameter search for NeoLoad to be able to handle the RTMP dynamic session IDs.

After the recording, a User Path using the RTMPT protocol is displayed as follows:

The following points should be noted:

  • A large number of HTTP requests with the /idle/ prefix have been recorded. These requests are polling requests.

  • When a Container is added during entering, polling requests also are added. This explains the a, ad, and rem. Containers.

Once processed by the Post-recording wizard, the User Path is modified as follows:

NeoLoad has made the following noticeable changes:

  • The request representing the opening of the RTMPT session (/open/1 for example) has been placed in a secondary execution thread (push_fork) since it is a blocked process. A Variable Extractor (RTMPTID for example) has been configured to extract and re-inject the RTMPT session variable in each of the following requests: /idle/XXX, /send/XXX or /close/XXX. Execution of the main thread is put on hold until the RTMPTID session variable is retrieved, using the wait_RTMPTID_Body object.

  • The variable modifier init_RTMPTID_Body resets the RTMPTID_Body variable, and the waiting time for a new value is considered on every Virtual User iteration.

  • All the RTMPT polling requests (except the first one) are grouped into a single polling request (/idle/${RTMPTID}/5 for example), reducing the number of requests considerably. If a Container becomes empty (a, ad, and rem for example), it is automatically deleted. For more information, see Polling requests.

  • The variable modifier init_polling initializes the NL-stopPolling variable, with the false value, to have the polling function work on every Virtual User iteration.

  • The request representing the RTMPT Push channel (/idle/${RTMPTID}/5 for example) has been placed in a loop (polling_while), which continues to loop until the NL-stopPolling variable generated by NeoLoad becomes true. Lastly, the loop itself has been placed in a secondary execution thread using a fork action (push_fork_1 for example).

  • NeoLoad identifies the different types of message returned through the Push channel during recording. These different types of message are modelized by the Push messages (receive_flex.samples.marketdata.Stock for example).

  • The polling_delay polling delay is the average of the time intervals between two polling requests in the original User Path.

  • The stop_polling variable modifier stops the polling loop by modifying the value of the NL-stopPolling variable.

ICEfaces polling

NeoLoad supports the open-source ICEfaces server and its commercial version, ICEfaces EE.

Versions 1.8.2a onwards of the ICEfaces server also feature an API that allows making use of the Push messages generated by the server itself as well as their associated timestamps. To be able to use the NeoLoad Push messages, the names of the ICEfaces beans and the beans associated timestamps must be published in the ICEfaces application.

The tested ICEfaces application is modified:

Modifying the ICEfaces bean:

The Java file containing the ICEfaces bean must contain a method publishing the additional information. For example, the MyBean.java file might contain the following code:

public class MyBean implements Renderable {
...
private GroupAsyncRenderer mybean;
private String renderInfo;
...
public String getRenderInfo()
{
String currentRenderInfo = mybean.getLastRenderInfo();
if(!currentRenderInfo.equals(renderInfo))
{
renderInfo = currentRenderInfo;
return currentRenderInfo;
} else {
return "";
}
}
...

Modifying the .jspx file:

The .jspx file containing the visual part of the content rendered in the browser must send back this information in the page. One idea is to send back the information in a hidden layer.

The code might take the following form:

...
<div id="hiddenDiv">
...
<ice:outputText value="MyBean #{MyBean.renderInfo}"/>
...
</div>
...

After the recording, a User Path using the ICEfaces Push Framework is displayed as follows.

Note: At the end of recording, a dynamic parameter search must be launched for NeoLoad to be able to handle the ICEfaces dynamic session IDs and the JSF ViewState.

The following points should be noted:

  • The ICEfaces polling is divided into two request categories: requests to the /receive-updated-views servlet and those to the /receive-updates servlet. This explains the large number of this type of requests.

  • User clicks are represented by requests to the /send-receive-updates servlet.

  • When a Container is added during entering, polling requests also are added. This explains the bi, connec... Containers.

Once processed by the NeoLoad Post-recording wizard, the User Path is modified as follows.

NeoLoad has made the following noticeable changes:

  • The two categories of polling requests have been grouped together: requests with the form XXX/receive-updated-views on the one hand and those with the form XXX/receive-updates on the other hand. This reduces the number of requests considerably. If a Container becomes empty (as is the case with bi and connec here for example), it is automatically deleted. For more information, see Polling requests

  • The Variable Extractor viewsToUpdate has been placed on the first polling request (/auctionMonitor3/block/receive-updated-views for example), which retrieves the id's for the ICEfaces views to be updated. This is why the second polling request has been placed in a loop (loop_update_view for example), in order to issue an update request for each previously-extracted view.

  • The request representing the ICEfaces Push channel (/auctionMonitor3/block/receive-updates for example) has been placed in a loop (polling_while), which continues to loop until the NL-stopPolling variable generated by NeoLoad becomes true. Lastly, the loop itself has been placed in a secondary execution thread using a fork action (push_fork for example).

  • NeoLoad identifies the different types of message returned through the Push channel during recording, provided that the server being tested is version 1.8.2a or upwards and that the developers have published the required additional information. These different types of message are modelized by the Push messages (ClockBean for example).

  • The polling_delay polling delay is the average of the time intervals between two polling requests in the original User Path.

  • The variable modifier init_polling initializes the NL-stopPolling variable, with the false value, to have the polling function work on every Virtual User iteration.

  • The stop_polling variable modifier stops the polling loop by modifying the value of the NL-stopPolling variable.

Lightstreamer polling

At the end of recording, a dynamic parameter search must be launched for NeoLoad to be able to handle the Lightstreamer dynamic session IDs.

After the record, a User Path using polling with the Lightstreamer Framework is displayed as follows.

The following point should be noted:

  • A large number of HTTP requests with the format XXX/bind_session.js have been recorded. These requests are polling requests.

Once processed by the Post-recording wizard, the User Path is modified as follows.

NeoLoad has made the following noticeable changes:

  • All the Lightstreamer polling requests have been grouped into a single polling request (/lightstreamer/bind_session.js for example). This request has been placed in a loop (polling_while for example), which continues to loop until the NL-stopPolling variable generated by NeoLoad becomes true. Lastly, the loop itself has been placed in a secondary execution thread using a fork action (push_fork for example). For more information, see Polling requests.

  • The variable modifier init_polling initializes the NL-stopPolling variable, with the false value, to have the polling function work on every Virtual User iteration.

  • NeoLoad identifies the different types of message returned through the Push channel during recording. These different types of message are modelized by the Push messages (initialSnapshot-1 or update-1 for example).

  • For each response returned by the Push channel, NeoLoad cuts up the JavaScript call into messages. NeoLoad recognizes three types of Lightstreamer call by default: initialSnapshot-X, update-X and heartbeat, where X represents the updated HTML component.

  • The Lightstreamer LS_phase parameter is handled using the LS_phase Variable Extractor set both on the session creation request (creation_session.js for example) and on the Push request (/lightstreamer/bind_session.txt for example). A JavaScript action (LS_phase_update1 for example) increments the value of the LS_phase variable at each loop iteration to reproduce the browser behavior.

  • The polling_delay polling delay is the average of the time intervals between two polling requests in the original User Path.

  • The stop_polling variable modifier stops the polling loop by modifying the value of the NL-stopPolling variable.

Lightstreamer streaming

At the end of recording, a dynamic parameter search must be launched for NeoLoad to be able to handle the Lightstreamer dynamic session IDs.

After the recording, a User Path using streaming with the Lightstreamer framework is displayed as follows.

The Lightstreamer streaming request is easily identified, since it ends with the path /STREAMING_IN_PROGRESS.

Once processed by the Post-recording wizard, the User Path is modified as follows.

NeoLoad has made the following noticeable changes:

  • The request representing the Lightstreamer Push channel (/lightstreamer/STREAMING_IN_PROGRESS for example) has been placed in a loop (streaming_while for example), which continues to loop until the LS_end_streaming variable generated by NeoLoad becomes true (the streaming request can be executed several time if the length of the response is over 300 Kb). Lastly, the loop itself has been placed in a secondary execution thread using a fork action (push_fork for example).

  • The variable modifier init_streaming initializes the LS_end_streaming variable, with the false value, to have the streaming function work on every Virtual User iteration.

  • NeoLoad identifies the different types of message returned through the Push channel during recording. These different types of message are modelized by the Push messages (initialSnapshot-0 or update-0 for example). The end message is added to the streaming request to handle several executions of the streaming request (if the response length is over 300 Kb).

  • For each response returned by the Push channel, NeoLoad cuts up the JavaScript call into messages. NeoLoad recognizes three types of Lightstreamer call by default: initialSnapshot-X, update-X and heartbeat, where X represents the updated HTML component.

  • The Lightstreamer LS_phase parameter is handled using the LS_phase Variable Extractor set on the session creation request (creation_session.js for example). A JavaScript action (LS_phase_update for example) increments the value of the LS_phase variable to reproduce the browser behavior. Lastly, this variable is used in the open streaming request (/lightstreamer/STREAMING_IN_PROGRESS for example).

WebSync polling

At the end of recording, a dynamic parameter search must be launched for NeoLoad to be able to handle the WebSync dynamic session id's (clientId).

After the recording, a User Path using the WebSync Push Framework is displayed as follows.

The following point should be noted:

  • A large number of HTTP requests with the format XXX/request.ashx have been recorded. These requests are polling requests.

Once processed by the Post-recording wizard, the User Path is modified as follows.

NeoLoad has made the following noticeable changes:

  • All WebSync polling requests have been grouped into a single polling request (/request.ashx for example). This request has been placed in a loop (polling_while for example), which continues to loop until the NL-stopPolling variable generated by NeoLoad becomes true. Lastly, the loop itself has been placed in a secondary execution thread using a fork action (push_fork for example). For more information, see Polling requests.

  • The variable modifier init_polling initializes the NL-stopPolling variable, with the false value, to have the polling function work on every Virtual User iteration.

  • The WebSync id parameter is handled using a JavaScript action (WebsyncVariables for example). At the first polling loop, the initial value is calculated in relation to the request that precedes the polling; it is then increment at each loop iteration to reproduce the browser behavior.

  • The variable modifier init_WS_id resets the WS_id variable to make the WebSync parameter consistent on every Virtual User iteration.

  • The polling_delay polling delay is the average of the time intervals between two polling requests in the original User Path.

  • The stop_polling variable modifier stops the polling loop by modifying the value of the NL-stopPolling variable.

Siebel polling

Siebel applications have a real-time message broadcasting feature that can send specific information to certain users in particular. The information usually is displayed at the bottom of the application screen as scrolling text; this is known as the message bar. Each client connected to the Siebel application sends a polling request at regular intervals to update the message bar settings and content.

After the recording, a User Path using polling to update the message bar is displayed as follows.

Note: When recording a scenario, NeoLoad identifies these requests as having a name with the form Message Bar:UpdatePrefMsg_XXX.

Once processed by the Post-recording wizard, the User Path is modified as follows.

NeoLoad has made the following noticeable changes:

  • All the Siebel polling requests to update the message bar have been grouped into a single polling request (Message Bar:UpdatePrefMsg for example). This request has been placed in a loop (polling_while for example), which continues to loop until the NL-stopPolling variable generated by NeoLoad becomes true. Lastly, the loop itself has been placed in a secondary execution thread using a fork action (push_fork for example). For more information, see Polling requests

  • The variable modifier init_polling initializes the NL-stopPolling variable, with the false value, to have the polling function work on every Virtual User iteration.

  • The polling_delay polling delay is the average of the time intervals between two polling requests in the original User Path.

  • The stop_polling variable modifier stops the polling loop by modifying the value of the NL-stopPolling variable.

HTML5 Server-Sent Events

Server-Sent Events are a technology for providing push notifications from a server to a browser in the form of DOM (Document Object Model) events. The Server-Sent Events EventSource API is standardized as part of HTML5.

After the recording, a User Path with the HTML5 Server-Sent Events (SSE) technology is displayed as follows.

Once processed by the Post-recording wizard, the User Path is modified as follows.

NeoLoad brings the following changes:

  • All the requests generating events are collected in a single request, for example /loadtest/html5/sse_long_events.jsp. The request is included in a while action, for example polling_while, which iterates until the NL-stopPolling variable generated by NeoLoad switches to true. Also, the while action is itself in a secondary execution thread with the fork action, for example push_fork. For more information, see Polling requests.

  • The variable modifier init_polling initializes the NL-stopPolling variable, with the false value, to have the polling function work on every Virtual User iteration.

  • The polling_delay polling delay is extracted from the polling response. When the server sends a reconnection order, the variable is extracted. Otherwise, the default value is 3 seconds. The delay simulates the timeout between two requests.

  • The stop_polling variable modifier makes it possible to stop the polling loop by changing the value of the NL-stopPolling variable