At the same time, decrease the number of workers from 5 to 4.
Effect on max db connections will be the same - although with a higher
"resting" number of connections.
Before:
12 (instances) * 5 (workers) * 20 (10 permanent + 10 overflow) = 1200
After:
12 (instances) * 4 (workers) * 25 (15 permanent + 10 overflow) = 1200
Also rename the 'elb' argument to 'simple' to be more descriptive.
The healthcheck is going to issue requests to `/_status?simple=true`
just to check that gunicorn is up and running - we don't need to go all
the way to the database, as this would have adverse impact when api is
under load.
This is to address some errors we saw yesterday such as:
`sqlalchemy.exc.TimeoutError: QueuePool limit of size 5 overflow 10
reached, connection timed out, timeout 30`
Related flask-sqlalchemy docs:
http://flask-sqlalchemy.pocoo.org/2.3/config/#configuration-keys
Removes bindings to user provided services for new application
deployments and sets the expected environment variables to `null`.
Listing variables in the manifest allows us to only inject secrets
used by the app. `null` is not a valid value for a variable in a
CloudFoundry manifest, so if any of the keys don't have a match in
the credentials file `cf push` will return an error and stop the
deployment.
instead of using wsgi, we now use "application" - this tells gunicorn
to look inside the python module application (application.py) for a
wsgi app - and by default that is also called application so rename
the variable.
Also, when running tasks, we're not using gunicorn so need to set the
flask variable in the manifest so that `flask command ...` finds the
app properly.
Remove server_commands as it's not used any more.
specifically, all of the performance platform specific data layout now
happens in performance_platform_client.py - stuff like setting the
_timestamp, period etc, and the perf platform-specific nomenclature is
all handled there.
