pike
ff1ab31327
The README buried hit/miss verification under the SteamPrefill validation chapter, and advertised make validate-check without a Makefile target. Operators need a short start → traffic → metrics path against the existing /metrics and /lancache-heartbeat endpoints. Link: #29
60 lines
2.7 KiB
YAML
60 lines
2.7 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:
|
|
# make validate-check
|
|
# # or: curl -s http://localhost/metrics
|
|
# Heartbeat (process up): curl -s -i http://localhost/lancache-heartbeat
|
|
#
|
|
# 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: ""
|