whlply2
asked on
Worried about stale data while using Microsofts Caching Application Block in a web farm
We are currently using Microsofts Caching Application Block (June 2005) to cache items such as dropdownlist box options in a .NET 1.1 website. We use the default Null Backing Store for the Caching Application block. We recently moved to a web farm and are worried about stale data. We are using load balancing in a round-robin fashion. There are possibilities for stale data depending on which web farm node you hit. I was told the enterprise library caching block does not support a web farm out of the box. Should I modify the Microsoft Caching Application Block setup or do you recommend a 3rd party solution like NCache? I'd prefer modifying the C.A.B. but if I have to purchase NCache I guess I have to. I'm guessing many other developers have come across this problem. Please let me know what you recommend. Thanks in advance!
By the way, I asked Microsoft already and they recommended the following:
* Continue to use the June 2005 Enterprise Library with the Caching Application Block.
* Switch from the Null Backing Store to the Database Backing store.
* Set up a custom database notification with SQL Server 2005 notification services. This will help notify the different web farm nodes to expire their cache if a change is made.
* Set a more realistic expiration policy. We currently have expiration set to 10 minutes but 30 or 60 minutes would be better. After all, one of the primary considerations for caching data is when the data doesnt change very often.
One small caveat to this approach is there is still the possibility for a small staleness factor. Our business sponsors will need to be aware of this factor and decide if its acceptable. The Microsoft rep agreed.
Should I stick with this Microsoft solution, choose NCache, or go another route? Any help is appreciated.
By the way, I asked Microsoft already and they recommended the following:
* Continue to use the June 2005 Enterprise Library with the Caching Application Block.
* Switch from the Null Backing Store to the Database Backing store.
* Set up a custom database notification with SQL Server 2005 notification services. This will help notify the different web farm nodes to expire their cache if a change is made.
* Set a more realistic expiration policy. We currently have expiration set to 10 minutes but 30 or 60 minutes would be better. After all, one of the primary considerations for caching data is when the data doesnt change very often.
One small caveat to this approach is there is still the possibility for a small staleness factor. Our business sponsors will need to be aware of this factor and decide if its acceptable. The Microsoft rep agreed.
Should I stick with this Microsoft solution, choose NCache, or go another route? Any help is appreciated.
ASKER
We are not using DNS round robin. Our network engineer said that we are currently using NLB (Network Load Balancing) with round robin. I don't know a lot about load balancing so I can't validate if that's a possible configuration. He mentioned that we could switch to use Round Robin DNS only (without load balancing). This may alleviate the caching problem because once a user logs in all future requests will go to the same server. His recommendation is NOT to go that route because Application traffic is random based only on DNS. Also when one server goes offline, requests will still attempt to go to that server until a DNS entry is removed (users may need to clear their cache or reboot their local workstation).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I will talk with him about using affinity in the NLB and get back to you.
ASKER
Your suggestion has helped but there is still a small possibility for stale data. If the user logs off the website and opens a new browser window they could get stale data. There needs to be a solution that invalidates the cache on all web server nodes when one of the webserver nodes has its cache updated. Any suggestions for this?
Microsoft's suggestions are excellent. If you want to optimize peformance with the farm and the DB you can put dual NIC's and two subnets using two switches. The front plane would have one NIC in each web server working in the NLB subnet. The back plane using the other NIC in each web server on a different subnet would be connected to the DB server. It's a good way to separate the traffic to prevent collisions.
ASKER
That's not really the solution I'm looking for but I'll accept your prior solution regarding the affinity setting. Changing affininty to the default on NLB has helped stablize the environment. There's still a possibility for stale data but I'll revisit if any end-users start to complain.
In regard to NCache, try to get some customer testimonials.