A new gem to help monitor Postgres performance in standalone instances

I just released my own gem for querying Postgres Databases for performance issues. I had used Heroku PG Extras and the Go Boundless New Relic Postgres plugin previously. Each are excellent tools with a lot of overlap. The holes for each-- hosting on Heroku needed for PG Extras and the lack of visibility into the queries themselves on New Relic-- pushed me to write this gem. My aim is to build an engine on it that will display the stats in screens that can be plugged into an application. We'll see how that goes.

Using Puma on Heroku instead of Unicorn

A few years back I wrote about using Unicorn on Heroku along with Unicorn Worker Killer. Oyr need was to increase the number of web requests an app could handle on Heroku. Puma tested faster at the time but did not offer worker processes. You have to use threads and for an app that was never intended to be threaded running on Ruby MRI it was too much work to adjust. Puma has since added the concept of Worker Processes and, given the performance advantages found with Puma it made sense to install it. Still, I was used to some variability with Unicorn and wanted to replicate some of the same things. This article from Heroku offered most of the help I needed though I did reduce the default thread count from 5 to 1. Additionally the section on the use of the Rack Timeout gem was helpful though I wound up doing this so that I could adjust the timeout via environment variable:

 Rack::Timeout.timeout = 20 # seconds  

What I did not find was helpful instructions on queue length. Puma defaults to 1024 and the previously mentioned article from Heroku cautions strongly against altering that queue length. Still, from previous performance testing on Heroku sometimes a shorter queue length is warranted (DO YOUR OWN TESTING!). This blog post originally suggested altering the queue length but again he cautions against it on Heroku. If you find that a shorter queue length helps then it is a setting in the config/puma.rb file:

 backlog = Integer(ENV['PUMA_BACKLOG'] || 20)  
 bind "tcp://0.0.0.0:#{port}?backlog=#{backlog}"   

Good luck and Heroku on

Heroku with Unicorn backlog settings and performance

In light of this post from Rap Genius and subsequent blow up on Hacker News I decided to share what we did to play with the request queue on Unicorn & Heroku.

In the app/config/unicorn.rb we changed the backlog line to this:

:backlog => Integer(ENV['UNICORN_BACKLOG'] || 200)

And then we can alter the backlog as necessary via:

heroku config:set UNICORN_BACKLOG=25 -a <app_name>

We found 25 to be a sweet spot for two Unicorn Workers but it may be different with four (which we are experimenting with now). Again this is also relative to the app so your results may (and probably will) be different.

Update:

I neglected to mention that you have to move the port declaration from config.ru and put it in the unicorn.rb too. The full line should be something like this:

listen ENV['PORT'], :backlog => Integer(ENV['UNICORN_BACKLOG'] || 200)