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.
On Thursday, August 31, 2017 at 12:08:56 PM UTC-5, Michael Ryan wrote:
>
> 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.
