couple of small notes OTOMH > The second option, a global queue, allows Passenger to put all requests on the same queue "stack". Workers then are given whateve

couple of small notes OTOMH > The second option, a global queue, allows Passenger to put all requests on the same queue "stack". Workers then are given whatever is next on this stack, thus making the aforementioned long request situation a little less problematic. This is the default option out of the box and is actually the recommended mode of operation https://www.phusionpassenger.com/documentation/Users%20guide%20Nginx%203.0.html#PassengerUseGlobalQueue https://www.phusionpassenger.com/documentation/Users%20guide... > workers will be killed off, and then when traffic picks up in the morning, requests will hang inside Passenger while it tries to launch new worker processes in memory. This also happens after nginx is restarted. He mentions this later, in passing, but In the enterprise version of passenger, there is a mode where on restarting your app, passenger will not spin down worker processes until it has spuns up a new one. So this step wise system of spinning up a new worker before spinning down an old one ensures no-downtime deploys/restarts even after an nginx restart