Use redis for raster tile caching

[annehaley]

Our current prod deployment is not able to serve raster tiles because the Heroku web dyno exceeds its memory threshold trying to respond to those tile requests. The requests receive a 503 Service Unavailable response and the layer does not appear on the map.

In an effort to offload the large_image cache from the web dyno, this PR specifies that large_image should use redis for its cache.

EDIT: The section below no longer applies. I had done that at first, but now the cache backend can be declared with settings.

To accomplish this, the cache config vars are set in the local app's ready function to override where django_large_image sets the cache method: https://github.com/girder/django-large-image/blob/8ec012dada25286f24f3e1ed4db325cbb2100e02/django_large_image/apps.py#L18. The django_large_image app must be installed before the local app to ensure that the ready functions are called in the correct order.

[BryonLewis]

I could confirm using the redis-cli MONITOR inside the container that it was properly being used to cache data from django-large-image.

I don't know if this is going to solve all memory usage issues. Using docker stats <container name> I tried both with and without redis with both the Elevation and Imagery data.

Without redis I could see nearly 10-12GB of memory usage when zooming in and out (very close and dragging around)

With redis it was closer to 7-8GB. I didn't have a repeatable test so these results may vary. It's good at least that we have it connected to the redis service because before I don't think it was doing anything.

[brianhelba]

We have the ability to just make changes to django_large_image, since this is the only project using it. Let's use this opportunity to add new Django settings to django_large_image to configure these properties, without having to mess with the app load order.

[annehaley]

We have the ability to just make changes to django_large_image, since this is the only project using it. Let's use this opportunity to add new Django settings to django_large_image to configure these properties, without having to mess with the app load order.

Alright, I wasn't sure if it was appropriate but if we're the only users, we might as well. Should we just default to redis if the DJANGO_REDIS_URL env var is defined?

[brianhelba]

We want to use settings to configure Django things, so django_large_image should look for some settings.LARGE_IMAGE_CACHE_BACKEND setting (practically this might be fetched there as getattr(settings, 'LARGE_IMAGE_CACHE_BACKEND', 'django'); likewise for settings.LARGE_IMAGE_CACHE_REDIS_URL.

Then, our project just sets these in in settings/base.py (the source of some information at that point can certainly be an environment variable), which will happen before the django_large_image app is loaded (so there's no tricky app ordering issues).

[annehaley]

After making upstream changes (PR & release), we can now specify the cache backend with settings. I upgraded the version of django-large-image we use and defined the relevant settings.

[brianhelba]

So easy now. 😎