Add recommendation to use nginx rather than straight app server

[cmc333333]

Per @GUI

You may actually want to put nginx in front, depending on your underlying server and your external load balancer. But for gunicorn and uncicorn it's important to have a proxy in front that buffers requests to prevent slow client attacks (and I don't think ELBs buffer requests by default): http://docs.gunicorn.org/en/latest/deploy.html#nginx-configuration

The above would only apply to things not running on cloud.gov. Does cloud.gov install an nginx for apps anyway?

[jmcarp]

Cloud.gov currently runs an nginx proxy in front of the cloud foundry router: https://github.com/18F/cg-secureproxy-boshrelease

[GUI]

I don't think that specific nginx config will fully protect against slow clients. proxy_buffering is disabled which I think that opens up potential issues (since this disables response buffering). proxy_request_buffering is still enabled (it's the default), but Unicorn and Gunicorn require both request and response buffering to be enabled. Unicorn's intro is a bit more explicit about this:

Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between unicorn and slow clients.

More generally speaking, it seems like whether you want nginx buffering enabled or not might be something you want to decide on a per-app basis (rather than globally for all apps). If you force buffering at a global proxy layer, then applications won't be able to support streaming requests or responses. Streaming can be desirable in many cases, and not all application servers have this limitation (for example, in the Ruby world, Puma's threading approach makes it fine to use with slow clients, which allows it to support streaming use cases).

[afeld]

Given that we push TTS systems to use to cloud.gov, not really relevant anymore.