...
Things we might investigate:
Use heroku https://devcenter.heroku.com/articles/log-runtime-metrics experimental add-on to get more precise logging of our RAM use over time as we trigger actions.
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?)
...