Turn soak results into action

Use the degradation category from the previous milestone to pick the next investigation. Memory-related drift and connection-pool exhaustion need different follow-up.

To turn your soak results into actions, complete the following steps:

1. Open your documented results and identify which degradation category your test fell into.

   Memory-related degradation: Latency rose gradually, correlated with increasing memory usage or GC pressure on the system under test.

   • Review application-level caching and session storage for unbounded growth.
   • Check for long-lived collections that accumulate per request (logging buffers, metrics registries, listener lists).
   • Set a memory usage alert in Grafana from the drift rate you measured.

   Connection-related degradation: Latency was stable, then jumped as the connection pool reached capacity.

   • Compare pool maximum to sustained request rate.
   • Look for connections not returned on error paths or timeouts.
   • Add a dashboard panel for pool utilization over time.

   Disk-related degradation: Performance changed when disk space or log volume approached limits.

   • Review log rotation and temp-file cleanup.
   • Set disk usage alerts from the fill rate you observed.

   No degradation observed: Metrics remained stable for the full test duration.

   • Extend duration on the middle stages entry (for example from 30 minutes to 4 or 8 hours on a production soak).
   • Increase load toward your average-load ceiling if you need more pressure.
   • Keep the clean result as a reference for the next code or infrastructure change.

2. Set duration targets for future soak tests based on what you learned.

   On a production soak, if degradation appeared at 90 minutes, the next run should last at least 3 hours to confirm a fix. If no degradation appeared in 2 hours, extend to 4 or 8 hours.

   A useful rule: run at least twice as long as the time-to-degradation you observed so a fix is less likely to be a short delay rather than a real resolution.

3. Plan when to run soak tests.

   Soak tests cost more time than stress or spike runs, so most teams run them less often:

   • After changes to resource management: Caching, connection pooling, session handling, or background jobs.
   • Monthly or before major releases: Catches slow regressions from small cumulative changes.
   • After infrastructure changes: New database instances, memory limits, or disk allocations.

In the next milestone, you review what you accomplished and explore next steps.