It's not a problem on a new server of cause, but on a live server it makes a difference, so you might as well learn the "correct" approach initially, so you won't hurt yourself in the future.

Right but if you are modifying and existing server, then this needs to be taken into account. We have several servers who are constantly serving connections and we can't have any of them drop otherwise it will result in a poor user experience.

I just wish the article talked about using reload as well as restart and when to use them.

Hi, author of the article here. I'm actually not familiar with reload, but after reading this comment thread I'm definitely going to read up on it and make sure it's reflected in the article. Any suggestions of knowledge you want to drop is more than welcome!

Me as well. I always use reload but I don't really know how it works. Does it maintain the old and new configs and drops the old after the last connection using it is complete?

When NginX's master process receives the HUP signal[1], NginX will process and test the new configuration. If it is correct, the new configuration will be loaded into new worker processes. The old worker processes will stop receiving connections, but finish their current work. Eventually (within milliseconds usually), all the old processes will be gone and only new processes with new configuration will be working on requests.

[1] On FreeBSD, we just use `killall -HUP nginx` to reload; your distro will probably send HUP to the master process' PID