Determine Number of Supported Users for a Web Application

Question

I'm developing an asp.net web application targeted to business customers. Can anyone provide some guidelines on how I can determine the number of users my application can support?

Also, the application uses session variables so its currently limited to one web server until that changes.

Answer 1

You can use a session state server running on a second box or sql server backed sessions to get around the single box issue.

As for the question at hand, there is no real way to determine that besides getting your hands on production hardware, setting up the app and running load tests until you can figure out where she breaks. This won't necessarily give you the real number as you have to make assumptions about what the users are doing and it is pretty much impossible to simulate the effects of the network cloud in test environments.

Answer 2

So you know, session can be made to work with multiple web servers very simply by moving it out to a sql server database.

A quick how to is available here

As for your original question, I would look into load testing. Hopefully there will be other posters who know more about that. I would focus on page views, as opposed to users.

Answer 3

Measure the resources (CPU, memory, disk, bandwidth) needed for typical actions within your application. Divide available resources by resources needed for a representative user "session" and you have a rough number.

Until you have a good set of real data, you'll have to make guesses about typical usage habits and the resource requirements. That's about all you can do for a 1st pass at estimating capacity.

Answer 4

A good load balancer can ensure that a user will return to the same server.

Answer 5

Only you/your team can determine the exact numbers that can be supported.

Your key to here is having a deep understanding of your problem domain and a distinct separation of the processing layers.

The separation allows you to isolate the bottlenecks, and tune the performance of the lowest performance factor much more easily, then move on to the next layer/performance limitation.

Do not make assumptions, as you will find impact unrelated to your assumptions that might surprise you.

1. Design to scale
2. Design to have separate “layers” for performance tuning reasons as well as your own sanity – it is also a better design principle and this is directly, one of the reasons development is segmented.
3. Test – design of “pass/fail” testing of layers to a design specification is only one facet of testing. Your question is answered by the performance impact of the technology, architecture and tools you choose to utilize in your application. Plan to make changes to each part of your application to address performance issues.
4. Gather performance metrics from each “layer”, tune each layer as you make discoveries of performance challenge nature. Plan for and discover how to quantify the performance measurements of each layer.
5. You WILL at some juncture have to make a compromise between performance and “cool/wow” factors. Each will impact your ability to market your solution, and you must then determine which will have the greatest impact.

This is one of the PAIN factors that I use to measure quality in designs – Plan All Incremental Needs and have discused elsewhere and in blogs.

Personally, I will often make decisions on design based on performance, but your marketing strategy might differ.