Performance and Garbage Collection

[PeteDuncanson]

Hi Daniel,

We've been running some performance tests on a site we are hoping to go live with next month and noticed each request is gobbling roughly 4MB of unmanaged memory each time that I'm trying to track down.

In our work we tried a few things but I'd love your thoughts. I think a fix is possible I just wanted to run some stuff by you if possible.

• We've got a tool thats throwing 15 concurrent requests into our site generating a total 600 requests for our web page. First run on my machine it gobbles up 450MB of unmanaged memory and second run added another 150MB which looked like it might be maxing out and forcing some GC of some sort but a 3rd run showed it pushing ever higher again.
• Memory usage jumps when we execute our commands in the JS engines (seen by monitoring memory usage while stepping through our code), we are runnning some chunky JSON through it (100Kb+) for each request but we init each engine with our bundled JS (300K including React and React-Router) only on start up of the engine to limit usage. Its this initial JSON that we need to seed the component with thats causing a jump in the memory. Its just pushed in as a string so I would hope the Garbage Collection in ClearScript (well V8 under the hood) would just clear it up but it seems to not be until we really push the usage up.
• We've modified JSPool (and JavascriptSwitcher as a result) to give us a .CollectGarbage() method we can call on the V8 engine when its returned to the pool, that has more than halved the memory usage. Had to use the agressive GC to get this to happen though (see https://clearscript.codeplex.com/discussions/576460).
• We are only passing formatted strings into the JS engine to be executed, not references to actual objects so ClearScript/V8 shouldn't be keeping anything from being GC'ed that we can see and all this is done in ReactEnvironment which should be thrown away at each request so .net GC should be doing its thing anyway.
• There is a definate "jump" on the unmanaged heap after every request (shown when just pressing refresh without our test running), initially 4MB now more like 1.5MB after my hackery :)

Any ideas on what other steps we can take?

I'm tempted to try throwing away the engine each time and see if we can get any better memory usage. This would be just a test to see if it makes a difference.

Cheers

Pete

[PeteDuncanson]

Switching to use a new engine per request certainly sorted out the memory issue at the expense of hitting the CPU a little harder. Happy with that :)

[Daniel15]

Switching to use a new engine per request certainly sorted out the memory issue at the expense of hitting the CPU a little harder

In that case it sounds like JSPool should recycle the workers periodically. The issue with creating one engine per request is that every request is a bit slower as it needs to load all the JavaScript again. You can definitely leave that option enabled if it helps your use case though (the pooling may still have some bugs which is why I left an option to disable it).

I'm currently on vacation but I'll be back on 16th February. Jetbrains are awesome and provided a free license for dotTrace for ReactJS.NET so I can do some profiling when I get a chance :)

[PeteDuncanson]

We've been using the same bit of kit here, trouble is it can't give you any details about the unmanaged memory other than how much you are using. Still its certainly helped.

Still seeing quite a ram up in unmanaged memory usage but then it settles down after a while bobbing around with about 300Mb being used or there abouts.

Requests are slower too, might need to do some more digging. I "think" the JS engine builds a load of objects for the JSON we pass in but is not releasing it fast enough. Forcing the GC seems to make it behave somewhat better. Still trying stuff out this end though. Anything we can do just ask.

In the meantime though enjoy your vacation :)

Cheers

Pete

[PeteDuncanson]

Just a little feedback on this one. We been playing with clearing out the global vars before we hand the engine back to the pool (as shown here https://clearscript.codeplex.com/discussions/461288#PostDetailsCell_1104949) and saw the memory usage greatly reduced. Seems doing that allows GC in V8 to kick in and do its thing. Might be worth considering?

On a side note we've been playing with just using V8 direct and got some very sweet speeds (including all the tricks we've learnt while poking around). We've got our pages down from 0.5 seconds to 0.180 using a new engine (well context at least) everytime. Now looking at basic pooling to see if we can't save the 80ms its taking to spin up and populate the engine with our bundle each time.

