Estimation of maximum no of concurrent users a application will need to support

Question

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?

Answer 1

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.

Answer 2

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.

1. Come up with a realistic test which will represent normal application usage by all types of users
2. 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.

Answer 3

If all you have is month-to-month estimates of how much work is going to be done, you absolutely can't then extrapolate down. If you had day-to-day numbers, I might be OK with using those, but within a month, a lot can happen. If you're building a system for a company in Europe or China, for example, it's entirely possible that 3/4 of the office will be out for a significant part of a month, and then all of the data entry will happen within a week. If you're building something for a bank in the US, there can be magnitudes of difference between the amount of data that is collected from day to day, based on holidays. Depending on how the data is generated, you may well end up with spikes at the beginning of the day or the end, the beginning of the week or the end, or the beginning of the month or the end.

When it comes to load/stress estimates, the average is meaningless. The peak is what matters, and you don't have enough information to estimate what the peak is, other than a maximum of 550 simultaneous users.

I'm going to follow up on Dmitri's comment, and suggest you're looking at this incorrectly. Instead of trying to figure out what the maximum concurrent number of users might be, and convince the powers that be that you're right, or reasonable, why not figure out what it would take to build a system that can support, say, 550 concurrent users? Or 200? Or 50? Depending on the technologies you're using, the difference in hardware cost/engineering work required to support 550 vs 6.5 may be small, and as an executive, I'd much rather be told about a system that can handle the worst case scenario, and not one that can probably handle things most of the time, but might fall over sometimes, under peak load, which is probably when I care about it the most.

Once you've done this, then you can do load/stress testing, see what the maximum is, and see what your bottleneck is, and provide an estimate of what it would take to fix that. If nothing else, you want to be able to tell the powers that be that it can support N simultaneous users; at M users, it will start to slow down, and at Y users, it will fall down entirely. And let them decide if that's sufficient.