We are building a large scale web platform where we try to use Caching to speed up things - though now it's a single server, we'll probably upgrade it to a cluster. Will the Caching work there? Should we consider anything special?
Thanks1
You will need to use a distributed cache. You can find implementations for different caching providers such as memcached or Velocity.
Related
Is it a good practice to use ESI's or is that an older technology? are there alternatives that would be better. I am familiar with the use of CDN's and cache servers but this ESI was typically for applications that do more than just load the front end.
ESI is fairly unknown outside the CDN context. However, I think there are a number of interesting use cases for its use 'closer' to the origin servers now that we see a lot more interest in splitting the applications that deliver Web sites into several self-contained services. An ESI-enabled cache is a good means to integrate these services into a single Web site.
Any recommendations for transition from single server to load balancing environment of 3 servers?
I considered using Sql Server session management, but I am storing linq2sql objects in session which has serialization issues. With a quick search I found a workaround .But I am skeptical to use this approach considering code-change/readability/performance issues. Any suggestions are welcome.
Just a suggestion : Can't you use sticky sessions in your load balancer?
We use memcached but it sounds like you want something to be a more critical portion of your app than just caching if you're placing LINQ to SQL objects up there (and I btw agree with RPM that you should consider getting out of that business...)
Anyway, this is a nice blog post that gives you a few options. Velocity is definitely one to look at since it's what Microsoft is offering (this is an asp.net app) and it seems to be gaining steam these days.
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
I needed to find a way that two applications can use the same cache, and after some quick research it seems that we will need a distributed cache to achieve this. Further Googling turns up a number of solutions, NCache, SharedCache, Velocity, memcached. This cache will be used for caching webpages in a Microsoft Enviroment using Asp.Net 3.5.
So my question is what experiences do you have with these, or other, technologies.
We have been using Memcached for some time now and it works like a charm. It is really stable and the overall performance is also pretty good.
You can make use of the "Memcached Providers" project at codeplex.com to easily integrate it with .net.
Depending on the solution you require a low-tech option might be to persist the results/data to a network share.
Then have each machine hold a cached version (perhaps use the ASP.NET cache or Enterprise Library) of the data with a corresponding cache dependency.
To answer your question I have heard excellent things about NCache and Memcached.
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.