What are the key factors that ensure successful ASP.NET application scalability?

Question

When starting a new ASP.NET application, with the knowledge that at some point in the future it must scale, what are the most important design decisions that will allow future scalability without wholsesale refactoring?

Answer 1

My Top three decisions are

1. Disabling or storing session state in a database.
2. Storing as little as possible in session state.
3. Good N-Tier Architecture. Separating business logic and using Webservices instead of directly accessing DLL's ensures that you can scale out both the business layer as well as the presentation layer. Your database will likely be able to handle anything you throw at it although you can probably cluster that too if needed.

You could also look at partitioning data in the database too.

I have to admit though I do this regardless of whether the site has to scale or not.

Answer 2

Ensure you have a solid caching policy for transient / static data. Database calls are expensive especially with separate physical servers so be aggressive with your caching.

Answer 3

There are so many considerations, that one could write a book on the subject. In fact, there is a great book and it is free. ;-)

Microsoft has released Improving .NET Application Performance and Scalability as a PDF eBook.

It is worth reading cover to cover, if you don't mind the droll writing style. Not only does it identify key performance scenarios, but also establishing benchmarks, measuring performance, and how to apply what you learn.

Answer 4

These are our internal ASP.Net Do's and Don't Do's for massively visited web applications:

General Guidelines

• Don't use Sessions - SessionState=Off
• Disable ViewState completely - EnableViewState=False
• Don't use any of the complext ASP.Net UI controls, stick to basic (DataGrid vs. Simple repeater)
• Use fastest and shortest data access mechanisms (stick to sqlreaders on the front site)

Application Architecture

• Create a caching manager with an abstraction layer. This will allow you to replace the simple System.Web.Cache with a more complex distributed caching solution in the future when you start scaling you application.
• Create a dedicated I/O manager with an abstraction layer to support future growth (S3 anyone?)
• Build timing tracing into your main pipelines which you can switch on and off, this will allow you to detect bottle necks when such occur.
• Employ a background processing mechanism and move whatever is not required to render the current page for it to chew on.
• Better yet - consider firing events from your application to other applications so they can do that async work.
• Prepare for database scalability, place your own layer so that you can later decide if you want to partition you database or alternatively work with several read servers in a master-slave scenario.

Above all, learn from others successes and failures and stay positive.