Could you expand the readme for how to return your production recommendations?

[surgevelocityllc]

Hi there, so based on the readme it seems I install the gem, register my app, then add some environment variables to my server and deploy the app.

However, when doing this on production servers, how do I get the process to end in order to generate the GC recommendations? I assume the only way to get good recommendations is to base it off of production usage.

I am on a PaaS and don't have access to direct commands other than Rails console. Does that mean I have to physically shutdown my production app (or at the least, another redeploy) to get the report?

Also, what is the recommended runtime before ending the process and generating the reports?

Love the concept, and memory management has been a huge pain for my app since Ruby 2.1!

[methodmissing]

@surgevelocityllc we're wrapping up initial support for aggregation on releases (by host -> pid -> ppid), which yields a much better full stack representation of heap state and what the GC's been up to. The first version of that would be available as a Heroku addon, but we're interested in other PaaS platforms too.

Regarding syncing snapshots, we've been looking at different possibilities to have data coming through other channels than the Kernel.at_exit hook. At the moment syncing on kamikaze (when the agent uninstalls and gets out the way) after X requests would be easiest and less error prone as a first stab.

For runtime, units of work (requests handled, jobs processed etc. depending on the GC spy you're using) is more important than process uptime. A particular Unicorn worker could sit around for a day without getting much traffic. We recommend 200 units of work, which should generate a sample set of 500 to 600 odd events, depending on how often GC runs.

Thoughts? Willing to be part of a small focus group? Which PaaS are you on?

Best,

• Lourens