Measure the application’s memory use after startup and during representative requests. Confirm the hosting account memory, CPU and process limits.

1. Start with a small supported worker configuration and a repeatable workload. Keep development reload disabled in production.

2. Measure response latency, CPU saturation, memory peaks and dependency connections. Identify whether slow requests wait on external I/O or consume significant CPU.

3. Increase workers gradually only when the resource budget and bottleneck justify it. Account for per-process caches, startup objects and connection pools.

4. Set graceful shutdown and restart behavior through the approved supervisor. Check that deployment briefly running old and new processes together still fits available memory.

5. Retest after a material code, dependency or traffic change rather than keeping a copied worker formula indefinitely.

Assume an application has a 2,048 MiB budget and reserves 512 MiB for other required processes and operating headroom. Measured peak use is 384 MiB per worker.

Three application workers: 3 x 384 MiB = 1,152 MiB
With reserved capacity: 1,152 + 512 = 1,664 MiB
Three old plus three new workers: 6 x 384 = 2,304 MiB

The example fits in steady state but exceeds the total budget during a full overlapping replacement, even before the reserve is counted. Change the deployment overlap, process count or capacity plan based on a measured test. These are illustrative numbers, not a Nabtech plan limit or a universal worker recommendation.

Also recalculate database pools and startup-loaded objects. Verify tail latency and failure rates under the intended workload before accepting a worker-count change.

Verify the expected load completes without out-of-memory restarts, growing queues or database connection exhaustion. Compare tail latency as well as average response time.

If more workers make the service less stable, return to the last working configuration and inspect the resource that became constrained. A process killed by the system may not produce a normal Python exception.

• Managing FastAPI lifespan resources and database pools
• Measuring application latency by dependency
• Running FastAPI behind a production reverse proxy
• Configuring FastAPI root paths and proxy headers

• FastAPI server workers
• FastAPI deployment concepts