this post was submitted on
12 points (87% like it)
14 up votes 2 down votes

reddit is a source for what's new and popular online. vote on links that you like or dislike and help decide what's popular, or submit your own!

all 20 comments

[–]enkafan 9 points10 points ago

those still using System.Web.Caching might want to take a look at System.Runtime.Caching in the 4.0 framework.

[–]birdhost 4 points5 points ago

I've been using MemCacheD with the Enyim client to cache across multiple applications.

There's a 1MB limit on the size of objects you're caching. I think some clients have ways to split larger objects across multiple cache keys to get around that limit, but I've never needed to.

[–]jrapp 2 points3 points ago

This is what I use, too. I use the MemCache server from Couchbase. It's a love/hate relationship. It seems that if I don't explicitly mark my classes as Serializeable() then they never make it into the cache.

[–]wizzfizz2097 1 point2 points ago

I've been playing around with memcached and enyim recently too, but will probably have to ditch it because we need cache dependencies. I tried implementing the algorithms myself but I guess I'm not that smart =)

[–]Aljavar 0 points1 point ago

Have you looked into namespacing prefix keys stored in cache? This entails storing a prefix value (any value really) in the cache and then changing the prefix to break the dependency. For example, you could store a prefix key of "1" in the cache and use this to store values under other keys as "1_Name" or 1_color". The "1" key could later be updated to a value of "2" (or some other value) which would mean future lookups would find no values set since they would be looking for "2_Name". Not sure if this is the type of "algorithm" you were speaking of.

[–]Aljavar 0 points1 point ago

Same here. Actually using this on Amazon AWS. Abstracting caching so as to move between no cache (local/testing), in memory cache (by environment) and external caching (staging and production) seamlessly was a must. The default caching system is not abstract nor configurable for these purposes.

[–][deleted] ago

[deleted]

[–]NoddysShardblade 2 points3 points ago

Agreed. I've never been in a situation of needing to add caching to something, but seen plenty of systems where some "genius" reinvented their own broken implementations of System.Web.Caching, adding many days of expensive programmer time to bug fixing and feature adding.

[–]hlthybodysckmnd[S] 1 point2 points ago

That's one of the reasons I ask the question. What factors made you choose the solution you have, did the decision end up working out, etc...

[–]Manitcor 5 points6 points ago*

I will try to hit this the best I can for you.

If you are in a single server scenario and NEVER care to do anything else in the near term (say next 12 months), and have memory on the system running the site to handle your estimated persistent data load then System.Web.Caching used AS-IS should be fine.

Here are things to consider if you move beyond any of the above restrictions:

  1. If you think you may change caching strategies during the life of the system - You will want to put a simple pattern around your caching API calls. This will allow for easier upgrades or changes to other caching options in the future. Since caching api's tend to be build for that cache system and there is no standardization you want to do this to insulate yourself for big regressive changes across your code base when you switch from System.Web.Caching to say AppFabric caching.

  2. If you plan to have a web farm with more than 1 box serving the same application and you are not using sticky sessions. In this case you will want to move to a external cache store like AppFabric in order to give all systems in the farm access to the same data. Even with sticky sessions you may want AppFabric as you can use it to decrease common data loads and opens up the possibility to move to stateless web applications later.

  3. If you need very tight control over caching (such as TTL, expiration, sliding rules, update rules etc) then you may want to look at a more robust caching system than plain System.Web.Caching.

  4. If you want to do things like pre-load data on application start or even have backend systems capable of updating cache data that the front end system is using live then you will want something more powerful and flexible than System.Web.Caching.

I am sure there are some more I can think of given the time. If you would like a suggestion on what you can use please give me a somewhat high level idea of your application and what you are trying to do.

A bit about me(doing this to be taken somewhat seriously): 15+ year enterprise systems engineer and architect using Microsoft development tools and technologies since 1994. Currently working at a financial company with a 3-million user system based on MVC3 and .NET 4 with AppFabric in a web farm environment so this stuff is kinda at the top of my head right now.

[–][deleted] ago

[deleted]

[–]hlthybodysckmnd[S] 1 point2 points ago

IIS isn't going to be the problem in most situations where you need to cache data. IIS is actually going to be sitting idle waiting for data from the database. The performance hit is the time it takes the db to grab the data from disk as opposed to just pulling it out of memory.

[–]ours 1 point2 points ago

To choose a solution first measure performance and get a better idea of the problem you want to fix and have numbers to compare once you've applied a solution.

Look for places where you are often getting the same costly data. Then come up with a strategy for caching that data that fits.

Caching is very dependent on what kind of data you are caching, how volatile that data is, how often is it needed and so on.

[–]snkscore 0 points1 point ago

System.Web.Caching is what I use.

And page output caching.

[–]Chrono803 0 points1 point ago

This may be my entry level experience speaking here, but didn't some people use WeakReference as a way to cache small amounts of data?

[–]pranavkm 1 point2 points ago

A custom implementation of a cache could use a weak reference since it means you could GC the object under memory pressure without having to bother about the reference in whatever structure you're using to keep track of cached items. However, a WeakReference by itself isn't going to get you much.

[–]hlthybodysckmnd[S] -4 points-3 points ago

That sounds like a dumb idea. What would be the point of that?

[–]Jdonavan -1 points0 points ago

Congrats on being the first person tagged by me as "ass" in this subreddit.

[–]maskaler 0 points1 point ago

We opted to redesign our db model at a point at which we felt we fully understood the domain (having built the previous one over several sprints creating a mess). With that we don't have the need for caching as responses are small and speedy as a result.

A side note is that we built the new service using the OData / WCF Data Services stack and get some benefits from browser caching as a result.

[–]N7-Legion 0 points1 point ago

Has anyone tried using Redis for caching? Especially in a Windows/IIS environment?

I have heard so many good things about it but haven't had the chance to try it out yet.

[–]xebus 0 points1 point ago

Redis is an interesting caching solution. If re-populating cache is expensive, Redis persistence (or memcacheDB) is an excellent & highly performant way of doing so.

I think the question of what to use really depends on the organization. Some shops will only use MS-certified solutions. Others are more open to OSS approaches.

[–]N7-Legion 0 points1 point ago

Unfortunately, that's a downside of working in bigger corporations. Whether it's MS or Oracle or someother company, you somehow end up getting stuck using their technologies even if they are not the best solutions.

Luckily my organization is not that tied to MS technologies. I mean we are .NET shop, but we have gone outside of MS for lot of stuff (NuGet and even ASP.NET MVC have made it a lot easier). Redis is one that we want to try out but we haven't found a good resource for how to run it in a Windows environment. At least not one that seems ready for production use.