Untitled attachment

Notices where this attachment appears

1. Embed this notice
   毛茸茸生长 :trans_flag: (bgme@bgme.me)'s status on Saturday, 16-Sep-2023 22:59:12 JST 毛茸茸生长 :trans_flag:

   in reply to

   @kt
   最后附上我折腾 Caddy cache 的经历。

   --------

   Caddy 2 目前可以使用的缓存模块有两个 http.handlers.cache （ https://github.com/caddyserver/cache-handler ）、http.handlers.http_cache （ https://github.com/sillygod/cdp-cache ），但均是非官方模块，Caddy 2 自身并不支持缓存。
   如果你因为一些需求，比如说反代S3媒体库，需要用到缓存功能，Caddy 2 就……
   一个反向代理，连缓存都不支持，多少有一点嘈点满满。

   下面再说一说这两个非官方的缓存模块。

   http.handlers.cache 基于 Souin cache，存储后端支持 Badger、NutsDB、Etcd、Olric、Redis，值得注意的一点是该模块并不支持像 Nginx 那样的 filesystem cache。

   后三个都是 in-memory cache ，内存消耗巨大，本人只尝试使用过 Olric （因为支持 embedded olric 无需额外安装软件）。
   embedded olric 不知道为什么，内存消耗特别大，测试时缓存 nitter 媒体文件，请求了大约1000个文件，传输流量140MB，Caddy的内存占用就已经达到了1.5GB。继续测试，发现Caddy的内存占用基本上是按请求流量十倍大小来算的。

   前面两个 Badger 与 NutsDB 都是KV数据库，算是 filesystem+memory 的 hybrid cache 。
   但实际使用下来，问题多多。
   Badger 存在缓存污染问题，模块开发者自己都建议不要使用 Badger （ https://github.com/caddyserver/cache-handler/issues/27 ）。
   NutsDB 倒确实没有缓存污染问题，但却存在内存占用的问题。将 EntryIdxMode 设为 HintBPTSparseIdxMode，按 NutsDB 官方的说法『HintBPTSparseIdxMode 是专门节约内存的设计方案，单机10亿条数据，只要80几M内存』。但实际使用中却存在内存占用持续增长的问题。反代 img.bgme.me ，大约8个小时后，便 OOM Kill 了，OOM kill 时 total-vm:26129016kB, anon-rss:9457364kB。

   此外 http.handlers.cache 配置相当的复杂，一点都和简单易用沾不上边。

   再说一说 http.handlers.http_cache 模块。
   http.handlers.http_cache 倒确实是简单易用，也完全是基于文件的 filesystem cache。
   在实际使用中发现存在部分请求超时的问题。这是一个老问题，之前也有人提过 issue https://github.com/sillygod/cdp-cache/issues/24 ，按理来说应该也修复了，但在实际使用中我确实是又遇到了这个问题（caddy v2.7.0-beta.1 、cdp-cache v0.5.0）。感觉可能与请求并发有关，本地环境测试时并没有那么容易出问题，但放到生产环境中，便经常出现请求超时。
   另外，重启服务后该插件会令之前缓存的Key丢失，遇到相同请求时会再次请求上流。 https://github.com/sillygod/cdp-cache/issues/38
   此外，该插件并不支持 Nginx 那样设置最大存储大小。

   总之，目前 Caddy 并不存在靠谱的 Cache 方案。如果你因为一些需求，比如说反代S3媒体库，需要用到缓存功能，并不非常推荐使用 Caddy。

2. Embed this notice
   毛茸茸生长 :trans_flag: (bgme@bgme.me)'s status on Saturday, 16-Sep-2023 22:59:10 JST 毛茸茸生长 :trans_flag:

   in reply to

   @kt
   主要还是用的 Caddy。
   部分需要 Cache 的站点，比如说 img.bgme.me ，中间套了一层 nginx。

   还用 Caddy 有好几个原因：

   需要多节点间证书共享与管理时，Caddy 要方便很多。
   certbot+nginx 单节点的话还好。但如果我想四五个VPS，共用一张证书，certbot+nginx 就比较麻烦了。还要搭配一套独立的证书管理与分发系统。
   Caddy由于模块化的设计（多种存储后端），以及自动证书管理功能，多节点共用证书就方便多了。
   只需要多节点配置为同一个存储后端（如 redis、dynamodb），就OK了。

   nginx 不支持对请求头、响应头进行文本替换。
   举个例子，我现在建立了 bgme.bid 这个 bgme.me 的镜像入口，由于 mastodon 响应中设置了 content-security-policy ，而且还都是基于 bgme.me 域名设置的，因此我需要将 content-security-policy 响应头中的 bgme.me 替换为 bgme.bid 。
   这样的需求 nginx 如果不使用第三方模块就是做不到。

   Caddy 支持通过 HTTP API 统一管理也是继续使用 Caddy 的原因之一。
   当然主要是上面的两点。