| || |
I have rendezvous point added after login (start of my first transaction in Action, Login is in Init) . And in Performance center I have specified the criteria that wait till 100% of the users reaches there.
Now I am wondering because on Performance center I can see the Vusers are switching between the Rendez and Run queue. Why I am able to see the Vusers in Run queue while all my vusers are not logged in yet (rammed up yet) ? Also I was seeing the transaction in the Action method getting executed while I have Rendezvous point at the beginning of Action.
Re: Rendezvous point
Bad Magic. You have taken a chaotic arrival model and turned it into a synchronous action, which can only be governed by a clock tick. Rendezvous use of this nature has about a 95% correlation to users who have challenges in process and tool use.
The issues you are observing are related to your rendezvous policy implementation.
About a decade ago one of the major credit card systems was profiled in forbes. At this time the highest amount of collision action on the largest shopping day of the year was five. Why? Because all of the users arrived and departed chaotically. Consider that your actions "challenge" some of the foundations of the client-server model when you are asking human actions to become synchronous in this fashion.
Replace ineffective offshore contracts, LoadRunnerByTheHour
. Starting @ $19.95/hr USD.
Put us to the test, skilled expertise is less expensive than you might imagine.
Twitter: @LoadRunnerBTH @PerfBytes
Re: Rendezvous point
it's often useful to remember what we're doing here
testing the performance of an application (software and hardware) by modelling the users interaction with it
often fast ramp ups are unrealistic (do all you users really turn up within 15 minutes and all log on straight away?)
often rendezvous points are unrealistic (as James suggested above)
often very short (or non-existent) think times are unrealistic (humans do stuff whilst they're working, might be typing stuff in, might be reading, might be talking, might be thinking, might be anything)
often very short (or non-existent) pacing is unrealistic (users don't just sit at their desk for 8 hours straight every day - they go to the toilet, they get coffee, they take breaks)
the best that we can do is to model the average user and the average group of users - with some variation (randomised think time etc) and the average amount of user activity during a test - this will give us a probable normal load
the further away from reality you stray with your testing the further from reality the results are
some of the things that we're looking for - bottlenecks, memory leaks for example can occur in wildly different ways when we stray from reality
this means that developers can spend a lot of time trying to fix problems that are never going to happen in real life
this is expensive and pointless
occasionally there are good reasons to stray from this concept, but before you do have a good long think about what you are doing and how it will affect the users and whether or not the test is repeatable