We are seeking an efficient and sufficient solution that may address your need that can hopefully be delivered in the short time term. One solution that should be easier to implement is to add a mechanism in LRC to monitor Vusers, when detecting failed Vusers the system will make several attempts to 'restart' Vusers automatically, the end-user will be able to enable such feature in the General tab (something like: "enable automatic attempts to restart failed vusers"). For example, I run a test with max Vusers of 1,000, during ramp-up (or even during the running stage), 3 Vusers failed (at this stage, we know the test will reach a maximum of 997 running Vusers), the system will detect there are three failed Vusers and will then attempt to 'restart' three Vusers, upon successful attempts, the test will run with 1,000 concurrent Vuers as planned. 

Looking for feedback on the proposed solution. 

Thank you. 

Hi Sharon, this is exactly what I understand under this idea. We should be able to maintain load, so if some users fail, we should be able to start new ones.

We have this possibility in the Performance center, and we use it. so this will be aligning two products, I guess?

thanks

Misha Pankevich

Rabobank

 - thanks for your prompt and detailed response, it is very helpful. I came to know that "restart" a failed vuser is impossible because threads of the operating system for the failed vusers are no longer available, however, what we should be able to do is to start a new vuser.. for example, you run a test with 100 vusers, five of them fail, LRC will allow the user to manually add up to five vusers in run time, to reach the desired 100 vusers concurrency. I wonder if such a solution will address your need. 

Regarding the other issue with vusers distribution, I have some suggestions and it will be best to take this one offline. 

Sharon 

 , We have purchased a VUH license with LR Cloud.

We are testing a SAP GUI application configured with Zscaler on on-premise load generators. We observed Zscaler going in idle state in machines after 10 min because of which tests which had ramp up time of all users greater than 10 min started having failed Vusers after 10 min duration. As a result, we have to abort the test which wastes VUH license. We have to keep accessing LG machines once in every 10 min duration throughout the ramp up period so that we don't get failed Vusers. Having the leverage to restart a Vuser would have avoided license wastage in such instances.

The problem is also with Vusers distribution during test in LR Cloud. Vusers are assigned to first LG and when that limit is over, then next set of Vusers are assigned to next LG. Because of this, some LG's don't get covered in the initial 10 min of ramp up  stage and thus Zscaler in those machines goes in idle state and needs reauthentication and the moment a vuser is assigned in running stage to those machines, it fails.

We can also configure the reauthentication timeout in Zscaler but vusers can fail due to n no. of reasons during ramp up.

My last test was planned for 250 users but 25 failed in ramp up and just because I couldn't restart those failed vusers, I had to abort and there was a license wastage for the time test was executed.

 ,  ,  et all, 

Please can you explain your use case and current challenge, and how a feature such as "restart failed vuser" will solve it? your detailed explanation will be appreciated. 

Sharon