Design considerations for supporting around 400+ concurrent users in web application

Question

I am at the start of a mid sized asp.net c# project and with an application performance requirement to be able to support around 400+ concurrent users.

What are the things I need to keep in mind while architecting an application to meet such performance and availability standards? The page need to be served in under 5 seconds. I plan to have the application and database on separate physical machines. From a coding and application layering perspective:-

• If I have the database layer exposed to the application layer via a WCF service, will it hamper the performance? Should I use a direct tcp connection instead?
• Will it matter if I am using Entity framework or some other ORM or the enterprise library data block?
• Should I log exceptions to database or a text file?
• How do I check while development if the code being built is going to meet those performance standards eventually? Or is this even a point I need to worry about at development stage?
• Do I need to put my database connection code and other classes that hold lookup data that rarely change for the life of the application, in static classes so it is available thru the life of the application?
• What kind of caching policy should I apply?
• What free tools can I use to measure and test performance? I know of red-gate performance measurement tools but that has a high license cost, so free tools are what I'd prefer.

I apologize if this question is too open ended. Any tips or thoughts on how I should proceed?

Thanks for your time.

Answer 1

An important consideration when designing a scalable application is to make it stateless. No sessions. Another important consideration is to cache everything that you can in order to reduce database queries. And this cache should be distributed to other machines which are specifically design to store it. Then all you have to do is throw an additional server when the application starts to run slowly due to an increased user load.

As far as your questions about WCF are concerned, you can use WCF, it won't be a bottleneck for your application. It will definitely add an additional layer which will slow things a bit but if you want to expose a reusable layer that can scale independently on its own WCF is great.

ORMs might indeed introduce a performance slowdown in your application. It's more due to the fact that you have less control over the generated SQL queries and thus more difficult to tune them. This doesn't mean that you shouldn't use an ORM. It's just to be careful about what SQL it spits and tune it with your DB admin. There are also lightweight ORMs such as dapper, PetaPoco and Massive that you might consider.

As far as static classes are concerned, they won't improve performance that much compared to instance classes. A class instantiation on the CLR is a pretty fast operation as Ayende explains. Static classes will introduce tight coupling between your data access layer and your consuming layer. So you can forget about static classes for the moment.

For error logging, I would recommend you ELMAH.

For benchmarking there are quite a lot of tools, Apanche Bench is one that is simple to use.