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'
--
You received this message because you are subscribed to the Google Groups
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
