Redis "volatile-lru" cache

[annehaley]

This PR bumps the version of large-image we use so that we can leverage the latest changes to its Redis cache. Since the cache entries will now have a TTL, we can use the "volatile-lru" max memory policy and expect that our redis cache can evict large-image tiles without evicting websocket connections.

See x and x. Resolves #398.

[brianhelba]

Why not just do this through the Django cache framework, which is the default for django-large-image?

[annehaley]

Why not just do this through the Django cache framework, which is the default for django-large-image?

We're currently using the Django cache, but in production when a user tries to visualize the boston orthoimagery layer for our example use cases, the web service with Django runs out of memory: Process running mem=895M(122.6%) Error R14 (Memory quota exceeded).

[brianhelba]

I see that after #404, the Django cache is being used, but it was never actually configured properly.

Per my suggestion, #404 needed to add something like:

LARGE_IMAGE_CACHE_NAME = "tiles"

CACHES = {
    "tiles": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": env.url("DJANGO_REDIS_URL").geturl(),
        "OPTIONS": {
            # Use database /2 for the tile cache,
            # in case other services use /0 in the future
            "db": "2",
        },
        # An arbitrarily long time
        "TIMEOUT": int(datetime.timedelta(weeks=4).total_seconds()),
    }
}

If we need to balance other cache considerations in the future, the configuration is well-documented by Django and we have all the local knobs (including the actual TIMEOUT) to adjust things.

[brianhelba]

Where do we control the Redis database number here?

We're using Redis for other things, so I think we should have local control of this.