[Daniel15]

@PeteDuncanson

We been playing with clearing out the global vars

Interesting, is the memory usage considerably reduced when you do that compared to when you just do engine.CollectGarbage(true)?

On a side note we've been playing with just using V8 direct

You mean rather than through JavaScriptEngineSwitcher? In theory JavaScriptEngineSwitcher shouldn't significantly affect performance. I wonder where it'd be slowing down.

Now looking at basic pooling

You could probably modify JSPool to use V8 directly :)

[PeteDuncanson]

Calling garbage collection didn't do much as the refs to the vars are still there. Clearing those out and then calling GC made a big difference. It's running really well without a pool at the minute. Got render time down from .5 to .18 seconds. Could do more with pooling though I think. Like the idea of using js pool. Will take a look

Sent from my iPhone

On 7 Mar 2015, at 01:40, Daniel Lo Nigro <notifications@proxy-git.cwkhome.funmailto:notifications@github.com> wrote:

@PeteDuncansonhttps://github.com/PeteDuncanson

We been playing with clearing out the global vars

Interesting, is the memory usage considerably reduced when you do that compared to when you just do engine.CollectGarbage(true)?

On a side note we've been playing with just using V8 direct

You mean rather than through JavaScriptEngineSwitcher? In theory JavaScriptEngineSwitcher shouldn't significantly affect performance. I wonder where it'd be slowing down.

Now looking at basic pooling

You could probably modify JSPool to use V8 directly :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/78#issuecomment-77676567.

[PureKrome]

Hi @PeteDuncanson - can you provide some sample code with re: to what you're doing? Would be great to reference that against whatever we're doing / not-doing.

Secondly, any more info with re: your tweaks and using js pool ? Did you end up trying that? Luck/no-luck?

[PeteDuncanson]

Hi @PureKrome,

We've gone the route of just building a hardcoded V8 version which has allowed us to use all the performance tweaks we can to get the most out of it. You can get that over at https://github.com/Offroadcode/SuperchargedReact.Net

Clearing out any global variables by running "delete myvarnamehere;" style commands in the runtime before throwing it away helped greatly on memory leaks and something I think could be added to ReactJS.net (@Daniel15 I might do a pull request for this if I get time). We've not gone the pooling route as getting a new context is proving to be blazingly fast if you just ask the DLL for a new one rather than invoking a new instance each time, is a small change but made a big difference, sadly this couldn't be done using the current JavascriptSwitcher and JSPool setup hence us stripping them out and going direct for V8.

Some other tweaks we did was allow for re-using compiled scripts which saves on the parse time every cycle (again you can't do this with the current levels of abstraction). Assumed that you've already bundled and JSX compiled your code so stripped out that step too.

All in all its blazing fast but does not have the flexibility of switching engines or broad reach that ReactJS.net has and is built for. As I said I'm hoping to implement some of these tweaks as PR's but with 3 different abstration layers and each being a separate project we might have a PR casscade which might hold things up which is another reason we jumped head first into coding up SuperCharged and knocked it out in 2 days (which was only possible thanks to the excellent work already done by @Daniel15).

Shout if you want to know anymore.

Pete

[Daniel15]

Thanks for the info @PeteDuncanson!

I think I'd be happy dropping the JavaScriptEngineSwitcher dependency if it helps with improving performance, but I need to maintain compatibility with both Windows and Linux. ClearScript doesn't run on Linux (due to its usage of C++/CLI) so I need the VroomJs engine for Linux compatibility. Perhaps JSPool could be updated to support using V8 directly (via ClearScript + VroomJs) and create multiple contexts.

[PeteDuncanson]

That might work, I know next to nothing about VroomJS and don't have a Mac so can't really test it. However if its just the two engines then it "could" be possible to optimise both some how then. Will be good to see how we might do that. Would need to do some reading up on vroomjs though, feel free to poke around in Supercharged to see what we are doing and steal back what you need if you beat me to it :)