wwarnerandrew

good question! the analysis that I was doing was really a one-off for switching between these processes. We have unit tests and sanity checks to ensure consistency going forward, but as a final check before flipping the switch we wanted to be as confident as possible that we hadn't introduced any regressions across the full data-set.

The new export process is much more reliable and a _lot_ faster, but as a side effect of doing things in a different way it generated the export file in a different format. Given that the order of objects in an export file and the order of keys/etc in the JSON objects didn't matter for anything except comparing the two processes, I figured it was simpler to put the normalization logic in the one-off tool vs baking it into our export process. But certainly if we were maintaining both exports in an ongoing fashion and validating them against each other, it would make a lot more sense to spend time making sure they generated objects and keys in the same order.

OP here— good point! We actually use Athena to query these exports in S3 to debug data drift of specific export objects over time. It's quite a useful tool, I was able to go knowing basically nothing about Athena to querying gzipped newline-delimited JSON files in S3 using SQL in about an hour.

The graphing library is highcharts (http://www.highcharts.com/)

Here is a permalink for that annotation: http://news.rapgenius.com/1900809

You can get that by clicking "share" in the annotation footer

What about using something like jquery detach? Then you could, when rendering, detach the element, render all the content, subviews, and re-append it. That shouldn't trigger reflows, right?

Yes, it's true that the Cedar stack supports forking web servers like unicorn, and that an individual dyno can run multiple workers and therefore serve multiple requests at the same time.

However, dumb routing is still very problematic – even if your dyno can work on two requests simultaneously it's still bad for it to get sent a third request when there are other open dynos.

Also, for apps with a large-ish memory footprint, you can't run very many workers. A heroku dyno has 512mb memory, so if your app has a 250mb footprint, then you can basically only have two workers.

Another essential point to note is that the routing between cedar and bamboo is essentially unchanged. They simply changed the type of apps you can run.

Yes, that's true, but for apps with significant memory footprint I don't think it's a huge help. Heroku dynos have 512mb ram (https://devcenter.heroku.com/articles/dynos), so for an app that has a 200mb footprint you're looking at probably 2 worker processes. I'd still prefer for an idle dyno to handle a new incoming request, rather than remaining idle while an in-use dyno attempts to service two requests.