Scaling an ASP.NET application

Question

This is a very broad question, but hopefully I can get useful tips. Currently I have an ASP.NET application that runs on a single server. I now need to scale out to accommodate increasing customer loads. So my plan is to:

1) Scale out the ASP.NET and web component onto five servers.

2) Move the database onto a farm.

I don't believe I will have an issue with the database, as it's just a single IP address as far as the application is concerned. However, I am now concerns about the ASP.NET and web tier. Some issues I am already worried about:

• Is the easiest model to implement just a load balancer that will farm out requests to each of the five servers in a round-robin fashion?

• Is there any problem with HTTPS and SSL connections, now that they can terminate on different physical servers each time a request is made? (for example, performance?)

• Is there any concern with regards to session maintanence (logon) via cookies? My guess is no, but can't quite explain why... ;-)

• Is there any concern with session data itself (stored server side)? Obviously I will need to replicate session state between servers, or somehow force a request to only go to a single server. Either way, I see a problem here...

Answer 1

As David notes, much of this question is really more of an Administrative thing, and may be useful on ServerFault. The link he posts has good info to pore over.

For your Session questions: You will want to look at either the Session State Service (comes with IIS as a separate service that maintains the state in common between multiple servers) and/or storing asp.net session state in a SQL database. Both are options you can find at David Stratton's link, I'm sure.

Largely speaking, once you set up your out-of-process session state, it is otherwise transparent. It does require that you store Serializable objects in Session, though.

---

Round-Robin DNS is the simplest way to load-balance in this situation, yes. It does not take into account the actual load on each server, and also does not have any provision for when one server may be down for maintenance; anyone who got that particular IP would see the site as being 'down', even though four other servers may be running.

Load balancing and handling SSL connections might both benefit from a reverse proxy type of situation; where the proxy handles all the connections coming in, but all it's doing is encryption and balancing the actual request load to the web servers. (these issues are more on the Administration end, of course, but...)

---

Cookies will not be a problem provided all the web servers are advertising themselves as being the same web site (via the host headers, etc). Each server will gladly accept the cookies set by any other server using the same domain name, without knowing or caring what server sent it; It's based on the host name of the server the web browser is connecting to when it gets a cookie value.

Answer 2

That's a pretty broad question and hard to answer fully in a forum such as this. I'm not even sure if the question belongs here, or if it should be at serverfault.com. However....

Microsoft offers plenty of guidance on the subject. The first result for "scaling asp.net applications" from BING comes up to this.

http://msdn.microsoft.com/en-us/magazine/cc500561.aspx

Answer 3

I just want to bring up areas you should be concerned about with the database.

First off, most data models built with only a single database server in mind require massive changes in order to support a database farm in a multimaster mode.

If you used auto incrementing integers for your primary keys (which most people do) then you're basically screwed out of the gate. There are a couple ways to temporarily mitigate this but even those are going to require a lot of guesswork and have a high potential of collision. One mitigation involves setting the seed value on each server to a sufficiently high number to reduce the likelihood of a collision... This will usually work, for awhile.

Of course you have to figure out how to partition users across servers...

My point is that this area shouldn't be brushed off lightly and is almost always more difficult to accomplish than simply scaling "up" the database server by putting it on bigger hardware.

If you purposely built the data model with a multi-master role in mind then kindly ignore. ;)

Regarding sessions: Don't trust "sticky" sessions, sticky is not a guarantee. Quite frankly, our stuff is usually deployed to server farms so we completely disable session state from the get go. Once you move to a farm there is almost no reason to use session state as the data has to be retrieved from the state server, deserialized, serialized, and stored back to the state server on every single page load.

Considering the DB and network traffic from just and that their purpose was to reduce db and network traffic then you'll understand how they don't buy you anything anymore.

Answer 4

I have seen some issues related to round robin http/https sessions. We used to use in process sessions and told the load balancers to make the sessions sticky. (I think they use a cookie for this).

It let us avoid SQL sessions but meant that when we switched from http to https, our F5 boxes couldn't keep the stickiness. We ended up changing to SQL sessions.

You could investigate pushing the encryption up to the load balancer. I remember that was a possible solution for our problem, but alas, not one we investigated.

Answer 5

The session database on an SQL server can be easily scaled out with little code & configuration changes. You can stick asp.net sessions to a session database and irrespective of which web server in your farm serves the request, your session-id based sql state server mapping works flawless. This is probably one of the best ways to scale out the ASP.NET Session state using SQL server. For more information, read the link True Scaleout model for session state