I have been asked the following question a couple times and feel like I could have had a better answer for it so I'm relaying it here in hopes of finding more resources, blogs books or pointers on writing scalable MVC3 C# code. If you have any pointers on writing better performing code that is hosted across multiple servers I would greatly appreciate it. For the sake of argument lets say it would be for code that expects upwards of 10-20K hits a day.
Question:
What coding considerations do you take into account for writing scalable code that is distributed over several servers?
My gut tells me the answer lies in handling session. My background over the last few years has been in writing services and forms applications not as much for web applications so I'm looking for information that can help me with web application specific development particularly for C# MVC3. Any blogs or books that you suggest I'll definitely look into!
One of the rules for implementing scalable web applications is for them to be stateless. Session is the first thing that should be thrown out of the equation as this is exactly what makes an application stateful. If you have a completely stateless application you could throw hardware when traffic increases and the application will be able to handle it. So start by putting the following line in your web.config:
<system.web>
<sessionState mode="Off" />
...
</system.web>
The problem will now lie on the data tier as this is where the state goes. So in order to improve performance and limit the number of requests to this node would be to use caching. Cache as much data as you can. Preferably store this cache on separate machines than the web servers. Dedicated machines for doing caching.
Related
I have read a ton of questions/answers on here regarding questions similar or about topics this would cover. I have come across a ton of different articles that outline setting up MVC to respond to inbound requests.
However, I have not been able to get a clear understanding of the limitations to the problem I am up against.
Problem:
I am creating an asp.net MVC 3 site. However, there is two scenarios where I will have a asp.net WebForms application making calls into my site and I need to respond.
One is simply returning a couple strings
The second is a bit more complex, a query result, a undetermined amount of data for reporting purposes by the webforms app.
Because of #2, am I forced to use some type of service like SOAP so an object can be interchanged between both apps?
I really wanted to use a RESTful approach with my URI's but my shortcomings are
What limitations due to the reporting information I got to pass back
the response is going to a web-forms app
Can someone give me some insight on what my options are?
Sounds like you need a separate service to deal with those specifics, I would start looking at Web API to meet those needs, you might even be able to leverage that API for other things
If Web API is too much of "early adoption" for you then you could fall back on WCF
While working on one ASP.NET project hosted within web farm including two front ends and load balancing, we got one issue regarding ASP.NET session state while being set to be "InProc", and we found that it's not working properly with load balancing., and we should consider using of "SQLServer" mode.
So, I'm wondering if there are any other points (Sessions, Caching, Security, file uploading, SQL Connections ...), we should take in consideration while development and deployment in such environment.
Microsoft offers some guidance on this. They have a knowledge base article with links to other resources you'll need.
http://support.microsoft.com/kb/815162
Oh, and as always, ScottGu has an excellent article and a cooler way of doing it. I just found this and it looks very promising:
The Microsoft Web Farm Framework
http://weblogs.asp.net/scottgu/archive/2010/09/08/introducing-the-microsoft-web-farm-framework.aspx
and the more recent Web Farm Framework Site has plenty of resources available. http://www.iis.net/download/webfarmframework
Although I never used it, I found out that the articles of Omar Al Zabir over at CodeProject.com seem to be rather helpful.
His article "99.99% available ASP.NET and SQL Server SaaS Production Architecture" covers some load balancing topics.
See my answer here regarding things to keep in mind with session state.
It references this article that has lots of good information on session state.
On my development server, I've configured IIS to use 3 worker processes (web garden) as a poor mans test for our load balanced environment, worked a treat.
We dont use session/application data. Our load balancer is configured with address affinity, so requests from the same IP go to the same server, thus allowing us to cache some user data. Our biggest gotcha was with cached data across the farm not being in sync, solved by wrapping the cache with a simple network library to send 'cached item changed' messages to other servers.
There are LOTS of things that you need to take into consideration. Here is an article which goes over the many considerations when moving into a distributed environment:
http://eralokpandey.wordpress.com/2010/03/31/load-balancing-in-asp-net-and-web-farm/
I am making a project for the university. When admission Starts, suddenly a lot of traffic comes at my site around 50000 to 100000 users. Site goes down therefore. How to manage it Please provide me details regarding this.
thank you very much
There are several different things you should look at:
ASP.NET Caching
Do you have a caching strategy? There are a lot of features in ASP.NET that will allow you to optimize how the server responds to requests. Take a look at:
http://msdn.microsoft.com/en-us/library/xsbfdd8c(v=VS.100).aspx
Load Balancing is really applied by the web server, not the server framework (ASP.NET / etc). If general opimizations and caching still give you problems, look into load balancing and web farms for IIS. Take a look at:
http://learn.iis.net/page.aspx/213/network-load-balancing/
If you have a lot of money, there are hardware solutions for load balancing that work with IIS. That's outside the provinces of programming and StackOverflow but it's helpful to know they are out there especially if you need to have a discussion with management about the pros and cons (expense!!) of which route to take.
I want to pass session from one application to other.
Like what gmail and orkut is doing, i want to do that.
Can anyone have some idea about how to do it?
Can it be possible without using any DB.
Assuming you want to control the entire pipeline - to accomplish this you need a centralized state server of some kind, which both sites can communicate with on the backend. For many smaller applications the database itself is used as a state server, but that is just one implementation of many. There are dedicated state server products, some free and some paid.
Even if both of your applications are on the same server, it's not possible with out-of-the-box ASP.NET functionality to share session directly because in-memory session is in process. However, running either of the two products listed above on the same physical machine as both your applications, and pointing both applications to that state server, will get you nearly there - it will be the same memory footprint as if they truly shared session, and the performance is extremely good (interprocess communication is blisteringly fast compared to network I/O).
Here is a more detailed description of the mechanics of a common authentication scheme between two or more sites.
What language are you using? If you are using ASP.NET on IIS, which I'd assume by your tags, you can do it using the machineKey attribute of <system.web> in the web.config file. It would look similar to this:
<system.web>
<machineKey validationKey="(here)" decryptionKey="(here)" validation="SHA1" />
</system.web>
Then, you can use the enableCrossAppRedirects="true" attribute on <forms> authentication type if you'd like the authentication keys to be passed between apps.
Also, if you'd like to generate a machineKey, you can use Scott Forsyth's tool at http://www.orcsweb.com/articles/aspnetmachinekey.aspx
Finally, as the first answer was posted, you can implement the ASP.NET state server for better control of the application's state. The ASP.NET team will be releasing Velocity soon which handles distributed caching. There are also third party tools for both.
Our company currently runs two Windows 2003 servers (a web server & a MSSQL 8 database server). We're planning to add another couple of servers for redundancy / availability purposes in a web farm setup. Our web sites are predominately ASP.NET, we do have a few PHP sites, but these are mainly static with no DB.
Does anyone who has been through this process have any gotchas or other points I should be aware of? And would using Windows Server 2008 offer any additional advantages for this situation (so I can convince my boss to upgrade :) ?
Thanks.
If you have dynamic load balancing (i.e. My first request goes to server X, but my next Request may go to server Y or Z), you will find out that In-Proc Sessions do not work. So you will either need sticky Sessions (your load balancer will ALWAYS send me (=my session) to server X) or out-of-process sessions (i.e. stored in an SQL Server).
Like Michael says, you'll need to take care of your session. Ideally make it lean and store out of process. You'll have similar challenge with cache depending on how you use it and might be interested in looking towards a more robust caching technology if you only use asp caching.
Don't forget things like machine keys and validation in your web.config. The machineKeys need to be consistant across your servers.
Read up on IIS7 and you should be able to pick out several good examples to show off to your boss.
A web farm can give you opportunities and challenges with deployment that should not be overlooked.
Without specifc experience to the setup above but to general moves of this kind. I would recommend phasing the approach. That is, move to Windows 2008 first and then farm.
One additional thing to look at is your deployment plan. Deployment plans seem to be sadly overlooked and/or undervalued. Remember that you are deploying to multiple nodes and you want to take into account how you want to deploy and test in a logical fashion.
For example, assume you have four nodes in your farm. Do you pull two out of the cluster and update and test, then swapping out the other two to repeat? Determine if your current deployment process fits in with the answer you provide. Just because you have X times the amount of servers does not mean that you want or need to do X times the amount of work.
Just revisiting the caching part of the conversation for a moment. You should definitely take a look at a distributed caching solution. If you are pre-caching data and using callbacks with cache removals, you can really put a pounding on the database if you are not careful. Also, a lot of the distributed caching solutions offer some level of session state management, as well. I have been very much enjoying Microsoft's Velocity project, although it is just a second CTP release and not ready for production.
In addition to what others have said, you might want to consider looking into Richard Campbell's (of .NET Rocks!) product:
http://www.strangeloopnetworks.com/
We use the ASP.NET State Server for handling out sessions. This comes free with windows server 2003/2008.
We then have to make sure the machine key's are the same (a setting in your web.config files).
I then manually take each site offline (using app.offline or whatever the magic file is called). Alternatively, u can use IIS and just turn the site off and the offline site 'on'.
That's about it. You could worry about distributed caching, but that's pretty hard-core stuff. You can get a lot of good millage out of the default Output Caching with ASP.NET. I'd start there, before you delve into the complexity (and cost, for some products) if you're going to do distributed caching.
Oh, we're using an F5 load balancer that does NOT do sticky sessions, so we need to maintain our sessions .. which is why we're using the ASP.NET state server.
One other gotcha aside from the Session issues described by the other posters is if the apps are writing to the local file system. Scaling out to a web farm would break the apps if they assume the files are on the local PC. For example, uploaded files might be available or not depending on which server is hit. Changing the paths to point to a shared drive should fix this.