loadrunner Got one question here : In which scenarios we...

  • perf-test.com need your contributions to build up a strong repository of performance engineering resources.

M

Maninder Singh

Guest
Got one question here : In which scenarios we would choose multi threading option as 'Process' instead of 'thread'. Because usually we choose 'thread' to utilize memory better
 
Sort by date Sort by votes
Non thread safe protocols for one. This doesn't happen as often as it used to on various platforms, but occasionally you get something that is not as thread safe as a library should be and when it goes it takes a lot of users with it. So, in that case, process is the more stable solution set.
 
Upvote 0 Downvote
For an example the application use access via browser are thin clients and application you access via clients are think client for example sap gui is a thick client
 
Upvote 0 Downvote
If you are using Citrix protocol you must use PROCESS - And even then the citrix dll code that handles connection setup isn't even thread safe across processes on the same box! Good luck!
 
Upvote 0 Downvote
"PROCESS we generally Use for THICK clients and THREAD for thin clients" This statement is not generally correct. For example, the ORACLE virtual user libraries are generally associated with thick clients. Thick clients are generally defined as clients with a substantial amount of local processing. Given the definition of local processing associated with thick clients you may encounter web clients which would meet the definition of thin clients (very little local processing, just GUI, with processing at the middle tier) or thick (AJAX). As Petar notes, the driver is whether the library involved is thread safe on a given platform, not the relative thickness or thinness of the client application. http://en.wikipedia.org/wiki/Thread_safety
 
Upvote 0 Downvote
In this case as LR uses the mdrv.exe as the execution process normally. THREADS means take your http/html/etc like script protocol and each vuser is executed as a thread under a mdrv.exe process There will be several less of these driver processes than vusers. However I've not actually figured out the algorithm as to how many threads get allocated to each mdrv.exe driver process since it does seem to change from test to test. If you execute as PROCESS then you will get one mdrv.exe process per vuser. A lot of this goes back to the early architecture of the product that just works and works well.
 
Upvote 0 Downvote
The algorithm is: If (lrp file of the protocol defines VuGen->MaxThreadPerProcess) {try to use this value} else {50}
 
Upvote 0 Downvote
Don't ask me why it is in VuGen section or why 50 (I know the answer but I will have to kill you if I tell you)
 
Upvote 0 Downvote
Thanks Boris. I guess that means I haven't digger deep enough into the tool yet. Neat. After 17 years one would have thought I would have figured that out by now. That does explain a few things though when I first figured out how yo get better vuser performance in Windows by setting the thread allocation registry higher though
 
Upvote 0 Downvote
You must log in or register to reply here.
Top Bottom
Back