(EDIT: rewritten question to make it clearer, meaning hasn’t changed)
You can create an application and measure its usage. But what I would like to know, if you decide up-front about an ASP.NET application, how much simultaneous users (sessions) fit into one machine typically.
Let’s assume the following default simplified setup: Inproc sessions, ASP.NET 3.5, NHibernate + L2 caching, shopping site (basket properties in session).
While I could ascertain that the session won’t raise above, say, 20kB, my experience shows me that there’s a huge overhead in general, even with well-laid-out applications. I’m looking for that simple calculation you can make on a sticky note.
For the bounty: what CPU / Mem would you advise your management for each X simultaneous users, ignoring bandwidth requirements. I.e. and answer could be: on a 2GHz Xeon with 1GB mem, Win2k8, you can safely serve 500 simultaneous sessions, but above that it requires careful planning or more hardwarere
Since you’re looking for an actual #, I’ll provide you some. We are creating a secure HR application utilize ASP.NET MVC. Like you we wanted to get a good feeling for maximum concurrent connections, which we defined as the max # of pages served in 10 seconds (assumes that a user would not wait more than 10 seconds for a page).
Since we were looking for an upper bound, we used a very simple page. SSL + a few session variables. On a Dual Xeon quad core (8 cores total), with 16GB of memory and SQL Express as the backend, we were able to hit ~1,000 “concurrent” connections. Neither memory or SQL express were the limiting factors though, it was primarily processor & I/O for our test. Note that we did not use caching, although for a shopping cart I doubt you would either. This page hit the database ~3 times, and sent ~150KB of data (mostly png images, uncached). We verified that 1,000 sessions were created, although each was small.
Our POV is that 1,000 is likely unrealistic. Tests including pages with business logic and real user data showed ~200 concurrent users max. However, some users will also be running reports, which could chew up an entire core for up to 30 seconds. In this scenario, 9 concurrent reports users could basically make the system unsuitable for others. This is to the other poster’s points … you can grab other performance #s all you want, but your system might behave entirely differently based on what it’s doing.