Journal of heroku investigations. Most recent entries on top? See also Heroku Consideration

Thurs Oct 8

The RAM and CPU resource issues are concerning.

• Why does an instance seem to take even more RAM on heroku than on our EC2?

• Why are slow actions even so much slower on heroku than on our EC2?

Things we might investigate:

• Try passenger on heroku instead of puma, to compare apples to applies

• Try the heroku buildpack for jemalloc and compiling ruby with that, which some people say makes ruby use RAM better. (We didn’t do that in our EC2 though). https://elements.heroku.com/buildpacks/gaffneyc/heroku-buildpack-jemalloc

• Try a heroku standard-0 postgres and standard-1x dyno to be using actual resources we will be using, in case the ’hobby' ones we are using to test have different performance characteristics

  • Dyno standard-1x can easily be temporarily turned on and off, but db will probably stay there at $50/month

• Actually analyze and try to optimize our app, RAM usage and performance

  • Make fixity report run on cronjob and give you stored results instead of running when you click on it

  • Make many-child pages use “infinite scroll” technique to only load first X and load more when you scroll down, instead of trying to load all at once

  • More efficient production of each child page element on work pages (hard-code URLs etc)

  • Use derailed gem to figure out what parts are using so much RAM and fix them https://github.com/schneems/derailed_benchmarks

• While we can probably optimize our app, the fact that we weren’t forced to on manual EC2 but will on heroku worries us that we’re raising the skill level and time needed to maintain a working app on heroku? (actually already HAVE spent time optimizing app now, but apparently not yet good enough for heroku?)

Wed Oct 7

We have a semi-functional app deployed to heroku – no Solr (so no searching), no background jobs, lots of edge case issues. But something to look at.

...