HireFire has the ability to automatically scale your web and worker
dynos up and down when necessary. When new jobs are queued in to your
application’s worker queue [..], HireFire will spin up new worker
dynos to process these jobs. When the queue is empty, HireFire will
shut down the worker dynos again so you’re not paying for idle
workers.

HireFire also has the ability to scale your web dynos. When your web
application experiences heavy traffic during certain times of the day,
or if you’ve been featured somewhere, chances are your application’s
backlog might grow to a point that your web application will run
dramatically slow, or even worse, it might result in a timeout. In
order to prevent this, HireFire will automatically scale your web
dynos up when traffic increases to ensure that your application runs
fast at all times. When traffic decreases, HireFire will spin down
your web dynos again.

The hirefire Python package currently supports two frameworks:
Django and Tornado. Implementations for other frameworks are planned but
haven’t been worked on: Flask, Pyramid (PasteDeploy), WSGI middleware, ..

The following guides imply you have defined at least one
hirefire.procs.Proc subclass defined matching one of the processes in your
Procfile. For each process you want to monitor you have to have one subclass.

For example here is a Procfile which uses RQ for the “worker” proccess:

importosfromhirefire.contrib.tornado.handlersimporthirefire_handlersapplication=tornado.web.Application([# .. some patterns and handlers]+hirefire_handlers(os.environ['HIREFIRE_TOKEN'],['mysite.procs.WorkerProc']))

Make sure to pass a list of dotted paths to the hirefire_handlers
function.

Set the HIREFIRE_TOKEN environment variable to the token that HireFire
shows on the specific application page (optional)

exportHIREFIRE_TOKEN='f69f0c0ddebe041248daf187caa6abb3e5d943ca'

See the installation section above for how to do that on Heroku.

Check that the handlers have been correctly setup by opening the
following URL in a browser:

http://localhost:8888/hirefire/test

You should see an empty page with ‘HireFire Middleware Found!’.

You can also have a look at the page that HireFire checks to get the
number of current tasks:

http://localhost:8888/hirefire/<HIREFIRE_TOKEN>/info

where <HIREFIRE_TOKEN> needs to be replaced with your token or
– in case you haven’t set the token as an environment variable
– just use development.

The module hirefire.contrib.flask.blueprint provides a
build_hirefire_blueprint factory function that should be called with
HireFire token and procs as arguments. The result is a blueprint providing
the hirefire routes and which should be registered inside your app

Consider all Celery tasks including the ones in the active, reserved and
scheduled queues. This fixes a long standing issue where tasks in those
queues could have been dropped if HireFire were to scale down the workers.
Many thanks to Ryan Hiebert for working on this.

Fix the RQ Proc implementation to take the number of task into account
that are currently being processed by the workers to prevent accidental
shutdown mid-processing. Thanks to Jason Lantz for the report and
initial patch.