Highlighted
Absent Member.. Absent Member..
Absent Member..
318 views

User-Dependent Load tests

Jump to solution

Most tests that update data are "independent" of the logged-in user. So I can have a test account X running concurrent scripts because the scripts are editing different data (based on a file of order numbers etc.).

We needed to load test a bunch of edits to "My Profile" for an initial roll-out. Since an account has one profile, we couldn't use one account for concurrency due to record locking. So we set up 15 identical scripts, modified them for 15 unique accounts, and had them run concurrently, but of course that was only 15 concurrent users - not very many.

Any suggestions for better ways to approach? Spinning off 15 unique scripts was tedious enough; to have done a more realistic load would have been a real challenge.

0 Likes
1 Solution

Accepted Solutions
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Re: User-Dependent Load tests

Jump to solution

Looks good, in my opinion.

If you have a concern that there will be database locking due to concurrent users, then you would need to get as many users as you think will be on the system after go-live (i.e. you don't need to test 10,000 concurrent users if you will only have 1,000; or 1,000 concurrent if you will only have 10).

Have a think about the business requirement too - If you expect 2,000 in the first 6 hours (as an example), that's only 333 in an hour, 5 in a minute, 1 every 12 seconds. So to test this with a single user, the would save the profile every 12 seconds.

So if you have 15 users, for you to test for 2,000 in 6 hours, you would set up your load profile to have the 15 users log in and wait approx. 3 minutes between saving the profile.

Breaking down the requirement might make it seem less of a strain

View solution in original post

0 Likes
8 Replies
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Re: User-Dependent Load tests

Jump to solution

If the process to update the profile is the same for each user, you can parameterise the username and password during login, and just run the 1 script with 15 users once, or maybe run it serveral times in your load hour doing random updates to the fields?

Regarding the concurrency, with Load testing you can either test: Concurrent users; or throughput in the hour.

So if you know that you need to test that your server can handle 100 users at the same time (depending on the infrastructure of the system), you need to have 100 users logging in and doing something.

On the other hand if the requirement is to ensure that users can complete 1000 profile updates in the hour; then you can work out how many times the 15 users need to log in during the hour and do updatese to the profile and measure the response times of the saves (in transactions)

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: User-Dependent Load tests

Jump to solution

Hello Jimboling,
Are these accounts the users of the application or the ones logged into the machine? From your statement, I assume it is the first, and the 15 scripts were modified to provide a different set of credentials. 

If this is the case, I would recommend that you take a look into parameterization, as it will allow you to store a table of user credentials and use a different set for every vuser (or even for each iteration). There is a section in each version's User Guide with detailed information. Hope this helps to get you started.

HP Support

If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.
0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: User-Dependent Load tests

Jump to solution

Thanks Brian - one of our concerns with running more than once in a session is how do we know that user N won't get queued up to execute against itself? Does that make sense? The potential for overlap, which, the fewer the accounts you have, the greater the likelihood.

I think we thought about parameterizing to avoid the script duplication, but were afraid the above would be the bigger issue.

0 Likes
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Re: User-Dependent Load tests

Jump to solution

The controller software will take care of that internally when it runs the users.

HP have a Button in the parameter dialog in VuGen called "Simulate Parameter". This will show you how they will be split up during a run.
Your concern about the number of users is valid though. You might run into issues like client side or server side caching (i.e. when you log into the profile, a call might be sent out to the database and saved on the server, the next time you log into the profile if the details are still cached the call to the database may not be made). I'd look into getting more users.

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: User-Dependent Load tests

Jump to solution

OK thanks again. Sounds like the key points are:

1. parameterize to avoid script duplication - that's the easy one, and I think we just realized that since we only had 15 test accounts available, it was quicker to duplicate than to take the time to parameterize. Esp. since we are not yet real proficient at this stuff.

2. Check out Simulation to understand how the overlap might happen. This is good - need to look into this further.

3. There is no magic to get around the database locking potential especially with so few test accounts. If we anticipate that after go-live, in the first six hours there will be 2,000 updates (just throwing numbers out for example's sake), we should have a large number of unique accounts to use for testing. Is that accurate?

0 Likes
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Re: User-Dependent Load tests

Jump to solution

Looks good, in my opinion.

If you have a concern that there will be database locking due to concurrent users, then you would need to get as many users as you think will be on the system after go-live (i.e. you don't need to test 10,000 concurrent users if you will only have 1,000; or 1,000 concurrent if you will only have 10).

Have a think about the business requirement too - If you expect 2,000 in the first 6 hours (as an example), that's only 333 in an hour, 5 in a minute, 1 every 12 seconds. So to test this with a single user, the would save the profile every 12 seconds.

So if you have 15 users, for you to test for 2,000 in 6 hours, you would set up your load profile to have the 15 users log in and wait approx. 3 minutes between saving the profile.

Breaking down the requirement might make it seem less of a strain

View solution in original post

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: User-Dependent Load tests

Jump to solution

Can someone reply regarding the attached follow-up questions? In the attachments I include my original post question and some additional thoughts with diagrams of my perhaps flawed understanding of the way tests execute. It may not make any sense but if what I am asking is understandable I would appreciate any additional comments that might clarify my thinking.

Also I should respond to Brian's initial point in his final reply (or at least to my understanding of his initial point). My concern was not so much with the possibility of record locking when the application went into production, but as a side-effect of how I had constructed the test. We were attempting to anticipate the effects of many users editing records unique to them, which was difficult to emulate without having many unique accounts available for testing with. But it may be (as the attachments point out) that I really didn't have anything to worry about. Thanks

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: User-Dependent Load tests

Jump to solution

Just to elaborate on what I am picturing in the prior reply attachments: if I execute a load test with four scripts that are identical except for using four unique accounts, does each execution of the script for a given account execute serially (slide 1) or can multiple executions associated with a given account overlap with one another (slide 2)?

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.