How do I limit the size of the cache?

[grishka]

I'm trying to translate this nginx config to Caddy: https://github.com/grishka/Smithereen/blob/4dcad9dd968b2ae6be04281d6a9ca72d13d4cfc8/examples/nginx.conf

This works but doesn't do so optimally because it would hit imgproxy every time a client requests a resized image:

smithereen.local

encode

# Static files
handle /s/* {
	root /var/www/smithereen
	file_server
}

# imgproxy
handle /i/* {
	reverse_proxy 127.0.0.1:4560
}

# Server application itself
handle {
	reverse_proxy 127.0.0.1:4567
}

So I started looking into replicating my nginx setup, where I cache the images processed by imgproxy, and this plugin seems to be the way to do cache on Caddy. Except I couldn't find a way to limit the cache by the combined size of all cached responses instead of the time, so least-recently used responses would get deleted to make room for new ones. Ideally I would just not have any expiration component whatsoever to my caching strategy, but nginx can't do that so I set the TTL to 10 years.

Does this plugin not support this sort of LRU strategy, or did I overlook it? The docs all only talk about the expiration time.

[darkweak]

Hello @grishka, the default storage doesn't have any LRU eviction strategy. You should use another one that is production ready like otter for in memory or go-redis if you want to store the responses in redis. e.g.

xcaddy build --with github.com/darkweak/storages/otter/caddy --with github.com/caddyserver/cache-handler

And use it in the caddyfile

{
    cache {
        otter
        ttl 87600h
    }
}

smithereen.local

encode

# Static files
handle /s/* {
        cache
	root /var/www/smithereen
	file_server
}

# imgproxy
handle /i/* {
        cache
	reverse_proxy 127.0.0.1:4560
}

# Server application itself
handle {
        cache
	reverse_proxy 127.0.0.1:4567
}

[francislavoie]

@darkweak otter is missing from the README Caddyfile examples & providers section

[jenjen75]

Hello @darkweak ,

I migrate from nginx to caddy with cache-handler. I struggled to understand why there is a memory leak. It's good to know that the default storage doesn't have LRU. Maybe it could benefit for other people, to tell in readme that the default storage is for dev only and not for production ?

I thought the default memory storage is production ready like nginx, and the others storages are optional.

Hello @grishka, the default storage doesn't have any LRU eviction strategy. You should use another one that is production ready like otter for in memory or go-redis if you want to store the responses in redis. e.g.