RTMPT streaming/polling

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