This is false. Nginx will spawn new workers with the changed config and gracefully shutdown the old ones once the new ones are online. There should be no drop in traffic or dropped requests while this happens.
Before making this statement, think of how the following states can really be non-disruptively handled:
1) requests in transit to nginx (in-flight)
2) TCP handshakes just completed (not yet accepted)
3) TCP handshakes in progress (clients will retry if server doesn't RST)
Nginx cannot know if requests are in transit nor it can handle just established TCP conns. It also does not drain
the backlog queue in the old processes. It simply tears down
estimated 'idle' connections.
Try a test with heavy load and you will see. More network latency more errors...
That's exactly why Nginx Plus offers dynamic upstream modification features as opposed to relying on reload.
1) requests in transit to nginx (in-flight) 2) TCP handshakes just completed (not yet accepted) 3) TCP handshakes in progress (clients will retry if server doesn't RST)
Nginx cannot know if requests are in transit nor it can handle just established TCP conns. It also does not drain the backlog queue in the old processes. It simply tears down estimated 'idle' connections.
Try a test with heavy load and you will see. More network latency more errors...
That's exactly why Nginx Plus offers dynamic upstream modification features as opposed to relying on reload.