# 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: ""