HIREFIRE

I was just starting to look into other options (outside of Heroku’s workers) for running background workers when I found HireFire.  The reason I was looking for options is because without HireFire, you have to manually move the quantity of workers available.  Essentially that meant a lot of idle time for my workers. Other services pro-rate use of workers by the minute, or even second.  That means that you only pay for actual processing time which makes a HUGE difference.

HireFire smartly scales your workers up (hires) and down (fires) depending on the how many jobs are pending in your queue.  If you’re using Heroku, HireFire is something you have to look at.

Advertisements

Migrating from Heroku Shared DB to MySQL DB

I wanted to migrate from Heroku’s shared database to a MySQL database because:

  1. the shared DB has a limited level that you can scale to
  2. some of the Heroku add-on partners are a lot cheaper than Heroku’s DB offerings
  3. my development is being done with a MySQL DB, as opposed to Heroku’s PostGRESQL, and I did have one snafu where a query worked locally, but not on PostGRESQL
  4. it’s hard to see (and edit) data that’s in the Shared DB
  5. Heroku only allows read-access to the Shared DB, so it would’ve forced me to use their worker Dynos which are more expensive than something like Iron Worker workers for a lot of the tasks I wanted to do with workers

 

Caching Rails 3 on Heroku

To learn about caching, I used a few different resources.

The three basic types of caching are:

  • page caching – mainly for static pages, it will not work if any filters are applied to the controller of the page (ie authorizations)
  • action caching – typically what you’d used to cache a page if they have filters
  • fragment caching – allows for caching of blocks of html on a page (if you can’t cache the whole page) or for partials

Since I’m on Heroku, the first place to learn was Heroku’s documentation.  It’s important to read the Heroku docs first because some standard Rails functions work differently on Heroku’ platform.  Mainly, for page caching (uses different syntax than standard rails) and action caching (mostly dependent on memcache, so you need to set your app up accordingly).

Overview of caching on Heroku
http://devcenter.heroku.com/articles/caching-strategies

http://devcenter.heroku.com/articles/building-a-rails-3-application-with-the-memcache-addon

There’s also a Rails Guide on Caching (just remember to ignore page caching part):
http://guides.rubyonrails.org/caching_with_rails.html

However, the most extensive (and useful) one for me was from Adam Hawkins at (especially for fragment caching):
http://broadcastingadam.com/2011/05/advanced_caching_in_rails

I also needed to learn about sweepers, in order to observe for changes that would impact another controller’s pages.  This Stack Overflow post helped me learn to put the sweeper in with the models and to ensure that I updated the correct controller:
http://stackoverflow.com/questions/2247410/action-caching-is-not-expiring-correctly-even-when-i-can-see-its-being-called

Setting up an Existing Rails App Locally

I had to download an existing Rails app and set it up.  To set-up a new Rails app, just follow the directions on the RoR site.

(1) download and install railsinstaller (railsinstaller.org)

(2) in the ruby command window, create a new app in the “sites” directory –

rails new appnamehere

(3) set-up git so you could download/upload to github and heroku (for version control).  follow these directions  and then these (ignore the parts about creating a new app and editing it, just need to set-up git).  when you add the remote, just use change the Hello-World to your app’s name

(4) add heroku.  follow these steps, (skip to step 3 since you set up git earlier)

(5) pull the latest version of your code.  In Git Bash go to (“cd …” for moving up in the directory, cd pathname (ie “cd sites/yourappname”) your app’s directory

(6) in git bash run: git pull heroku master git@heroku.com:yourappname.git

(7) go back to ruby command prompt to create db, run – rake db:create (i had an issue with this once, but this solved it)

(8) Create tables using schema – (i had connection issues, but this answer helped me)

rake db:schema:load

(9) run

rake db:migrate

(10) the tables should be set-up and you should be able to run “rails server” (or rails s for short).  when you go to localhost:3000 in your browser, you should see your app

(11) go to http://appservnetwork.com/ to download everything you need to run phpmyadmin, which will allow you to edit and view tables (structure and data).  i was having trouble the more recent versions so i had to use 2.4.9 (version) and that worked (set the host/domain name to localhost).  you’ll need to know what is the database login info for the development environment for the install of appserv (it will ask for it during the mysql install) – look in the sites/youappname/config/database.yml file for this info

(12) after install appserv, i could go to http://localhost/phpmyadmin/ in my browser to see my database and tables

(13) run “bundle install” in ruby command prompt (installs all gems specified in gemfile)