Unanswered question

What logic does the HTTP recorder use to determine when to start a new page?

In evaluating NeoLoad I have noticed that pages with a lot of resources get recorded with resource requests seemingly randomly recorded as pages with seemingly random children resources. I.e. We have a page that has maybe a hundred or so js, css, font, and image resources, along with APIs called for configurations and data, and the user path for the page will get recorded with some of the css files and js files as pages, and under some of these pages, API calls and other resources, when everything should actually be a resource of the original page. Is the logic purely based on timing, and if so is there any way to adjust the threshold for requests remaining as resources of a page vs starting a new page?

Sean F.
Sean F.

Sean F.

Level
0
23 / 100
points

Answers

Nouredine A.
Nouredine A.

Nouredine A.

Level
4
5000 / 5000
points
Team

That's right. One of the mechanism to create a page is related to timing but not only. It also depends on the response type like html response or not.

You can tweak a bit this timing by editing the $install_dir/conf/controller.properties file under [Recorder] section. There's that option: controller.recorder.pause.unexpected=500

This tells NeoLoad to wait 500ms before creating a new page but again since it's not the only mechanism in place it may not lead to your expected result.

You have to restart NeoLoad after modifying that value and make some try to see what is best for your application. Do not forget to reverse back that modification if not needed anymore.

 

Sean F.
Sean F.

Sean F.

Level
0
23 / 100
points

This is not an answer, but this community apparently doesn't offer a way to comment on answers. however, I wanted to say that I appreciate Nouredine's answer, but changing the configuration as suggested did not change the recording behavior. It still appears that the logic is creating new pages (randomly?) every second or so.

Sean F.
Sean F.

Sean F.

Level
0
23 / 100
points

Neil, here are a couple of examples of responses for resource requests from a landing page, that became "pages" in the user path and some of the resources from the actual parent landing page ended up under these "random" pages:
------------
HTTP/2.0 200
content-type: application/json;charset=UTF-8
content-length: 50
server: Apache/2.4.41 (Amazon) OpenSSL/1.0.2k-fips
content-encoding: gzip
cache-control: must-revalidate, max-age=300
expires: Mon, 19 Apr 2021 16:59:42 GMT
date: Mon, 19 Apr 2021 16:54:42 GMT
vary: Accept-Encoding
x-frame-options: DENY
cdn-rule: REDACTED

{"default_theme":"******"}
-------
HTTP/2.0 200
content-type: application/json;charset=UTF-8
content-length: 920
server: Apache/2.4.41 (Amazon) OpenSSL/1.0.2k-fips
addpolling: true
configurationkey: pollconfig
poll-interval: 900
content-encoding: gzip
cache-control: must-revalidate, max-age=226
expires: Mon, 19 Apr 2021 16:58:28 GMT
date: Mon, 19 Apr 2021 16:54:42 GMT
vary: Accept-Encoding
x-frame-options: DENY
cdn-rule: API_REDACTED

{---json-object--redacted---}

Many other API resources which erroneously get identified as pages have a similar content-type header.