Django persistent memcached connections

Recently we diagnosed an issue for several of our customers who were using the python Django web-framework. They were all experiencing performance issues and a reasonable amount of broken connections to our servers. The issue was that by default Django uses a new connection to memcached for each request. This is terrible for performance in general, paying the cost of an extra round-trip to setup the TCP connection, but is far worse with cloud-services like MemCachier that have an security layer and require new connections to be authenticated. A new connection to a MemCachier server takes at least 3 round-trips, which increases the time to execute a single get request by 4x.

It turned out this situation is the result of a very old and long-standing bug in Django (#11331). This bug arose due to a incorrect fix for another bug that Django had, one where it could continually create new connections to the memcached server without ever closing any of them until it eventually consumed all the available file descriptors at the server. Unfortunately this fix for this file descriptor leak was to simply close the memcached connection after all requests.

Thankfully we can fix this by monkey-patching Django and disabling the close method of the Memcached class. The best place to do this is in your Django wsgi.py file, inserting the code below before you create your application:

That is, the full file may look something like follows:

We’ve advised several customers to use this fix and they’ve had great results! We will soon be adding it to our docs as a recommended practice for Django.