DRF views not cacheing in basic memcached configuration

[Michael Ryan]

Hi There,

I'm working on a pretty vanilla implementation of DRF along with memcached in a production environment and running into some peculiar cacheing behavior isolated to DRF.

In short, Django's cache middleware seems to be chugging along just fine on normal django views in my application, but in DRF views, there is a cache miss in 100% of circumstances.

This behavior is unique to my production environment/memcached (apparently), because if I repeat the test case locally with the Django dev server (and its accompanying built-in cache behavior), then DRF page cacheing works as expected (aka, quite well).

I've dug into memcached -vvv logs and what I have noted is that when accessing one of the DRF views in question, there doesn't seem to be any attempt by the cacheing middleware to store the result of the DRF view in the cache. Therefore it's always a cache miss on subsequent requests.

Consider the following memcached trace on a "regular" django view from elsewhere in my application

An attempt to store the view results (note the size of the data)

<26 set :1:views.decorators.cache.cache_page.redacted.GET.f97725a0a5c8f8db945f73759fee43cb.20274088b4d81bbef05d64e9397cc395.en-us.America/Chicago 1 600 1021371
26: going from conn_parse_cmd to conn_nread
> NOT FOUND :1:views.decorators.cache.cache_page.redacted.GET.f97725a0a5c8f8db945f73759fee43cb.20274088b4d81bbef05d64e9397cc395.en-us.America/Chicago
>26 STORED

A successful attempt to retrieve

<26 get :1:views.decorators.cache.cache_page.redacted.GET.f97725a0a5c8f8db945f73759fee43cb.b9ee24c6b071b1277b190e6563bdcbc1.en-us.America/Chicago
> FOUND KEY :1:views.decorators.cache.cache_page.redacted.GET.f97725a0a5c8f8db945f73759fee43cb.b9ee24c6b071b1277b190e6563bdcbc1.en-us.America/Chicago
>26 sending key :1:views.decorators.cache.cache_page.redacted.GET.f97725a0a5c8f8db945f73759fee43cb.b9ee24c6b071b1277b190e6563bdcbc1.en-us.America/Chicago
>26 END

Expected behavior, proven to work.

 In the DRF view, I never see this pattern, or even an attempt. Instead what I see is something like this:

<26 delete :1:views.decorators.cache.cache_page.redacted.GET.6ca1afcdf99ddab12e7e739e410fd63e.c8d0ca3093920eb43b928a4b842a96da.en-us.America/Chicago
> NOT FOUND :1:views.decorators.cache.cache_page.redacted.GET.6ca1afcdf99ddab12e7e739e410fd63e.c8d0ca3093920eb43b928a4b842a96da.en-us.America/Chicago
>26 NOT_FOUND

It seems to be trying to aggressively delete the cache at roughly the moment I would be expecting it to try and cache the result it just finished computing. There is never a SET command for the result.

I'm sure this is a simple configuration error, but when you get this far in the weeds, Google starts to fail on you...

Anyone know where I should begin to decipher this?

Also, my setting.py cache settings:

CACHES = {

        'default': {

            'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',

            'LOCATION': '127.0.0.1:11211',

        }

    }

    CACHE_MIDDLEWARE_ALIAS = 'default'

    CACHE_MIDDLEWARE_SECONDS = 600

    CACHE_MIDDLEWARE_KEY_PREFIX = 'redacted'

[Michael Ryan]

Hello. Please disregard and close. I was able to conclude that the issue was a missing django settings.py key to expand the maximum cache object size. This was causing django to quietly never attempt to cache the page in production.