uWSGI cheaper subsystem: balancing memory overhead and cold start latency

In environments with low-traffic workloads, reducing the memory footprint of uWSGI is a priority. The cheaper subsystem allows the server to scale down the number of worker processes when demand is low, rather than maintaining a static pre-fork model defined by the processes directive.

While the busyness algorithm provides a mechanism for dynamic scaling, there is a trade-off between aggressive resource reclamation and the latency introduced when spawning new workers to handle sudden request spikes. This is particularly relevant for applications with significant startup overhead where lazy-apps = true may be employed to manage memory efficiency.

What are the recommended thresholds for cheaper-busyness-max-requests and cheaper-busyness-min-requests to prevent frequent worker oscillation in low-traffic scenarios? How does the interaction between the busyness algorithm and lazy-apps impact the initial request latency during a scale-up event?