Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Egghead React on Rails Pro Deployment Highlights
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.
Response Time and Throughput
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.