Mixing
Estimation of maximum no of concurrent users a application will need to support
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I need to estimate the maximum number of concurrent users my application will experience in order to set goals for the software development team.
We have 550 potential users, but modelling of the workload suggest that the number of concurrent users will be considerably less. How do I set a set a sensible goal AND persuade a nervous customer that the goal is realistic?
I have good information about the amount of work that will be performed (records created/updated) over the 5 year life of the application and how this work will vary month to month. I also know the working hours of the users and the average duration of each visit. This tells me that if the expected work per month was spread evenly over each month, there will be an average number of 6.5 concurrent users.
Obviously in real life the number of concurrent users will vary.
Is it reasonable to plug this average of 6.5 concurrent users into a poisson distribution, select a confidence limit (I think I could sell 99%) and derive a target 'maximum" number of concurrent users that will rarely be exceeded.
Is this a valid approach?
performance performance-testing
asked 3 hours ago
David Bridges
112
New contributor
David Bridges is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
2
down vote
favorite
I need to estimate the maximum number of concurrent users my application will experience in order to set goals for the software development team.
We have 550 potential users, but modelling of the workload suggest that the number of concurrent users will be considerably less. How do I set a set a sensible goal AND persuade a nervous customer that the goal is realistic?
I have good information about the amount of work that will be performed (records created/updated) over the 5 year life of the application and how this work will vary month to month. I also know the working hours of the users and the average duration of each visit. This tells me that if the expected work per month was spread evenly over each month, there will be an average number of 6.5 concurrent users.
Obviously in real life the number of concurrent users will vary.
Is it reasonable to plug this average of 6.5 concurrent users into a poisson distribution, select a confidence limit (I think I could sell 99%) and derive a target 'maximum" number of concurrent users that will rarely be exceeded.
Is this a valid approach?
performance performance-testing
asked 3 hours ago
David Bridges
112
New contributor
David Bridges is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I need to estimate the maximum number of concurrent users my application will experience in order to set goals for the software development team.
We have 550 potential users, but modelling of the workload suggest that the number of concurrent users will be considerably less. How do I set a set a sensible goal AND persuade a nervous customer that the goal is realistic?
I have good information about the amount of work that will be performed (records created/updated) over the 5 year life of the application and how this work will vary month to month. I also know the working hours of the users and the average duration of each visit. This tells me that if the expected work per month was spread evenly over each month, there will be an average number of 6.5 concurrent users.
Obviously in real life the number of concurrent users will vary.
Is it reasonable to plug this average of 6.5 concurrent users into a poisson distribution, select a confidence limit (I think I could sell 99%) and derive a target 'maximum" number of concurrent users that will rarely be exceeded.
Is this a valid approach?
performance performance-testing
asked 3 hours ago
David Bridges
112
New contributor
David Bridges is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I need to estimate the maximum number of concurrent users my application will experience in order to set goals for the software development team.
We have 550 potential users, but modelling of the workload suggest that the number of concurrent users will be considerably less. How do I set a set a sensible goal AND persuade a nervous customer that the goal is realistic?
I have good information about the amount of work that will be performed (records created/updated) over the 5 year life of the application and how this work will vary month to month. I also know the working hours of the users and the average duration of each visit. This tells me that if the expected work per month was spread evenly over each month, there will be an average number of 6.5 concurrent users.
Obviously in real life the number of concurrent users will vary.
Is it reasonable to plug this average of 6.5 concurrent users into a poisson distribution, select a confidence limit (I think I could sell 99%) and derive a target 'maximum" number of concurrent users that will rarely be exceeded.
Is this a valid approach?
performance performance-testing
performance performance-testing
asked 3 hours ago
David Bridges
112
New contributor
David Bridges is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 3 hours ago
David Bridges
112
New contributor
David Bridges is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 3 hours ago
David Bridges
112
New contributor
David Bridges is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 3 hours ago
David Bridges
112
asked 3 hours ago
David Bridges
112
112
New contributor
David Bridges is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
David Bridges is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
David Bridges is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
3
down vote
I would say that the more proper approach would be to segregate load for different functional areas and concentrate on the maximum number of historically concurrent users. Let me explain in ore details.
...application will need to support...
This is not a concrete statement. Since normally application provides a set of features which performance might or might not affect performance of some other features. Yet one might find ambiguity in the statement. Does N concurrently logged in users prove that the application can support those N users?
Historical Average
I would not stick to how many users and on which day were logged in to the system historically. You can just take the maximum. If there was a day when there was 2 times more of logged in users that some other day then nobody will bet such the circumstances won't repeat again.
Guessed load values
When we'll break down the load by the functional points we might notice that there could be the cases when we can expect the load that could be much closer to the overall maximum than in some regular circumstances. For example if the service terminates some feature there might be some urgent activity required by the user (like back up some data that would not be maintained by your service any more). This will lead to load increase which hassn't been observed historically. So some potential spikes analysis is still required.
answered 2 hours ago
Alexey R.
5,629728
add a comment |Â
up vote
2
down vote
If your application worked fine so far I don't think you will run into problems. If your calculation is correct and you will not have more than 7 concurrent users you don't have anything to worry about.
However you can consider a Stress Test excercise in order to determine your application boundaries and determine when (and why) it gonna break.
- Come up with a realistic test which will represent normal application usage by all types of users
- Start with 1 virtual user and gradually increase the load unless you reach saturation point - when the performance starts degrading. Record the number of users which were active at this moment and that would be how many users your application can support without any issues.
Once done you can set up a Load Test with anticipated amount of concurrent users, let say 10 to determine performance baseline and execute this short smaller test periodically and in automated manner (i.e. make it as a part of your continuous integration pipeline) - this way you will get confidence that the new functionality or bug fixes will not cause performance degradation.
answered 56 mins ago
Dmitri T
7,395169
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
I would say that the more proper approach would be to segregate load for different functional areas and concentrate on the maximum number of historically concurrent users. Let me explain in ore details.
...application will need to support...
This is not a concrete statement. Since normally application provides a set of features which performance might or might not affect performance of some other features. Yet one might find ambiguity in the statement. Does N concurrently logged in users prove that the application can support those N users?
Historical Average
I would not stick to how many users and on which day were logged in to the system historically. You can just take the maximum. If there was a day when there was 2 times more of logged in users that some other day then nobody will bet such the circumstances won't repeat again.
Guessed load values
When we'll break down the load by the functional points we might notice that there could be the cases when we can expect the load that could be much closer to the overall maximum than in some regular circumstances. For example if the service terminates some feature there might be some urgent activity required by the user (like back up some data that would not be maintained by your service any more). This will lead to load increase which hassn't been observed historically. So some potential spikes analysis is still required.
answered 2 hours ago
Alexey R.
5,629728
add a comment |Â
up vote
3
down vote
I would say that the more proper approach would be to segregate load for different functional areas and concentrate on the maximum number of historically concurrent users. Let me explain in ore details.
...application will need to support...
This is not a concrete statement. Since normally application provides a set of features which performance might or might not affect performance of some other features. Yet one might find ambiguity in the statement. Does N concurrently logged in users prove that the application can support those N users?
Historical Average
I would not stick to how many users and on which day were logged in to the system historically. You can just take the maximum. If there was a day when there was 2 times more of logged in users that some other day then nobody will bet such the circumstances won't repeat again.
Guessed load values
When we'll break down the load by the functional points we might notice that there could be the cases when we can expect the load that could be much closer to the overall maximum than in some regular circumstances. For example if the service terminates some feature there might be some urgent activity required by the user (like back up some data that would not be maintained by your service any more). This will lead to load increase which hassn't been observed historically. So some potential spikes analysis is still required.
answered 2 hours ago
Alexey R.
5,629728
add a comment |Â
up vote
3
down vote
up vote
3
down vote
I would say that the more proper approach would be to segregate load for different functional areas and concentrate on the maximum number of historically concurrent users. Let me explain in ore details.
...application will need to support...
This is not a concrete statement. Since normally application provides a set of features which performance might or might not affect performance of some other features. Yet one might find ambiguity in the statement. Does N concurrently logged in users prove that the application can support those N users?
Historical Average
I would not stick to how many users and on which day were logged in to the system historically. You can just take the maximum. If there was a day when there was 2 times more of logged in users that some other day then nobody will bet such the circumstances won't repeat again.
Guessed load values
When we'll break down the load by the functional points we might notice that there could be the cases when we can expect the load that could be much closer to the overall maximum than in some regular circumstances. For example if the service terminates some feature there might be some urgent activity required by the user (like back up some data that would not be maintained by your service any more). This will lead to load increase which hassn't been observed historically. So some potential spikes analysis is still required.
answered 2 hours ago
Alexey R.
5,629728
I would say that the more proper approach would be to segregate load for different functional areas and concentrate on the maximum number of historically concurrent users. Let me explain in ore details.
...application will need to support...
This is not a concrete statement. Since normally application provides a set of features which performance might or might not affect performance of some other features. Yet one might find ambiguity in the statement. Does N concurrently logged in users prove that the application can support those N users?
Historical Average
I would not stick to how many users and on which day were logged in to the system historically. You can just take the maximum. If there was a day when there was 2 times more of logged in users that some other day then nobody will bet such the circumstances won't repeat again.
Guessed load values
When we'll break down the load by the functional points we might notice that there could be the cases when we can expect the load that could be much closer to the overall maximum than in some regular circumstances. For example if the service terminates some feature there might be some urgent activity required by the user (like back up some data that would not be maintained by your service any more). This will lead to load increase which hassn't been observed historically. So some potential spikes analysis is still required.
answered 2 hours ago
Alexey R.
5,629728
answered 2 hours ago
Alexey R.
5,629728
answered 2 hours ago
Alexey R.
5,629728
answered 2 hours ago
Alexey R.
5,629728
5,629728
add a comment |Â
add a comment |Â
up vote
2
down vote
If your application worked fine so far I don't think you will run into problems. If your calculation is correct and you will not have more than 7 concurrent users you don't have anything to worry about.
However you can consider a Stress Test excercise in order to determine your application boundaries and determine when (and why) it gonna break.
- Come up with a realistic test which will represent normal application usage by all types of users
- Start with 1 virtual user and gradually increase the load unless you reach saturation point - when the performance starts degrading. Record the number of users which were active at this moment and that would be how many users your application can support without any issues.
Once done you can set up a Load Test with anticipated amount of concurrent users, let say 10 to determine performance baseline and execute this short smaller test periodically and in automated manner (i.e. make it as a part of your continuous integration pipeline) - this way you will get confidence that the new functionality or bug fixes will not cause performance degradation.
answered 56 mins ago
Dmitri T
7,395169
add a comment |Â
up vote
2
down vote
If your application worked fine so far I don't think you will run into problems. If your calculation is correct and you will not have more than 7 concurrent users you don't have anything to worry about.
However you can consider a Stress Test excercise in order to determine your application boundaries and determine when (and why) it gonna break.
- Come up with a realistic test which will represent normal application usage by all types of users
- Start with 1 virtual user and gradually increase the load unless you reach saturation point - when the performance starts degrading. Record the number of users which were active at this moment and that would be how many users your application can support without any issues.
Once done you can set up a Load Test with anticipated amount of concurrent users, let say 10 to determine performance baseline and execute this short smaller test periodically and in automated manner (i.e. make it as a part of your continuous integration pipeline) - this way you will get confidence that the new functionality or bug fixes will not cause performance degradation.
answered 56 mins ago
Dmitri T
7,395169
add a comment |Â
up vote
2
down vote
up vote
2
down vote
If your application worked fine so far I don't think you will run into problems. If your calculation is correct and you will not have more than 7 concurrent users you don't have anything to worry about.
However you can consider a Stress Test excercise in order to determine your application boundaries and determine when (and why) it gonna break.
- Come up with a realistic test which will represent normal application usage by all types of users
- Start with 1 virtual user and gradually increase the load unless you reach saturation point - when the performance starts degrading. Record the number of users which were active at this moment and that would be how many users your application can support without any issues.
Once done you can set up a Load Test with anticipated amount of concurrent users, let say 10 to determine performance baseline and execute this short smaller test periodically and in automated manner (i.e. make it as a part of your continuous integration pipeline) - this way you will get confidence that the new functionality or bug fixes will not cause performance degradation.
answered 56 mins ago
Dmitri T
7,395169
If your application worked fine so far I don't think you will run into problems. If your calculation is correct and you will not have more than 7 concurrent users you don't have anything to worry about.
However you can consider a Stress Test excercise in order to determine your application boundaries and determine when (and why) it gonna break.
- Come up with a realistic test which will represent normal application usage by all types of users
- Start with 1 virtual user and gradually increase the load unless you reach saturation point - when the performance starts degrading. Record the number of users which were active at this moment and that would be how many users your application can support without any issues.
Once done you can set up a Load Test with anticipated amount of concurrent users, let say 10 to determine performance baseline and execute this short smaller test periodically and in automated manner (i.e. make it as a part of your continuous integration pipeline) - this way you will get confidence that the new functionality or bug fixes will not cause performance degradation.
answered 56 mins ago
Dmitri T
7,395169
answered 56 mins ago
Dmitri T
7,395169
answered 56 mins ago
Dmitri T
7,395169
answered 56 mins ago
Dmitri T
7,395169
7,395169
add a comment |Â
add a comment |Â
David Bridges is a new contributor. Be nice, and check out our Code of Conduct.
David Bridges is a new contributor. Be nice, and check out our Code of Conduct.
David Bridges is a new contributor. Be nice, and check out our Code of Conduct.
David Bridges is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsqa.stackexchange.com%2fquestions%2f36037%2festimation-of-maximum-no-of-concurrent-users-a-application-will-need-to-support%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
