Jackett 缓存调优指南：如何缩短搜索响应时间
项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett Jackett 是一个种子追踪器聚合工具：它把大量公共和私有 tracker 包装成统一的 Torznab/RSS API，供 Sonarr、Radarr 等下载工具调用。读完本文并照做一遍，你能拿到一个可验证的结果：同一关键词的重复搜索从秒级降到百毫秒以内，tracker 收到的真实请求数下降一个量级，并且你能用搜索页自带的耗时数字确认每一步改动生效。
🧭 快速自检：判断你需不需要优化
先对照下面 4 条现象。一条都不占的话，可以跳过本文。
- 连续两次相同搜索，第二次和第一次一样慢 → 缓存被禁用，或 TTL 设得太短，结果刚写入就过期
- 配置的索引器越多，Jackett 内存占用越高且长期不回落 → 每索引器缓存条数（Cache max results per indexer）设置过大
- 一次搜索经常 30 秒以上甚至返回空结果 → 元索引器并行查询的索引器太多，慢索引器拖住整体（元索引器有 40 秒超时）
- 刚改完某个索引器的密码，搜索还报旧错误 → 旧结果残留在内存缓存里
⚙️ 配置层：把两个缓存参数调对
如何调整缓存有效期
做什么：确认缓存开关打开，并把 Cache TTL (seconds) 设到一个合理的值。
操作路径：Web 界面右上角进入服务器配置页（Jackett Configuration），找到 "Cache enabled (recommended)"、"Cache TTL (seconds)" 两个字段，改完点 Apply server settings。
推荐取值及理由：保持默认 2100 秒（35 分钟）。源码注释明确说明 35 分钟是兼顾结果新鲜度与命中率的合理值（见 ServerConfig.cs）。设太短，结果刚缓存就过期，等于没开缓存；设太长，tracker 上新增或撤下的资源反映不出来，搜索结果失真。
如何验证：用 Manual Search 搜一个词，记下页面顶部各索引器的耗时；5 分钟后原样重搜，同一索引器耗时应大幅下降。TTL 到期后再搜，耗时会回落到首次水平——回落到首次水平恰好说明 TTL 按你设置的时间在生效。
如何调整每索引器缓存结果数
做什么：给 "Cache max results per indexer" 设一个与你内存匹配的数值。
操作路径：同一配置页，Cache TTL 下方第三个字段，默认 1000。
推荐取值及理由：新手保持 1000；只有当你的常规搜索经常翻完前 1000 条、且机器内存富余时，才考虑上调。该值过大时，每个索引器在内存中堆积的结果集更多，内存占用随之增长；过小时，缓存服务 会按"最旧优先"不断丢弃查询，命中率下降、真实请求变多。
如何验证：改动前后各做 10 次不同关键词的搜索，用系统工具（任务管理器或 top）对比进程内存；内存明显增长且你并不需要那么大的结果窗口时，降回 1000。
修改索引器配置后如何确认缓存被清掉
做什么：理解"保存配置即清缓存"的自动机制，不要试图手动点 Test 来清。
操作路径：进入某个索引器的配置页修改参数并保存。后端在保存配置时会自动调用 CleanIndexerCache，只删除该索引器的缓存条目，其他索引器不受影响。
推荐取值及理由：无需设置，这是自动行为。依赖它的前提是你走"改配置→保存"这条路；如果你以为点 Test 能刷新缓存，旧结果会一直留到 TTL 过期。
如何验证：改配置保存后立刻用该索引器原样重搜一次，顶部耗时应回到首次查询水平（说明走的是真实请求而非缓存命中）；再过几分钟重搜，耗时再次下降。
🔍 使用习惯层：减少真实查询的索引器数量
用 Tracker 和 Category 筛选缩小搜索范围
做什么：手动搜索时不要每次都全量查询，先想清楚这次要找哪个 tracker、哪类资源。
操作路径：首页点 Manual Search，输入关键词后，用 "Tracker" 下拉只选目标追踪器、"Category" 下拉限定分类，再点搜索。
推荐取值及理由：只为当前任务选择最少的 tracker。选得越多，并行发起的真实请求越多、整体等待越久；选得越聚焦，单索引器命中缓存的概率越高，响应越快。
如何验证：搜索结果页顶部会列出每个参与查询的索引器及其耗时（如 "The Pirate Bay (6) [622ms]"）。对比一次全量搜索和一次筛选后搜索的耗时列表，条目变少、总耗时下降即为生效。
用元索引器按类型分组搜索
做什么：按资源来源分组查询，而不是查 "all"。
操作路径：把搜索的索引器从 "all" 换成 "public"、"private" 这类内置筛选索引器，或在 Tracker 下拉里只选一组同类站点。筛选索引器会只把请求分发给匹配条件的已配置索引器（见 BaseMetaIndexer.cs 的 ValidIndexers 逻辑）。
推荐取值及理由：长期只用公共站找资源就固定查 "public"。查 "all" 时每个已配置索引器都会被并发访问，最慢的一个决定整体延迟，还容易撞上元索引器 40 秒超时；只查一组时参与的索引器少，超时和慢站风险都低。
如何验证：结果页顶部的耗时列表里只出现你那一组的索引器，且没有任何 30 秒以上的条目。
不要连续堆叠大搜索
做什么：一个搜索还在跑时，不要立刻发起下一个大搜索。
操作路径：等 Manual Search 返回完整结果后再发下一次查询；配合 Sonarr/Radarr 使用时，避免让多个客户端同时对同一批索引器发不同关键词。
推荐取值及理由：缓存以完整查询（关键词+分类等组合的哈希）为键，不同关键词之间互不命中。连续堆叠搜索时每次都是真实请求，并发量叠加，网络与 CPU 竞争最激烈；搜索间隔开、重复词保持一致时，第二次起直接命中缓存，耗时最低。
如何验证：同一关键词间隔 1 分钟连搜两次，第二次的每索引器耗时显著低于第一次，且日志中不再出现新的出站请求记录。
🖥️ 运行环境层：让进程长期稳定
确认缓存处于开启状态
做什么：检查缓存开关，并学会查看当前缓存里有什么。
操作路径：服务器配置页确认 "Cache enabled (recommended)" 已勾选；首页 "Configured Indexers" 页面可点 "View cached releases" 按钮查看各索引器当前缓存的结果。
推荐取值及理由：保持开启。关闭后所有请求直接打到 tracker，私有站容易触发访问频率限制；开启后重复查询走内存，tracker 压力最小。注意关闭缓存这一动作本身会清空全部缓存条目，重新启用后前几次搜索会回到冷启动速度。
如何验证：View cached releases 页面能列出最近搜索命中的条目，且 FirstSeen 时间在持续增长；一旦列表为空而你确定开过缓存，说明开关或 TTL 有问题。
从日志里定位慢索引器
做什么：找出拖慢整体响应的那个索引器，禁用或删掉长期不用的索引器。
操作路径：服务器配置页点 "View logs"；对可疑索引器点 "Test"，日志会记录它的测试耗时（形如 "Test search in 某某站 => Found N releases [Xms]"）。对长期不用的索引器，直接在索引器列表点删除图标移除配置。
推荐取值及理由：单次 Test 耗时稳定在秒级以上的索引器是主要瓶颈，优先处理；已配置的索引器全部参与 "all" 查询，留着不用只会拉长整体响应。删除配置只是移除本地记录，不影响 tracker 本身账号。
如何验证：移除慢索引器后再做一次全量搜索，对比顶部耗时列表：最长那条耗时缩短，整体返回时间下降即为生效。
常见误区
- "点 Test 按钮可以清掉旧缓存" —— 不对。测试查询不写入缓存，Test 端点也不调用缓存清理；缓存只在三种情况下自动清空：保存该索引器配置（清单个）、修改代理设置（清全部）、关闭缓存开关（清全部）。正确做法是走"改配置→保存"触发清理。
- "TTL 设成几天，一劳永逸" —— 缓存命中的前提是同一查询在 TTL 内重复。TTL 过长意味着几天前的快照一直当结果用，tracker 上新增的资源看不到。保持默认的 2100 秒，让新鲜度和命中率平衡。
- "Cache max results per indexer 设得越大越省心" —— 该参数直接决定每个索引器在内存中驻留的结果量，缓存服务 超限时按最旧查询整组丢弃。盲目调大只是把内存占用换给一个你用不到的深度。
- "索引器加得越多，结果越快" —— 元索引器对所有匹配索引器并发发请求，总耗时由最慢者决定，且有 40 秒整体超时。加索引器增加的是真实请求数和超时风险，不是速度。
✅ 验收清单
- Cache enabled (recommended) 已勾选
- Cache TTL (seconds) 保持 2100，未随意放大
- Cache max results per indexer 保持 1000，内存无异常增长
- 修改过某索引器配置并保存，重搜确认走了真实查询（耗时回到首次水平）
- 同关键词 5 分钟内重搜，页面顶部耗时有数量级下降
- 手动搜索已使用 Tracker / Category 筛选，耗时列表只含目标索引器
- 通过 Test 耗时和日志确认过瓶颈索引器，并移除了长期不用的索引器
收尾
想继续深入，建议直接读 CacheService.cs 里的 TTL 修剪与超限丢弃逻辑，以及 BaseMetaIndexer.cs 中的 40 秒并发超时设计；索引器定义目录 Jackett.Common/Definitions/ 则展示了每个 tracker 的接入方式。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
