Weave provides server response caching to improve performance when you run repeated queries or work with limited network bandwidth. This article explains when caching helps, how to enable it, which requests Weave caches, and how the cache uses disk space, so you can decide whether to turn it on and plan for its storage footprint. The feature is deactivated by default.Documentation Index
Fetch the complete documentation index at: https://wb-21fd5541-docs-2661.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
When to use caching
Server response caching is helpful when:- You frequently run the same queries.
- You have limited network bandwidth.
- You’re working in an environment with high latency.
- You’re developing offline and want to cache responses for later use.
Enable caching
To enable caching, set the following environment variables.WEAVE_USE_SERVER_CACHE turns the cache on, and the other variables let you tune its size and location.
Caching behavior
This section describes which server requests Weave caches, so you can predict which operations benefit from caching. The feature caches idempotent requests against the server. Weave caches the following requests:obj_readtable_querytable_query_statsrefs_read_batchfile_content_read
Cache size and storage details
Use this section to estimate the disk space the cache requires, so you can sizeWEAVE_SERVER_CACHE_SIZE_LIMIT for your environment. WEAVE_SERVER_CACHE_SIZE_LIMIT (in bytes) controls the cache size. The actual disk space used consists of three components:
- A constant 32 KB checksum file.
- A Write-Ahead Log (WAL) file up to ~4 MB per running client. Weave removes the WAL file automatically when the program exits.
- The main database file, which is at least 32 KB and at most
WEAVE_SERVER_CACHE_SIZE_LIMIT.
- While running >= 32 KB + ~4 MB + cache size.
- After exit >= 32 KB + cache size.
- While running: ~9 MB maximum.
- After exit: ~5 MB maximum.
Performance