...

• Moving database to standard-0 ($50/month), and web dyno to standard-1x ($25/month), just to make sure we’re using production resources, although I don’t expect it to make a difference (hobby pg and dyno we were using ought to be just as fast), but just to rule it out.

  • Ramelli is coming back in 3 to 4 seconds, with no apparent spikes to 6 or 7, so… better? If still double the reliable 2 seconds on our EC2 situation.

  • RAM still super problematic, sample#memory_total=511.92MB sample#memory_rss=500.29MB

  • fixity report page 3-5 seconds, actually matching expected?

• Blank Rails new app RAM usage?

  • It is using a reasonable sample#memory_total=128.11MB sample#memory_rss=95.13MB

    • OK, what is making our app twice as big even on home page? need to investigate.

  • let’s try same skeleton rails app, but with our scihist-digicoll gemfile, so we’re loading all those gems….

    • Up to sample#memory_total=266.05MB sample#memory_rss=191.89MB

    • yeah, that’s a lot more. Although still like half of what we were seeing before! If we can keep it under 300MB, we can be okay. Hmm. We’re gonna have to do memory profiling of scihist-digicoll.

    • scihist-digicoll deploys as sample#memory_total=273.16MB sample#memory_rss=206.83MB, not TOO much more….

      • but just request of home page takes us to sample#memory_total=278.65MB sample#memory_rss=212.80MB… hmm, not THAT much more, refreshing home page gives us a few more. 😞

      • Five child work takes us to sample#memory_total=277.77MB sample#memory_rss=211.89MB , a few refreshes to sample#memory_total=274.44MB sample#memory_rss=208.56MB

      • We are doing way better memory-wise than last time we looked?? Maybe moving away from hobby dyno really did matter???

      • 115 child work at sample#memory_total=306.34MB sample#memory_rss=240.46MB, it is getting bigger hmm.

      • Several Ramelli loads up to sample#memory_total=398.45MB sample#memory_rss=332.57MB DOH. Although taking up to 6 seconds to come back sometimes.

      • Let’s actually try a branch which allocates very little per member, disabled member view.

    • A testing version of scihist_digicoll which only displays a friendlier_id for each thumb/lockup, how does ramelli do….

      • sample#memory_total=443.03MB sample#memory_rss=379.39MB no better???

      • Let’s try without iterating through the children at all….

      • sample#memory_total=421.28MB sample#memory_rss=353.05MB WHAT REALLY? What is taking this memory, we’ve made ramelli hypothetically not load any more objects than a page with one child.

      • Aha, well, decorator.representative_member is still doing a members load. let’s stop it (this is also a point of optimization, we’re doing TWO member fetches here!)

      • Down to sample#memory_total=393.84MB sample#memory_rss=334.83MB … a little bit better, but this is still REALLY WEIRD that it’s so much. We’re going to have to memory profile somehow.

Thurs Oct 8

The RAM and CPU resource issues are concerning.

...