Changes in puma configuration:

- 2 workers, 4 threads each. This means a total of 8 simultaneous connections, 8 database connections open from the web server. This is more or less what I can afford with the memory in my VPS.
- do not daemonize the Puma process. It's much better if Upstart takes care of daemonizing it in production, tracking its correct PID and being in charge of respawning Puma if necessary.
Lower capistrano log level
Capistrano deployment now starts/stops/restarts the Puma server.

When restarting Puma, a phased restart command is issued. This is generally desirable (workers are restarted one by one, ensuring zero downtime) but it means that there will be workers attending requests but running an old version of the code, at least until all workers are restarted. This is not generally a big problem except if there has been a change in the database schema. In this case the old code could cause problems.

Therefore it is recommended to manually stop+start the service (or issue a restart command on the Upstart service, which runs a normal restart instead of a phased restart), to immediatelly restart all workers forcing them to load the updated code, if there has been a change in the DB schema since the last deployment.

For more about Puma phased restart and when it is undesirable, see:

https://github.com/puma/puma#normal-vs-hot-vs-phased-restart