loadrunner Interesting issue with Performance Center 12.50 and Load...

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

S

Scott Moore

Guest
Interesting issue with Performance Center 12.50 and Load Generators. We have a small web/http script with our test scenario in PC with a single URL requests in it. If we run a single group of vusers assigned to a single Generator, the CPU on the Generator goes to 100% at about 250 vusers. There are no memory, disk, or network bottlenecks that would cause this (we are monitoring the Generator). If we create 10 seperate groups and put 30 vusers in them and still assign all groups to the SAME Generator - we do not experience any 100% CPU proble. This indicates that there is something going on with the thread pools PER Group, right? Is there a vuser limit per group that we should be aware of? Is this expected behaivor? If not, is there a patch available to correct this?
 
Sort by date Sort by votes
CPU intensive operations in a single URL can be related to uncompressing GZIP content or parsing anything with DFEs. I dont know about how PC manages the groups (each group within it's own proc boundary?) but if the returned content of a particular URL is something that has got to do with GZIP or similar, a 32 bit mdrv process can quickly bring the CPU to a halt. Just a thought.
 
Upvote 0 Downvote
How is the RTS for each group ? Meaning are you using the same RTS for all the groups as you have in the group which took cent percent LG utilization?sometimes if you enable always send logs, run as process may cause this issue ! Also it depends how the groups are asked to ramp up. During ramp up at which user numbers you seeing the max utilization .Have you tried to see the LG s task manager for the list of process utilization summary while you are applying load with that ? Is the 100 percent utilization is constant during the test or getting fluctuated ?if fluctuated up to what level it is coming down and again spiking up?
 
Upvote 0 Downvote
Scott, did you try to break it to 50 Vusers group? This is what is happening automatically, each wrapper(MMDRV) holds 50 Vusers, this looks strange for a light weight script, will it happen with other "single URL" Scripts?
 
Upvote 0 Downvote
We kept upping it, but we decided to slow the ramp up wayyy down. We reached 1000 users We think we may have been overloading the authentication server and the disconnects were expensive to the Generator. It may have been sensing a DDOS. I am still trying to confirm this though.
 
Upvote 0 Downvote
Lost traction with the SUT - my guess is somethjng overloaded in the connection layer, causes a retry storm and thus mdrv goes into a spin. Did you try ramping up more slowly?
 
Upvote 0 Downvote
It's a defect we have seen for years. I think both Andrew Seling and myself both reported it. One way we have mitigated it was to change the thread allocation min block size to 64 instead of the default 16. Not sure if this happens on Linux generators however.
 
Upvote 0 Downvote
Also in both windows and Linux generation turn off the half open connection checking in the TCP/IP stacks. If in a retry storm that will hit at default 40 simultaneous half opens in Windows or in Linux it is whatever is set with sysctl. We ran into that specifically the day Microsoft pushed the update in Win2k3 years ago. Most enterprises now use 400 as the default in current os builds but that is site specific
 
Upvote 0 Downvote
You must log in or register to reply here.
Top Bottom
Back