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 –
web_set_max_param_len("99999");
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 general practice is to add a global setting at the start of the script like this –
web_set_max_param_len("99999");
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