

Server Density removes Memcached because it's "too slow" - nphase
http://blog.serverdensity.com/2012/05/11/removing-memcached-because-its-too-slow/

======
justinsb
While I do agree that a good database can replace memcache in certain
circumstances, isn't a 24ms response time from memcache a pretty good
indication that something is seriously wrong there?

I'd expect <1ms, if your network allows you to get that from Mongo

~~~
relix
It seems to me that the 24ms was the whole process they were using, i.e. put
data in memcached, take data out using a seperate process, and put data in
mongodb; versus putting the data straight into mongodb.

~~~
1SaltwaterC
Nope. From those metrics, Memcache is using all that time by itself. New Relic
breaks down the network map based on distinct services. The database layer has
a separate entry.

~~~
rfurmani
I had a similar issue with my Django project on Heroku. My site performance
went down once I enabled memcache, almost entirely due to latency (going up to
100ms at times). This is one of the reasons why I ended up moving off of
Heroku and onto an EC2 instance: now I have full control of my stack, I can
run what I want locally on the server, and I'm getting much better performance
(nginx+gunicorn+memcached+django+johnnycache+rds)

~~~
1SaltwaterC
I'm not affiliated with the OP. I maintain my own stack on EC2 due to very
specific application requirements. However, something is suspicious if the
latency goes up so much due to Memcache alone.

------
sauravc
The title is pretty stupid not to mention misleading. 24ms to talk to memcache
means "they're doing it wrong".

