How to handle java script generated Session ID in Vugen using Load runner

A session id (GUID) is generated on client side via a javascript and sent to the server. This cannot be correlated because it doesn’t come from the server.

You will need to figure this out from the page source. In my case, the sessionID is assigned a value of window.SessionId where window.SessionID = NewGuid()

The body of NewGuid() is -

function NewGuid() {
-------

-Creates a new pseudo GUID.
------

var guid = ‘xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx’.replace(/[xy]/g, function (c) {
var r = Math.random() * 16 | 0, v = c == ‘x’ ? r : (r & 0×3 | 0×8);
return v.toString(16);
});
return guid;

}

This generates a session ID like : 3f58555c-d6f4-4b1e-ac2a-b89f5d173944

then Use web_js_run() function.
Save the above javascript code with .js extension in the script folder.
Add the script under Extra files via Add Files option
Go to RunTimeSettings -Preferences-Options-Web Javascript header-Enable running javascript code == change the value to Yes
Write the following function.the the result is stored in param1

Dynamic transaction names in Load runner | Dynamic Transaction names in Vugen | Dynamic transaction names with Iteration number in LR

Sometimes you may want to create transaction names on your own. These may be with iteration numbers or with parameter values which are present in the parameter file. I will show you an easy way to do this. follow here.

The transaction names should be used with lr_eval_String as below

lr_start_transaction(lr_eval_string("The script is now at the iteration number# {IterationNumber}"));

lr_end_transaction(lr_eval_string("The script is now at the iteration number# {IterationNumber}"), LR_AUTO);

Please make sure the Tx names of Start and End should be same, You need to pass the same value in Start and End Transactions so try to use the below code. Here the sTransName is a variable which holds the value of transaction name

Action()

{ 

char sTransName[50];

sprintf(sTransName,lr_eval_string("TransactionA_{IterationNumber}"));

lr_start_transaction(sTransName);

lr_end_transaction(sTransName,LR_AUTO);

 return 0; 

}

How to Pull the data from SQL via VB script

to pull the data from Sql via VB Script we need to follow these steps:

•  In the remote machine à H:\ :Create a notepad and copy below code 
•  Update the required SQL query in the below string “Sqlquery” and query should retrieve only one value .(while editing the query selectà Editàx.vbs)
•  Update the required server .(In the below code dev 90 is connected iiy replce 90 with 73,91,………….. as per requirement and environment ).
•  Then save it with “VBS” extension and double click the file .
• Verify the result in the H:\SQLResult.txt

strConn = "DRIVER={SQL Server};SERVER=sqlvirdev0090\dev90,6090;Database=rr_ge_db01;"

Set con = CreateObject("adodb.connection")

con.Open strConn

Sqlquery = "(select rx_i from rx where asgn_rx_i='80087139')"

Set Value = con.Execute(Sqlquery)

dbvalue = Value.fields(0)

'MsgBox dbvalue

Set txt = CreateObject("scripting.filesystemobject")

Set txt1 = txt.createtextfile("H:\ SQLResult.txt", True)

txt1.writeline dbvalue

Error -26000: Error: Out of memory ! [MsgId: MERR-26000] in load runner

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

Vusers are not existing after force stop,scenario is not finishing on time in Load runner

When ever you run a scenario and that is for set of Hrs and set of  mins, and you may observe that your VUsers are not dropping after this time, or they seem to be stalled in gradual exiting state,the reasons behind this are
1.Think Time: If your scripts are having exceedingly large think times, and your run time settings allow a 50 to 150% of recorded think time, these scripts will continue to execute till they have a controlled exit even after the stipulated schedule.so this may be a cause

2.Pacing – Your Transactions Per Second is what your pacing is. If your scripts have reached an execution state just before the end of the run, these executions will continue to run till they have a controlled exit. You might want to adjust the pacing accordingly to achieve exact Transactions Per Second  you are looking for..so this may be a cause

3.Load generators: Check the health of your load generators. If your load generators are fighting for resources, this may cause unforeseen consequences on your schedule..so this may be a cause

 if you are only looking out for the constant 1 hr run and ignore ramp up and ramp down schemes, you may with out any problem force stop the users. But, in case of tests where you want to look out for the resource handling, ramp down is a very important step and you may not want to force stop these users.