Journal of heroku investigations. Most recent entries on top? See also Heroku Consideration
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.
Performance and resource concerns
One puma worker (five threads) for our app takes nearly 500mb of RAM, so we can only fit one in a 512MB dyno, or two in a 1024MB dyno. Somewhat less than we had hoped. Not sure why RAM usage is somewhat bigger than a passenger worker on our present infrastructure, maybe the extra threads? We could try with fewer threads.
More concerning however is the performance of our slowest/largest requests.
Our small/reasonable requests are somewhat slower on heroku than current infrastructure. But our larger requests are much slower, with much more variance in speed. Apparently very slow requests--and/or requests which create a lot of objects/use a lot of RAM--cause heroku performance to degrade unpredictably? We could try to diagnose and improve our slowest actions, but this raises concerns about increasing difficulty of app development.
Action | Current infrastructure | heroku (hobby dyno) |
|---|---|---|
Tuesday Oct 6
For future: Asset delivery
...