I've implemented a caching interface and memchanged provider for our website using enyim. Works great in testing until we get to load testing, where it spikes the CPU of w3wp.exe to near 100%. We have a configuration property to switch the caching provider back to dotnet's API and the CPU goes back to 5-7%. Has anyone experienced similar?
+1
A:
Every time you store something in memcached through enyim, the .NET runtime will perform binary serialization on the stored object. And deserialization when you retrieve. For some types (string, byte[] and some more), enyim implements a more specific and light weight serialization, but most types are serialized by the standard BinaryFormatter. This is processor intensive.
It especially hurts when your code is written towards the in-memory cache in ASP.NET. You will probably have code that thinks that getting something from cache is free. You may get it from cache again and again and again. We had comparable problems when we switched to memcached. If you do some profiling, you'll probably find that you do insanely many reads from cache.
Our experiences with the enyim client have been very positive. We run memcached in an ASP.NET server farm on around 10 nodes and it is very stable. For some forms of data (very often accessed), we prefer the in-memory in-process caching of ASP.NET.
Teun D
2009-08-12 07:27:29
Can you please explain what a memchanged provider is? I thought memcached was in memory only, no serialization to disk. Thanks!
Jacko
2010-08-08 13:52:19
Correct, memcached is entirely in-memory. But when you send .NET objects over the network to your memcached server, you'll have to convert your in-memory presentation to a wire-presentation. Serialization is not always to disk, it means to convert your objects (a graph) to a serial presentation (i.e. a sequence of bytes). Oh, and where I said "we prefer the in-memory caching", I should have said "we prefer the in-process caching"
Teun D
2010-08-13 12:38:28