Raise catalog cache TTL to 24h and optimize global search - #711
Closed
tiankaima wants to merge 1 commit into
Closed
Conversation
Longer L1/KV TTL improves section KV hit rate for repeat traffic; search now skips COUNT queries and caches responses for 120s.
5 tasks
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
life-ustc | a49715e | Jul 31 2026, 10:21 AM |
Member
Author
|
Closing as superseded by merged work on Already in main via #712 (
Already in main via #713 (
This branch ( Related: #709 — TTL raise landed in #712; post-deploy KV hit-rate measurement still tracked there. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PUBLIC_DETAIL_RUNTIME_CACHE_TTL_MSandPUBLIC_DETAIL_KV_CACHE_TTL_MSfrom 60s/1h to 24h (revision-scoped keys still invalidate on static import)./api/searchby replacing paginated list summaries (COUNT + heavy includes) with lightweightfindManyqueries.Motivation
Production metrics showed ~0.06% section KV hit rate and ~956ms avg search latency. The 60s L1 TTL was too short for high-cardinality section traffic; search was paying for COUNT queries and full summary includes on every request.
Test plan
bunx vitest run tests/unit/global-search-service.test.tskv_hitrate improves on repeat traffic (perf(catalog): section detail KV cache hit rate near zero in production #709)/api/searchp95 drops on production