ASP.NET Application Scaling

Question

This is a very broad question, but I hope I can get some useful tips. I currently have an ASP.NET application that runs on a single server. Now I need to scale to meet the growing workload of customers. So my plan is this:

1) Change ASP.NET and the web component to five servers.

2) Move the database to the farm.

I do not believe that I will have a problem with the database, as this is just one IP address for the application. However, now I'm worried about ASP.NET and the web tier. Some issues I'm already worried about:

• Is the simplest model to implement only load balancing, which will handle requests for each of the five servers with cyclic mode?

• Are there any problems with HTTPS and SSL connections now that they can terminate on different physical servers every time a request is made? (e.g. performance?)

• Is there any concern regarding session support (login) via cookies? I think not, but I can not explain why ...; -)

• Is there any problem with the session data itself (server side stored)? Obviously, I will need to replicate the state of the session between the servers or somehow make the request go to only one server. Anyway, I see a problem here ...

Answer 1

As David points out, most of this issue is actually more likely administrative, and may be useful for ServerFault. The link that he publishes has good information to dig through.

For your Session questions: you need to look at either the session state service (comes with IIS as a separate service that maintains common state between several servers), and / or saving the asp.net session state in the SQL Database. Both options that you can find in the David Stretton link, I'm sure.

Generally speaking, after you configure a session state outside the process, it is transparent. This requires that you save Serializable objects in the session.

---

Round-Robin DNS is the easiest way to balance the load in this situation, yes. It does not take into account the actual load on each server, and also does not have any conditions when one server may be unavailable for maintenance; anyone who gets this IP address will see that the site is down, although four other servers may work.

Load balancing and handling of SSL connections can benefit from the reverse proxy type; where the proxy handles all incoming connections, but all it does is encrypt and balance the actual upload of the request to the web servers. (these problems, of course, are more on the side of the Administration, but ...)

---

Cookies will not be a problem if all web servers advertise themselves as the same website (via host headers, etc.). Each server happily accepts cookies set by any other server using the same domain name, without knowing and not caring about which server sent it; It is based on the host name of the server that the web browser connects to when it receives a cookie value.

Answer 2

This is a fairly broad question and it is difficult to fully answer such a forum. I'm not even sure what the question is here, or if it should be on server.com. But....

Microsoft offers many recommendations on this. The first result for "scaling asp.net applications" from BING is just that.

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

Answer 3

I just want to identify areas that you need to worry about in the database.

First, most data models built with only one database server require significant changes to support the database farm in multimaster mode.

If you used auto-incrementing integers for your primary keys (which most people do), you are mostly turned out of the gate. There are several ways to temporarily mitigate this, but even those that require a lot of guesswork and have high collision potential. One mitigation involves setting the initial value on each server to a large enough number to reduce the likelihood of a collision ... This will usually work for a while.

Of course, you need to figure out how to split users on different servers ...

My point is that this area should not be slightly brushed aside and it is almost always difficult to accomplish than simply scaling up the database server, placing it on larger equipment.

If you intentionally built a data model with the role of several masters, then kindly ignore.;)

Regarding sessions: do not trust “sticky” sessions, sticky is not a guarantee. Honestly, our materials are usually deployed in server farms, so we completely disconnect the session state from the transition. As soon as you go to the farm, there is almost no reason to use session state, because the data must be received from the state server, deserialized, serialized and stored on the state server each time one page loads.

Taking into account the DB and network traffic from the very beginning, and their goal was to reduce db and network traffic, you will understand how they no longer buy you.

Answer 4

I saw some issues with round robin http / https sessions. Previously, we used in process sessions and informed load balancers to make sessions sticky. (I think they use cookies for this).

This allowed us to avoid SQL sessions, but meant that when we switched from http to https, our F5 boxes could not remain sticky. We switched to SQL sessions.

You can examine the press of encryption before balancing the load. I remember that this was a possible solution to our problem, but, alas, we did not investigate.

Answer 5

The session database on the SQL server can be easily scaled with a little code and configuration changes. You can embed asp.net sessions into the session database and no matter which web server in your farm is serving this request, session-based sql server state matching works flawlessly. This is probably one of the best ways to scale the state of an ASP.NET session using an SQL server. For more information, read the True Scaleout model link for session state.