resque

Hi there,
There's no downside to opening connections on initialization or after forking, even if you don't use the connections often. Aside from reducing the chance for connection errors during the request loop, you'll also speed up your request loop by not spending time establishing new connections. I definitely recommend making this change if you can.
For Resque, there's unfortunately no way around the fact that every job is run inside a forked process and can't inherit or share any connections. You'll have to open a new Redis connection for every Resque job that uses Redis. The best way to do this inside the "after_fork" Resque hook. If you use ActiveRecord, it's likely that you're already establishing a new connection inside this hook. Here's what our after_fork hook looks like, in our config/initializers/resque.rb file:
```ruby
Resque.after_fork do
  tries = 0
  begin
    $redis.client.reconnect
    ActiveRecord::Base.establish_connection
  rescue
    tries = tries + 1
    if tries <= 2
      retry
    else
      raise
    end
  end
end
```
The begin..rescue block lets us try up to two times if either our Redis or ActiveRecord connection fails to open. This allows our Resque jobs to be a little more resilient in the face of occasional connection problems on Heroku dynos.
If you're not already using it, we definitely recommend using the "hiredis" driver for your Redis connections. For customers who need to open new connections frequently, they tend to see fewer connection problems with it. There's instructions for using it here: https://github.com/redis/redis-rb#hiredis
As for consolidating your databases, I'd recommend against this. Because Redis is single-threaded, it can only handle one command at a time. If you were to consolidate three databases in to one, you'd have a lot more clients competing for Redis time on a single server.
I hope this helps — let me know if you implement any of the above and, if you do, how it works out for you!
-Tyson