Best practice: profile before adding memcached?

Paul Querna chip at
Mon Feb 5 01:28:45 UTC 2007

Marcus Bointon wrote:
> On 4 Feb 2007, at 19:22, Steven Grimm wrote:
>> I can't remember one time when I did detailed profiling and wasn't at
>> least a little surprised by the results. If you are having performance
>> problems it's almost always worthwhile.
> Though I agree with that (xdebug rules), there's another small factor.
> The way you write code knowing that memcached is going to be there can
> differ from how you might write it otherwise. In particular, some SQL
> query optimisations can work against memcache efficiency, and code
> optimised for memcache availability will often look bad in a profiler
> without it.

But, be careful of assuming that.  $work now has the issue that the
$site cannot survive even our most unloaded times without a full
memcache.  Reseting the memcaches, it takes 4-6 hours before the site
gets back to normal....

Yes, this is bad practice, and we need to scale our db tier better with
partitioning, but when we added memcache the whole partitioning plans
suddenly go way down in priority; memcache effectively 'hides' how
vulnerable you are.


More information about the memcached mailing list