s1d3sw1ped
04f55535a5
- Replaced the `validate-with-prefill.sh` script with a streamlined `make validate` command for improved usability. - Updated `validate-config.yaml` to clarify cache management instructions and garbage collection algorithms. - Enhanced comments to provide better guidance on upstream configurations and their implications for caching setups.
58 lines
2.6 KiB
YAML
58 lines
2.6 KiB
YAML
# validate-config.yaml
|
|
#
|
|
# Small dual-tier configuration intended for full-function validation of a
|
|
# built steamcache2 binary using realistic Steam client workloads driven by
|
|
# the external SteamPrefill (https://github.com/tpill90/steam-lancache-prefill)
|
|
# "benchmark" commands.
|
|
#
|
|
# Why these values?
|
|
# - Both tiers enabled. Memory is sized large enough to survive the disk attach
|
|
# window in mixed mode (see steamcache.go: the goroutine that blocks on d.Size()
|
|
# before SetSlow). With a realistic SteamPrefill benchmark (high rate of unique
|
|
# ~1MB chunks) the old tiny 128MB mem + 512MB disk caused almost all early
|
|
# content to live only in memory, get evicted by its GC, and never reach disk.
|
|
# Result: "never hitting", hit_rate 0, memory_size 0, despite files appearing
|
|
# on disk for late-arriving chunks. Larger mem + disk makes the validation
|
|
# actually exercise hits, promotions, disk tier, and GC as intended.
|
|
# - Conservative concurrency limits suitable for a developer laptop.
|
|
# - trusted_proxies set for 127.0.0.0/8 so that an external benchmark tool
|
|
# can simulate multiple distinct clients via X-Forwarded-For if desired.
|
|
# - upstream left empty: the server will use the incoming Host header
|
|
# (exactly what happens when you point SteamPrefill at your Lancache IP).
|
|
#
|
|
# Usage (typical dev workflow):
|
|
# make build
|
|
# make validate
|
|
# # In another terminal:
|
|
# SteamPrefill benchmark run -c 20 ...
|
|
#
|
|
# After the benchmark run, inspect with:
|
|
# curl -s http://localhost/metrics
|
|
#
|
|
# Tweak sizes upward if you want to run very large workloads while still
|
|
# exercising the disk tier (workload >> RAM is ideal for real disk testing).
|
|
|
|
listen_address: :80
|
|
|
|
max_concurrent_requests: 1000
|
|
max_requests_per_client: 10
|
|
|
|
max_object_size: "0" # unlimited for validation (real Steam files can be large)
|
|
trusted_proxies: ["127.0.0.0/8"]
|
|
|
|
cache:
|
|
memory:
|
|
size: 1GB
|
|
gc_algorithm: hybrid
|
|
disk:
|
|
size: 2GB
|
|
path: ./validate-disk # cleaned between runs by make validate or make clean-disk
|
|
gc_algorithm: hybrid # recommended for disk in the project README
|
|
|
|
# Empty upstream = use Host header from the client (SteamPrefill / real Steam clients).
|
|
# Allows for chaining steamcache2 instances if needed.
|
|
# For example, for a lan party you could have a small fast ram only cache at each table pointing to a larger slower disk cache in the back somewhere
|
|
# It would reduce the amount of bandwidth needed to the internet and the amount needed to each table
|
|
# just as a little reminder there is no authentication so this is not a good idea for a public cache just out on the internet.
|
|
upstream: ""
|