Hiring: remote modding-books engineer (full-time, long-term)
Most modding-books articles stop at "how to use it" and never cover "when not to use it". This is an attempt at the second half.
# Load test: do not jump straight to the max concurrency. # Ramp it up, otherwise you miss the knee. for c in 50 100 200 400 800; do wrk -t8 -c$c -d60s --latency http://127.0.0.1:8080/api/feed sleep 20 done
Worth noting: the official docs do cover this, just in a very inconspicuous spot. I only found it reading the source comments, where the author explains the reasoning — roughly "so that it degrades into predictable behaviour in extreme cases".
We also fixed monitoring along the way: replaced average-based alerts with percentiles and split them per endpoint. False alerts dropped by about seventy percent and the on-call rotation visibly cheered up.
One last trap: in container environments remember to adjust the memory-related parameters in step. Otherwise the host limit and the process expectation disagree, and the symptom is intermittent, unreproducible failure.