You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/components/store.md
+27Lines changed: 27 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -576,6 +576,33 @@ Note that there must be no trailing slash in the `peers` configuration i.e. one
576
576
577
577
If timeout is set to zero then there is no timeout for fetching and fetching's lifetime is equal to the lifetime to the original request's lifetime. It is recommended to keep it higher than zero. It is generally preferred to keep this value higher because the fetching operation potentially includes loading of data from remote object storage.
578
578
579
+
## Hedged Requests
580
+
581
+
Thanos Store Gateway supports `hedged requests` to enhance performance and reliability, particularly in high-latency environments. This feature addresses `long-tail latency issues` that can occur between the Thanos Store Gateway and an external cache, reducing the impact of slower response times on overall performance.
582
+
583
+
The configuration options for hedged requests allow for tuning based on latency tolerance and cost considerations, as some providers may charge per request.
584
+
585
+
In the `bucket.yml` file, you can specify the following fields under `hedging_config`:
586
+
587
+
- `enabled`: bool to enable hedged requests.
588
+
- `up_to`: maximum number of hedged requests allowed for each initial request.
589
+
- **Purpose**: controls the redundancy level of hedged requests to improve response times.
590
+
- **Cost vs. Benefit**: increasing up_to can reduce latency but may increase costs, as some providers charge per request. Higher values provide diminishing returns on latency beyond a certain level.
591
+
- `quantile`: latency threshold, specified as a quantile (e.g., percentile), which determines when additional hedged requests should be sent.
592
+
- **Purpose**: controls when hedged requests are triggered based on response time distribution.
593
+
- **Cost vs. Benefit**: lower quantile (e.g., 0.7) initiates hedged requests sooner, potentially raising costs while lowering latency variance. A higher quantile (e.g., 0.95) will initiate hedged requests later, reducing cost by limiting redundancy.
594
+
595
+
By default, `hedging_config` is set as follows:
596
+
597
+
```yaml
598
+
hedging_config:
599
+
enabled: false
600
+
up_to: 3
601
+
quantile: 0.9
602
+
```
603
+
604
+
This configuration sends up to three additional requests if the initial request response time exceeds the 90th percentile.
605
+
579
606
## Index Header
580
607
581
608
In order to query series inside blocks from object storage, Store Gateway has to know certain initial info from each block index. In order to achieve so, on startup the Gateway builds an `index-header` for each block and stores it on local disk; such `index-header` is build by downloading specific pieces of original block's index, stored on local disk and then mmaped and used by Store Gateway.
0 commit comments