Search refresh interval
A saved post is not searchable until the index publishes it. With 1,000 new posts/s, worker capacity and the refresh interval set that delay. Both must keep it below 5 s.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | 1 shard, refresh every 10 s | 4 shards, refresh every 1 s |
|---|---|---|---|
| p99 latency (Queries) | under 150 ms | 24 ms Pass | 25 ms Pass |
| Data age | under 5 s | 10 s Fail | 1 s Pass |
| Monthly cost | 16 USD/mo | 16 USD/mo | |
| Error rate | 0% | 0% |
Key numbers
| Number | Value |
|---|---|
| Default refresh interval of a search index | 1 s |
| Operations per second, one search part | 10,000 ops/s |
| Default shards | 1 shards |
Index · 4 pages read per query · disk writes per insert: 2
How it works
A search index does not show a new document at once. A write enters a queue. Workers process the queue and add the documents to the index. Then a refresh publishes the finished work, so that queries can see it. The age of a search result is the sum of three waits: the queue, the processing and the wait for the next refresh.
In the mini board ten million posts are indexed, 1,000 new posts/s arrive, and 500 queries/s run. New data must be visible within 5 s. With one shard and a refresh every 10 s, a post can wait 10 s for the refresh alone. The limit fails.
Two knobs fix it. A shorter refresh interval, here 1 s, publishes work sooner. More shards give more workers, so the queue does not grow: with 4 shards the workers keep up with 1,000 new posts/s. Both must be right. Fast refresh with too few workers still lets the queue grow, and many workers with a slow refresh still wait for the refresh.
A short refresh has a cost. Each refresh makes a small file to merge later, so it adds work. Pick the longest interval that meets the age limit.
In the levels you tune the shards and the refresh interval and check the age of new documents.