Announce: New http cache plugin

:grinning:default_max_age Default: 5 minutes: :+1:

Hi @nicolasazrak ,

I am currently trying to get your plugin working. For my demo website I enabled it by using just the cache directive:

site.com {
    root /var/www/site.com/build
    gzip
    cache
}

This works but it “feels” slower. However it is just using static assets so I was sure that this could only add overhead. However I can not find any cached files on my system.

I added:

site.com {
    root /var/www/site.com/build
    gzip
    cache {
        path /tmp/caddy-cache
    }
}

with caddy-cache being a folder created in /tmp with chmod 777 for the caddy user as well as owner and group set to the caddy user. This leads to an error 500: “Internal Server Error”.

When I change the path to /home/myuser/caddy-cache (same setup as above) it crashes all my websites although systemd is reporting that caddy is up and running without any problems.

Is there something that I am doing wrong? Was this plugin intended to only cache proxy responses?

Thanks in advance
Kevin

@kekub cache is not really useful with static content, because to serve content it’s pretty similar. It might be a little bit faster because it keeps the file descriptor open but the difference is not big. Although it works (because it is independent from where the data came), it is more useful when you have slow responses, for example: the ones that come from an app server with a slower language.

About having 500 errors, that is really bad, it should not happen, even less crashing caddy. Please open an issue in github.com/nicolasazrak/caddy-cache/issues Are you using other plugins? Is that your full Caddyfile? Do logs show anything?

I have a slow hdd in my server and want to cache some of the files on a ramdisk.

I will open an issue within the next days. My Caddyfile is quite big as I have about 10 mini sites on that server. I did not see any logs but I will try check in detail.

Make sure you’ve enabled the error log (errors directive) and the process log (-log CLI option). :slight_smile:

re-visited http.cache with source built Caddy 0.10.9 and http.cache proxy caching still helps for index.html h2load HTTP/2 HTTPS testing though still slower than non-cached Nginx results https://community.centminmod.com/threads/caddy-http-2-server-benchmarks-part-2.12873/#post-54715

Tested Caddy source build with GCC 4.8.5 and GCC 7.1.1 on CentOS 7.4 on 2 cpu OpenVZ 2GB RAM/50GB SSD VPS.

caddy-vs-nginx-h2load-http2-loadtests-160917-06

2 Likes

Thanks for the bench. Nginx will always be faster because it’s written in C, second they are developing since 2004.

2 Likes

Yes Nginx has a earlier head start. This highlights why sharing and encouragement of benchmarking both official and source compiled Caddy binaries should occur Caddy EULA section 3.1 h - benchmarking info clarification?. How else do you continually track Caddy’s development progress in terms of performance and regressions over time ? :slight_smile:

1 Like

Yeah, you have a point. Matt should ease the restriction for pre-built binary. Anyway, the new tool Caddy-X (to be released) should ease the deployment.

1 Like

Regarding building of any version; if you’re going for speed, these might help? Not much of a Go-coder (yet).

1 Like

Cheers @unquietwiki not much of Go person myself either. If someone can whip a guide for setting up Caddy with profiler, I’ll start including profiler info in my future benchmarks too :slight_smile:

1 Like