-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add consistent caching layer for templates #1489
Comments
Hey @maruel! Thanks for your feedback/proposal. I want to make sure I understand it completely.
This is true, although right now I'm leaning on OS/FS optimizations to make load times better. I think Go uses Unix sendfile, doesn't it?
This... I don't believe this is true. Template files are loaded and parsed at request time, not startup; I was using templates yesterday and saving them and reloading the page was working great for me... 😶 Here's the relevant code: https://github.com/mholt/caddy/blob/0a0d2cc1cf12d58c5e38680689c78f18044288e6/caddyhttp/templates/templates.go#L48-L60 So while I can see why the first goal will be a valuable feature in Caddy, does this render the second goal obsolete? Anyway, if I understand the rest of your proposal right, we wouldn't need to touch templates (?) but just add a caching mechanism to the static file server. This could be configured (enabled) with a directive in the Caddyfile. Questions:
(This reminds me I want to propose a proxy caching feature as well. But that's for another issue.) |
Hi @mholt ! Clarifying a few things:
The current template caching behavior is surprising IMHO so I renamed the issue to focus on the templates.
|
I migrated from |
Thanks for clarifying. I'm beginning to agree. markdown should probably parse the templates at request-time (and then cache them, as you're proposing; that should help with performance). I'm booked up for a while but anyone is welcome to tackle this! If the templates and markdown directives share any logic, try to make the code common between them. Maybe caching is something that the |
@maruel Good news, we've got an official cache middleware started here in the v2 branch (Caddy 2 is currently in beta): https://github.com/caddyserver/caddy/tree/v2/modules/caddyhttp/httpcache It is suitable for any HTTP response, not just those from templates. It's a working, simple PoC right now but I'd love some help getting it finished. Can you give it a try and we can work on it together? |
Hi! What would be the best avenue to discuss the design choices? I don't promise anything else, but at the very least a discussion about the design trade offs would be good. |
@maruel Either here, or if you want some tighter feedback, I can invite you to our dev Slack. As long as we summarize what we decide here it should be fine. Want me to send an email to the address on your GitHub profile? |
Observations:
Since it's fairly involved to get everything right, maybe file separate github issues? |
Good point, I'm totally in favor of this. I just whipped it up real quick as a PoC and we need something better. Would anyone have a chance to do a quick comparison of which serialization is most efficient? We don't need type information embedded into the serialization, necessarily, since we have a very specific case of just a map of strings. Honestly, we could probably even roll our own VERY simple serialization format that just concatenates each header field. It's for internal use only, so a general-purpose serialization might be overkill.
One advantage we have here is that the cache can be added anywhere in the middleware chain. We can, for instance, add it before the gzip handler, so by the time the response comes back to the cache handler to be added to the cache, it is already compressed. :) So, this might already be done by default due to Caddy 2's architecture!
Agreed, and specifically what is allowed to be cached needs to be very finely controlled and configurable, so we'll have to expand on this.
Yes, definitely. Feel free to split this into a new issue to continue discussion on whatever part you think we should work on first! |
Moving discussion to new repo dedicated for the caching layer: caddyserver/cache-handler#1 |
Problem statement
root
occurs in a Caddyfile, all files in this directory are opened at each request, making it much slower than necessary.templates
, all the files are cached on process startup and modification on the files are not detected.This is different from issue #10 which is to cache external data and issue #390 that wasn't focused.
Goals
Action items
It is possible I misunderstood the design and that the AIs are incorrect.
The text was updated successfully, but these errors were encountered: