Fuite: a tool for finding memory leaks in web apps(nolanlawson.com)
nolanlawson.com
Fuite: a tool for finding memory leaks in web apps
https://nolanlawson.com/2021/12/17/introducing-fuite-a-tool-for-finding-memory-leaks-in-web-apps/
33 comments
Colleague of bgirard at Facebook here, we are planning to open source the tool in 2022. Great to find someone also working on memory tooling here :) Fuite seems really interesting, will try it out!
Hi bgirard! I support the FB team that works on this - it's on the roadmap to open source hopefully H1 next year :) It's continued to find significant leaks in other parts of our infra too, so hopefully it will be equally helpful to others. Great to see others looking at memory tools now too - I'll definitely be checking Fuite out
Author here. I wasn't aware of your talk, but it's super interesting! Showing info about the retain chain is a great idea, but I didn't get around to doing it in fuite. IME just counting the number of objects is actually pretty effective to find the smoking gun. (You leaked 1 event listener, which leaked a bazillion strings, arrays, objects, etc., but all you really care about is the 1 event listener.)
I would love to see how your tool approaches this! Hope it gets open-sourced. :)
I would love to see how your tool approaches this! Hope it gets open-sourced. :)
Almost all SPAs do have memory leaks in my experience. I was once involved in Eclipse Memory Analyzer project(for Java, short MAT), and I mentored a student who built a prototype to support JS in MAT.
We easily found significant memory leaks everywhere. That prototype was never released for reasons I cannot comment on in public.
misunderstood, nvm!
I think they meant the student built a prototype leaks detector for SPAs.
Oh cool, thanks for the correction
The only thing more tedious and brain-breaking than tracking down client-side JS memory leaks is tracking down server-side JS (Node) memory leaks.
Serious question, is it really more difficult fir server side JS? At least you don't have to fiddle around with DOM references. The potential impact on the server side is of course potentially bigger.
Browsers - Chrome especially - have really fantastic tooling for doing stuff like this. I think there's some way to hook those up to Node, but they're very readily available on the front-end
You can use chrome's tooling directly from nodejs. You just need to invoke nodejs with `node --inspect` (or --inspect-brk to pause before the first line of code is executed). Then open chrome's dev tools. A nodejs icon will magically appear at the top left of the dev tools pane. If you click that it'll open a new window with chrome's debugger, profiler and memory tools working directly with nodejs's v8 instance.
Or ndb[0].
[0]: https://github.com/GoogleChromeLabs/ndb
[0]: https://github.com/GoogleChromeLabs/ndb
I mean it depends on the application naturally, but flame graphs or no and especially when dealing with heap dump comparisons, sometimes very opaquely named symbols, etc, it can be an exercise in frustration.
Gmail and other gsuite apps’ developers, would you please use Fuite? Thx.
Personally I prefer JS-light sites, but in today's SPA filled world, this tool is very welcome.
This is actually really important. If you're a tab whore like me you'll always find a site that eventually eats up all your RAM and kills the browser dead. More SPAs need to test for memory "leaks" like these, especially if they're repeatedly creating large numbers of DOM elements through scripting.
Having to point at a URL and crawl for pages seems awkward. Is there something I can directly integrate into my app? How would it deal with a login page?
Ran into the same limitation. I had tried logging in to a local dev server and then running fuite, but it looks like it runs the tests in its own personal chromium instance so my session wasn't used.
There are no memory leaks on my login and sign up pages though!
edit: just checked the docs and it says you can specify a scenario script with a setup hook to get passed authentication.
There are no memory leaks on my login and sign up pages though!
edit: just checked the docs and it says you can specify a scenario script with a setup hook to get passed authentication.
I jump into this project implementation and it supports login page by using some config. You should give it a try
This specific issue makes the "PHP way" (just to mention a notable example) of having an interpreter created to serve a page and then destroyed at the end, much more convenient, even if more resource intensive. Assuming the problem is not in the Javascript side of a single page application, of course.
How do crawler approaches like this handle SPAs that have a multi-step onboarding flow before getting into the actual heavy-hitting areas that need the most testing? (e.g. where you may have to click through several things before even hitting a route change)
Author here. I added support for custom scenarios, where you can define a "setup" step that logs in or does whatever you may need to do: https://github.com/nolanlawson/fuite/#extending-the-default-...
Very cool. Looks extremely easy to use which is the difference between people using tools or just reading about them :)
As an aside, I created some tooling for identifying memory leaks in Python apps. Once I started sending the results to Slack and formatting them nicely, I found people ran the tool more frequently. Usability is everything.
As an aside, I created some tooling for identifying memory leaks in Python apps. Once I started sending the results to Slack and formatting them nicely, I found people ran the tool more frequently. Usability is everything.
This is a welcome surprise. I have been hunting down memory leak problems for a hardware installation that runs a JS heavy app 24/7. Had to build in auto software resets just to clean the garbage because there was no real solution. Looking forward trying this out asap
Most SPAs nowadays load JS for new components dynamically on route change. I expect this to increase the stack, too. Just something to keep in mind.
Great point! This is exactly why fuite does a preflight iteration before the "real" iterations. One-time setup costs shouldn't count against the "leak" – only sustained memory growth.
[deleted]
Memory leaks on the client side, in a single-page app.
We used it to find a problem fixed in React 18 that caused large leaks on Facebook.com: https://github.com/facebook/react/pull/21039#issuecomment-80...
We also found one issue that caused a leak that's impossible to spot unless you know how V8 closures are implemented and retain one another.
I'm really hoping to see Facebook open source the tool some day!
Fuite seems really interesting. I like the idea of an automatic crawler!