Lodestar: Debugging Live Javascript Applications - Cayman Nava -[Toronto Ethereum Developers Meetup]

Transcript

hello everybody uh today i'm going to do a little show and tell of just some different ways of debugging um debugging a javascript application and as the example i'm going to be using lodestar which is the typescript beacon node that we've been writing for the past year so i'll get started by sharing my screen okay can everyone see me see the screen cool all right so i've started up i started up some code before

the meetup just so that things would be working uh live demos live coding can be a little sketchy so um i can guess i can tell you where we're starting here um on the top top of the screen i have a lodestar node started and i started it by cloning down the most recent version of lodestar from github building the building the whole uh repo following the instructions and then i started it by running node dash dash inspect a load star beacon and i'm using a test net of procter so that's what's running up

above i'm not going to start it again but just to give you a sense of what's going on the kind of the question like how do you debug a running javascript application it's um right now we have some logs going and i guess you could print a whole bunch of logs print a bunch of strings to the screen but that's not really scalable and um i guess at a certain point you're kind of left wondering what's what actually is going on behind the scenes so i can kind of see like i'm sinking i guess um one slot per second which if you know anything about e2 that's not very good um 10 peers i guess seems a little low but

so there's not very much you can really do here not a lot of input that you can really give not a lot of output really we can change um we could try to hit maybe the api and figure out what's going on there but i'm going to show some other fun techniques so one thing that we use and i think a lot of other applications use not just javascript but they use prometheus metrics and hook it into fancy looking dashboards and these metrics are a really good way of exposing just things that are happening under the

scene under the hood especially certain things in javascript that are really nice to know so here i've got a dashboard which i've already plugged into this running node and now we can actually see a lot more this is much more rich than just this you know line by line um not getting much here um here we can actually see um we put in some work to actually build a dashboard so there's a little bit of upfront work but once you get this going you can actually begin to maybe see if there's a problem or see where where where

where that maybe how some hot spots are um we can see the heap space it's the total this is the kind of the memory used process heat bytes these are kind of two metrics relating to the memory uh we can see some metrics relating to the garbage collection and if you're a javascript developer these are two pieces that would be really important to you another thing we can see is event loop lag it's important to keep that lag low so this gives you kind of one extra level of granularity into a running application um

but you can actually there's there's other tools you can also use um and we're gonna thank google for this one i'm gonna open up chrome or chromium and navigate to chrome colon slash inspect and now if you remember i started my my uh node process with this dash dash inspect flag and what this did was it turned on debugging um or it allows chrome to hook into this running node process so just by default i went to chrome inspect

by default i've got this little target it says loadstar hey this is great um and what i can do here is basically get a chrome dev tools window just like you could get on any web page if you right clicked and you know went to the right setting but right now it's actually running load star it's actually running the uh this node process uh so we can do some we can we can do some really interesting things so like one question you might have is like all right well why is why is our sinking so slow like one and a half slots per second

well one thing you might be able to do is uh you can go to the profiler and you can start a cpu profile so we're going to be starting this it's actually it's starting on the node hopefully the note isn't breaking nope it's still good um but after a while we can run this for as long as we want after a while we can stop it and this should give us a flame chart so this flame chart uh shows give us a breakdown of what actually was happening over time um and we can see very quickly what there are certain things that are taking a lot longer

time than than other things so right away we can immediately see wow this process change segment that's that's what's taking a lot of time and in fact verify signature sets back if we see this happening a lot so almost all of our chain pro all of this process chain segment it's almost all verifying signature setbatch whatever that is um in fact it's bls signature verification so it's a just a very expensive operation but doing this you can really drill down and see um what's taking a lot of time what's not

try to find any hot spots and this is all happening on this running node so um you know as you're doing updates as you're changing the system every time you run your your application you can always hook into it and be seeing what the latest hotspots are another really great feature i'm not going to use it right now because there's not enough time but uh is it is doing a heap snapshot um we could take a snapshot one one issue with doing this is that it's gonna it would freeze the node um while you take a snapshot nothing else is running but what you get out of it is it will show you

in detail all of the memory usage of the running node so exactly what's being stored where what is referencing what and this is a really great way of of finding memory leaks finding references that are retained that are like you they shouldn't actually be there and you can actually you can actually bring any of those references down into uh the running console and then inspect them um writing javascript to to to go deeper and deeper um you can also uh you can also look at the source code for

anything that's running um and add breakpoints [Music] and step through any of the running code it may affect your peering and as your peers may not like that you're stopping the code but um it's a great it's a great feature for stepping through tricky pieces of the code and and going line by line to see uh if if if it's running the way you're expecting it to run uh so all in all this is i don't know if this is an underused tool or uh or not in my opinion i haven't seen that it's used a lot but i think it's a great it's a great way of debugging live javascript applications and it's

really definitely helped it's definitely saved our hide quite a number of times on lodestar and uh that's that's really it for me for now if anyone has any questions you can we can take them awesome caiman thank you for uh thank you for the talk um yeah it's i'm not a developer but um yeah it's just so cool to see like all these different tools and methods for uh debugging um things i see masei has raised his or her hand um you can feel free to unmute yourself and ask your question

hello i just want to say thanks for that really great uh presentation um this looks like a really cool tool um and i just wanted to ask if uh it like if you could if you could use it with like any node uh js uh application or if it's just with like is it is it just with um things related things that are like uh uh that are only for like blockchain or if it could be used with anything yeah good good question so this whole chrome dev tools can be used with any node application you would just need to make sure that whenever you're

running it you have to be sure that node is being called with this uh inspect flag um otherwise otherwise you're not gonna be able to hook into the application but yeah it can it can work with any node application the the metrics that would be something that the application would have to implement themselves uh kind of ahead of time so that that might may or may not be available cool thank you so much awesome we also have a a question from dap lyon bilford lion hey y'all

thanks for the dog good to see you all hey looking at this pls thing that it's very slow do you think it would be a good idea to put it on a worker thread like maybe absolutely um this is uh kind of maybe a trick question but uh this is something we're working on uh actively right now um um yeah bls is a great candidate for for being put on a thread thread because we could break up this work and um it's not necessarily sequential we can break it up and throw it off to these different web workers um and hopefully cut down a lot of like that time could be maybe cut in half and that would make our sync speed faster

but that's definitely something that you only know by actually looking at the hard data or like looking at something like a flame chart