Is there anyone already implement memcached for production use in Windows environment? Because many blogs that I've read, it's not recommended to run memcached in Windows especially for production use, for example running memcached on windows.
And one more thing, which memcached client that is good to use with c# and .net 3.5 ? I've found many alternate such as Memcached Providers @ Codeplex, Beitmemcached, and memcached provider @ Sourceforge
Why do you need to run memcached on windows? It’s an expensive affair in a production environment.
If your code needs to run in a Windows environment get a windows memcached client and talk to a *nix based memcached machine.
In a production environment running memcached on Server 2003 or 2008 would mean that you get licenses for all those boxes. Linux will offer you all the OSS benefits. TCO will rise linearly with memcached on Windows
Edit:
It’s been around 1.5 years since I wrote this answer and lot of things have changed since. You’ve to take notice, especially when someone like Dustin comments.
So here’s how you can get memcached on windows running. Download memcached for windows from Couchbase (formerly Northscale).
Typically if you plan to run memcached on the same production machine you’d want to start it in limited memory, i.e. define the maximum memory memcached is allowed to use.
c:\Program Files\memcached>memcached.exe -m 128.
Here memcached runs with a maximum of 128 mb usage. You don’t want memcached to take up all the memory on your webserver.
The moment you decided to scale out memcached you’ll need to consider what I said earlier. Additionally compress your values in the key value combinations. Web servers typically consume very little CPU (2-3%) usage and compression brings in a lot of value to network throughout in comparison to the CPU usage. If you are too concerned about normal compression, try LZO
Since Velocity didn't exist at the time, I used a memcached port to Windows for the company that I work for, Skiviez. It mainly only exists to provide a centralized cache for multiple worker processes on the same machine. It's been running fine about 18 months now on an e-commerce site that sees modest use (~18,500 hits/day). The client that I used was Enyim integrated as a cache provider for iBATIS.NET. That client seems to work well enough; memcached clients are not very complicated to begin with, either.
If I had to do it again, I'd probably look at Velocity if I was committed to remaining on Windows for my distributed caching solution. But it's working now, so I'm not going to touch it.
(Aside: Since then, I negated most of the need for the cache by adding certain Cache* columns to key tables in the database that are updated by a scheduled task every evening. This ended up putting much less strain on resources all around, from the initial hit in CPU time by querying the database to the subsequential strain on memory availability by keeping the cached results sitting in memcached. It also made it much more explicit in the code when a cached version of the data is being accessed versus a calculated-on-the-fly version. I'm sure you have lots of reasons to use a distributed cache, but it's always worth a shot to take a step back and question whether or not you really need it!)
i don't know what the project you're working on is, but you might like to take a look at the Microsoft Velocity project From the page:
"Velocity" is a distributed in-memory application cache platform for developing scalable, high-performance applications. "Velocity" can be used to cache any common language runtime (CLR) object and provides access through simple APIs. The key aspects of "Velocity" are distributed cache performance, scalabily, and availability.
I've seen a couple of demo's and it looks like it has really nice integration with .net framework.
The problem with the client API's is that you still have to have an instance of memcached running on another box somewhere preferrably as you've noted, using the LAMP stack. Using velocity means you're still going to be running on the same stack and there's tighter integration across the .net platform.
Having said that, if you want to use velocity as a cache for other .net applications you might find yourself having to write your own API to expose the velocity data for consumption.
Velocity is a bit more involved to administer, but it is far, far more powerful then memcached. I am not anti-memcached, not in the least bit, it is great. But moving forward, new projects that are pure .NET based are crazy not to leverage Velocity, even in its current unreleased state.
have a look at SharedCache. its open source, easy to use and very reliable.
high-performance, distributed memory object caching system, generic in nature, but intended to speeding up dynamic web and / or win applications by alleviating database load. Don't forget to visit us at http://www.sharedcache.com
The problem with the client API's is that you still have to have an instance of memcached running on another box somewhere preferrably as you've noted, using the LAMP stack.
Not at all true. The LAMP (Linux, Apache, MySQL, PHP) stack is not required to run Memcached. I currently prefer memcached over velocity until velocity is out of CTP. I've played around with velocity for a bit but found it too unwieldy. I follow that whole KISS thing, you know... keep it simple. Nothing simpler than caching... Get(key)... Put(key, value)... Destroy(Key).
