CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

David Hayden [MVP C#]

         .NET Tutorials, Patterns, and Practices

Highly Scalable ASP.NET Websites and Web Applications

Udi Dahan mentions ultra scalability for the web in a recent post.  This was in regards to someone wondering about the scalability of nHibernate for a large scale web applications that has about 250,000 users with as many as 40,000 active users at a given time.

Although it is a fair question, Udi redirects the question of scalability to its most basic level:

"...what better way to handle load than preventing the users from hitting your servers at all?"

Perfect!  And exactly my point in a previous article:

The article starts out by talking about the UI:

"The less a client requests information from your website, the more HTTP requests your website or web application can handle as a whole.  The most sought after information can be grouped accordingly and wisely on your pages so that it eliminates the need for your visitors to have to browse and drill-down to information they want the most."

Although Developing High Performance and Scalable ASP.NET Websites sounds complicated, you can get quite a bit of bang for your buck by implementing down right simple and effortless solutions.  Most of the techniques center around the user interface of your web applications and effectively implementing output caching which can 1) short circuit page processing, or 2) eliminate page processing altogether by sending HTTP Headers telling a browser and/or proxy server that it can cache those pages to eliminate a trip to your application for a certain period of time.

It doesn't have the cool factor of talking about O/R Mappers, but it gives you a bigger bang for your buck and gets the job done.


Published Dec 10 2005, 05:08 PM by David Hayden
Filed under:

Comments

Dan Ciruli said:

Good points. Looking at your response to this (and your "Chatty Interfaces" post, which I enjoyed as well), I'd add one thing: sometimes, there's another tier involved (between tiers 2 and 3 in your diagram). Sometimes, you have to do some "heavy lifting" with the data that's been returned from the database before presenting it to the user. For example, you might have to do some media transformation to return a specific file type to the user in response to their request.

In cases like that, one way to ensure scalability is to distribute that processing so that neither your webserver nor your database machine are spending their CPU cycles on processing that data.

If you're interested, my company (Digipede) has a .NET-based distributed computing tool that helps with *that* part of the scalability problem.

In any case, thanks for the posts!
# December 12, 2005 8:23 PM
Check out Devlicio.us!

Our Sponsors

Free Tech Publications

This Blog

Syndication

News

CodeBetter.Com Home