Skip to content

Egghead React on Rails Pro Deployment Highlights

Justin Gordon edited this page Jun 4, 2018 · 1 revision

Egghead Performance Results with Using React on Rails Pro Node Rendering

April 10th, 2018:

Scout Performance Summary, Comparison against a month ago, before moving to React on Rails Pro.

Memory Usage and Response Times are way better. image

Response Time and Throughput

image

Overall Performance

image

Egghead Dialog During Development

Egghead, March 28, 2018

Pete Keen, lead back end developer at Egghead, approached me with: "Could we talk about the node rendering option? We're having these bouts of timeouts every hour or so that I just don't have an explanation for. i wish there was a way for me to decisively point a finger at execjs and say "this is what is causing the process to deadlock"

90 minutes later, Pete replies "it's snappy, but it's impossible to say in this context if it's faster or not. what i can say is that it works. i'll be happy if it's as fast in the happy path and gets rid of the horrible puma deadlock that seems to be happening."

Egghead, March 29, 2018

petekeen [3:48 AM]: "There's some pretty severe memory bloat going on with the renderer node process. I just refreshed a few times on my local instance and it went from half a gig to over a gig and a half."

petekeen [9:01 AM]: Alright. Fixed and in production. Looks like the caching is working well. Load on the render farm is pretty low.

joel [9:22 AM]: hey, this sounds promising. thanks for getting in and working on this Pete. Feels like something that is a solid win and step in the right direction

justin [10:33 AM]: And I’m thrilled to hear that the our “standalone-renderer” is working better than the embedded one (right, @petekeen?)

petekeen [10:34 AM]: I changed our standalone renderer to run on node 9.10.0. maybe it'll just stabilize at 1.4GB and be fine? @justin it's working at least as well functionally and it seems to have eliminated my biggest performance bugaboo, so yeah and our Rails memory usage is definitely better

May 25, 2018

justin [12:47 PM]: I guess the key thing is how I can justify a company to use this renderer vs. execJS… when to use and when not to use.

petekeen [12:47 PM]: "do you want your app to randomly crash sometimes in hard to predict ways? then execjs is perfect for you". i think it's fine for low traffic sites. so the vast majority of people are going to be fine with execjs. anybody who regularly hits six digit request numbers a day is going to be in for a bad time.

Note from Justin: Even with ExecJS, the React on Rails Pro library adds several layers of caching to both improve response time and lower server load, even on sites with less volume.