Increasing the parameter size for correlation – cons of giving a randomly high number
Most of the times correlating dynamic variables in a Loadrunner script requires you to change the buffer size to a higher number. When there is not enough buffer size, you will encounter an error like the one shown below:
Error -26377: No match found for the requested parameter “VS01″. Check whether the requested boundaries exist in the response data. Also, if the data you want to save exceeds 1024 bytes, use web_set_max_html_param_len to increase the parameter size [MsgId: MERR-26377]
The general practice is to add a global setting at the start of the script like this –
While this sets up the buffer size to 999999 bytes – large enough to hold up your data, this poses serious problems that you won’t realize until it happens during a load test.
The mdrv.exe is a driver process which is responsible for running Vusers on your load generator. Even after LR11.xx, this process continues to be 32 bit one. So the maximum addressable space is 4GB by this process.
Running VUsers as thread has an advantage of sharing this 4 GB of space between a lot of threads. With the increase in number of users, you can see the instances of mdrv.exe increasing on your load generator to accommodate the users.
Each VUser takes up certain amount of space in your RAM depending on the code, context/context-less recording, custom variables + the amount of buffer before executing the request following a web_reg_save_param. The unused space from this buffer will be available for other threads of the process once the correlation is done.
At the precise point of assigning a certain buffer space to the requested parameter, if you happen to have a large number of VUsers demanding the same line of code execution, you will simply run out of memory and the user fails. You will see the following error in the VUser log and error message window:
Error -26000: Error: Out of memory ! [MsgId: MERR-26000]
The following screen shot is taken for a mock test which had a script with a high value for web_set_max_html_param_len and run with 100 users on a load generator
The same script when modified with the buffer size of what is only needed, it runs fine without any errors for the same number of users – ruling out bottlenecks from our test itself.
Note: The exact value required for web_set_max_html can never be known owing to the dynamic nature of the variables involved. In case of working with view states which might weigh over 2 MB – it is always safe to increase the size only by 50% of actual length of the recorded one.