We have a webform app that is ready for production. We found that SQL and Azure training kit's session state providers are not recommended for production code on Azure. We had no luck with TableStorageSessionProvider so far. Unfortunately, our client is not willing to pay for AppFabric Cache. Unless I'm misinformed I see no way to use AppFabric.
We do not use the session ourselves (removed all references to it), would you recommend disabling it or simply using the default provider?
Best regards,
Max
if you have no need for session, then it would be best to disable it. Default provider for session state is in memory of a single IIS server and you will likely have 2+ deployed in production. First it takes resources to keep it around, second it leaves an opening for someone in the future to accidentally use it during development w/o realizing overall implications.
HTH
Azure instances are not like any other IIS servers. In memory session data is NOT shared across multiple instances.
If you do not need session state, disable it. If you do, I would recommend checking out AppFabric Cache. We use the AppFabric Session state provider and it works great. If you're interested, this link will help get you started...
http://appfabricdemos.codeplex.com/releases/view/65427
Related
I have a session wrapper class in my ASP.NET MVC application that is used to store frequently used data (like current user info, supplier info etc) in Session. Session runs InProc. Everything works perfectly, but I know it is a bad design to have session in InProc mode as it is not scalable and it is tightly coupled to application pool. I didn't want to use Sql Server for managing sessions as it seems to be a last resort as speed is number 1 priority for us. So after doing a bit of research, it looked like Redis DB is the fastest option here (compared to MongoDB, RavenDB etc). I used this provider https://github.com/TheCloudlessSky/Harbour.RedisSessionStateStore. After implementing it as per instructions, it worked. But now I am getting occasional slow down of the site, where pages sometimes (probably 30% of the time) load very very slow. As soon as I switch it back to InProc mode it all runs fine. I wonder if I installed Redis incorrectly or there are some tricks that I have to do to make it run smoothly. Can anyone help? If you require bits of code, I can provide it, but it is pretty much the same as per https://github.com/TheCloudlessSky/Harbour.RedisSessionStateStore sample. CPU and Memory seems to be quite low and stable....
There was an issue with Redis provider Nuget package. Contacted package owner and new version was released which seems to work fine.
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 have a situation where information about a user is stored in the web application cache and when that information is updated in one application - I want to notify the other applications (running on the same machine) that the data should be removed from it's cache so it can be refreshed. Basically I need to keep cached data in sync across multiple asp.net applications.
I have started down the path of using a central web service to help coordinate the notifcations but it is turning out to be more complex than I think it needs to be.
Is there a way that one asp.net application can easily reach across to another on the same box to clear an item from the cache?
Is there a better way to achieve shared cached information than using the application cache?
I really want to create a way for apps to communicate in a loosely coupled way - I looked at nservice bus but the dependency on MSMQ scared me away - my client has had bad experiences with MSMQ and does not want to support an app that requires it.
Suggestions?
Michael
I agree with Hogan. Best is to use a shared database. I want to add to that that, when using SQL Server, you can use SQL Cache Dependency. This SQL Server mechanism allows notifications to applications in such a way that used caches can be invalided directly after a change is made to the data.
A shared database is probably going to cause you the least pain.
Edit
Note: ASP.NET allows you to make "cache clearing" triggers on SQL server changes. Should be a quick search in the cache examples on MSDN to find some examples. Thus when the user info stored in the cache changes in the DB the local cache copy will clear and be re-loaded from the DB.
There are commercial distributed caches available for .net other than Microsoft Velocity - NCache, Coherence, etc.
How about Velocity? It's a distributed cache that works between servers as well as between applications. It has PowerShell management and all sorts of documentation to get you going faster and be far more maintainable in the long-term.
What about COM/DCOM, using namespace System.Runtime.Remoting
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.
I want to add a scheduled task to a client's ASP.NET app. These posts cover the idea well:
https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
What is the Best Practice to Kick-off Maintenance Process on ASP.NET
"Out of Band" Processing Techiniques for asp.net applications
My question has two parts: First, will IIS unload the application if there isn't enough request activity despite the Cache activity? My client doesn't enjoy as much traffic as stackoverflow so they can't rely on user requests to keep the app 'active'. Obviously, I can't schedule tasks in an unloaded app.
Second, if so, is there a way to prevent IIS from unloading the app outside of configuration or external 'stay-alive' requests? My client's host doesn't allow much configuration tweaking and a stay-alive utility introduces the deployment complexity I'm trying to avoid with an ASP.NET Cache solution.
Thanks a bunch.
Edit/Conclusion: TheXenocide's solution is exactly correct given the question. However, I've decided it is a really bad question. The temptation to cut corners is always looming. I've regained my senses and told my client to use a website monitoring tool to keep the site active. In addition, the scheduled task is going in a windows service despite the extra deployment hassle.
Unfortunately, outside the range of changing timeout configuration (which I believe to be possible in Web.config, though I don't know what is and isn't allowed on hosting providers, most of which use Medium Trust) I don't believe there is any other method to keep the application from ending beyond web requests. One thing you might try that may be a little more simple than using some keep-alive service on a local machine might be to add some logic to Session_Start/Session_End that ensures there is always at least one session active; you can use the WebRequest class from within your application to call your own site and it should still start a new session.
Good luck, and let us know what you do :)
UPDATE: these details now very much depend on which version of IIS and which version of .NET you're running in. Newer versions of each have methods of configuring "always running" applications.