Lightstreamer polling
- Warning: 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 NeoLoad 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). 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. Thus, 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.