Node.js Performance, Kubernetes, and Why “Fast” Isn’t Always Fast - JSJ 702 - JavaScript Jabber

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Welcome back to another episode of JavaScript Jabber. This week,
on our panel, we have Dan Shapire.

Speaker 2 (00:11):
Hello from a freezing wintry tel Aviv, sixty degrees fahrenheit.

Speaker 3 (00:16):
Thank you for rubbing that in.

Speaker 1 (00:17):
I know, I think it's below freezing here. We also
have Steve Edwards.

Speaker 3 (00:21):
Yo yo yo, coming at you from a slightly warmer
now Oregon, where we really need snow.

Speaker 1 (00:29):
Yeah. Also, Steve, word is that you are currently looking
for a Laravelle view job.

Speaker 3 (00:35):
Yes, something slnes would be nice.

Speaker 1 (00:39):
All right, So if you want to hire a Steve,
get a hold of him.

Speaker 3 (00:45):
This particular Steve would be nice.

Speaker 1 (00:47):
That's right. Do you want to put like contact information
out there?

Speaker 4 (00:52):
Yeah?

Speaker 3 (00:53):
I was gonna wait till shameless plugs at the end,
but yeah, you can my infos on my GitHub at
Wonder nine to five, same handle for Twitter. It was
probably the best way to get old Steve at s
mg a web dot com.

Speaker 1 (01:08):
Cool. I just want to make sure that yeah, people
hear it and they can reach you if they need to.
I'm Charles Maxwood from Top End Devs And this week
we have a special guest. We have Matteo Colina.

Speaker 5 (01:19):
Hello, I folks, Hey, Hi from for Lee Italy. It's
been a rainy day here and I'm staying it home.

Speaker 1 (01:28):
I didn't know you. I've been to for Lee.

Speaker 4 (01:34):
Really like not you won't even know that is where
he's on the map.

Speaker 1 (01:39):
Yeah, Pasatoduani in Italia. I was a missionary in Italy
and yeah, so I've been to for Lee and Remini
and wow, I lived in Oncona for like six months
so yeah, wow, Oh so you know.

Speaker 2 (01:53):
And we and we, my wife and I passed really
close by just when Matteo happened to be in London. Yes,
so we unfortunately kind of missed each other.

Speaker 4 (02:03):
That would been a rag.

Speaker 5 (02:06):
But my calendar these days during conferences and is close
to a nightmare.

Speaker 2 (02:13):
Well, all I can say is will probably be in
Italy again because we love Italy, and next time hopefully
we'll be able to actually meet.

Speaker 1 (02:23):
Yeah, I would love to go back. We had a
foreign exchange student who also lives in Oncona and so
we'd like to see her and her baby. So anyway,
what are we talking about that's not travel tech or
Steve needs a job.

Speaker 5 (02:39):
Today we're talking a little bit about the latest thing
in platformatic my company, and not j yes, I think
maybe with some ais pist in it, because you know,
everything is AI today.

Speaker 2 (02:54):
Yeah, a lot of our listeners may not be familiar
with Platformatic, but I think that if you're doing a
think with notes, there's a good chance that you're probably
using at least one thing from Platformatic.

Speaker 5 (03:05):
Like it's absolutely at this point, I think you're using
something from from Platformatic close to one hundred percent. Okay,
it's as I say, last year, I touched forty two
a billion downloads on NPM some some some impossible numbers
like that.

Speaker 4 (03:25):
So this is the state.

Speaker 2 (03:28):
So like every man, woman and child on this planet
is downloading stuff on Platformatic like ten times a year.

Speaker 4 (03:36):
I have no idea.

Speaker 5 (03:36):
Yeah, at this point, it's it's it's it's it's everywhere.
As I say, I am in everybody Dependency three.

Speaker 4 (03:45):
So I am the Nebraska man. I'm joking.

Speaker 1 (03:51):
Okay, I thought it was just your mom over there
NPM installed Platformatic stuff.

Speaker 4 (03:55):
Look, that can be possible. You know.

Speaker 5 (03:58):
I fixed that laptop for for christ So that was
the gift.

Speaker 1 (04:02):
There you go.

Speaker 5 (04:04):
So it's the one time over the over the year
that somebody can ask me to fix a computer over Christmas.

Speaker 3 (04:11):
The tech support.

Speaker 5 (04:13):
It's it's it's it's something that everybody does. So so
true talking about things we have since the last time
was year so what we have released a few benchmarks
okay that I think are pretty relevant for everybody to

(04:35):
look at. So let me just get them and so
that we can discuss them. I'm going to pass them.

Speaker 2 (04:43):
While you do. I was. I want to emphasize that
while I was obviously somewhat kidding before, it is absolutely
true that I kind of considue you to be sort
of mister no JS, especially now that Ryan Dalla has
moved on to other things.

Speaker 5 (04:59):
H It's well, I have been since this summer. I've
been nominated the chair of the no JS project. So wow,
I am effectively running the thing.

Speaker 2 (05:14):
Wow. I didn't even know that. Wow, that's pretty.

Speaker 5 (05:17):
It's an honor. Let's put it this way. It's an honor.

Speaker 2 (05:23):
Yeah, we talked about it slightly before we started the
show officially that I'm I'm you know, Node is not new,
obviously it's been around for a while, but I'm I'm
seeing Node usage actually increasing. A lot of organizations that
have previously been using other technologies for the back end

(05:45):
are adopting Node as their go to technology for back
end stuff. I don't know if it's because of the
Lambda functions and stuff like that, or it's because you know,
all the meta framework out there, Next JS and ten
stack and whatnot. I don't know. Maybe it's like everything together,

(06:06):
but I'm definitely seeing no JS technology usage pickup a
lot of companies. Like I was speaking at this conference
in Israel, and like every company that I was talking
to was doing something with no JS on the back end.

Speaker 5 (06:23):
Yeah, it's everywhere, Okay, right now, if you want to
build anything for the Web, you're using Note.

Speaker 4 (06:29):
If you're not using Note, you are probably.

Speaker 5 (06:32):
On a minority, and it's it might be good to
be in a minority. But the mainstream stack right now
is something React based plus no JS on the server.

Speaker 1 (06:48):
And I'm in the minority me too, I know.

Speaker 4 (06:52):
But you're probably using View. I've heard okay, Laravel Lvl, I.

Speaker 5 (06:58):
Would I would wonder, Okay, this is a how do
you do server side rendering with view on Laavo.

Speaker 1 (07:04):
If you use.

Speaker 3 (07:05):
Inertia JS, which is something I'm a big fan of
and I've talked about ad nauseum probably on here. Inertia
has a service side rending capability. If you're using View
with something like nuxt, it also has server side rending capability.

Speaker 4 (07:18):
Yeah, but then it's node right correct.

Speaker 3 (07:21):
Okay, point well, you asked how to do with view,
so that's how No.

Speaker 4 (07:25):
No, But it's say with knox is node.

Speaker 2 (07:28):
Yes.

Speaker 5 (07:29):
Is the inertia not no, not JavaScript running somewhere.

Speaker 3 (07:33):
Inertia is real quick. Is basically a glue layer between
your front and your back end that allows you to
plug and play. So you could use View with Ruby,
with Laravel, with Node, you could use you So you
could use viewsvelt react Angular on the front end, and
you could use laravl Node, Ruby on the back end

(07:54):
in any combination. So it's just it's crazy fast. I
have an application that I've built and maintained for a while,
and it's just amazing how fast it is. It basically
sort of hijacks the post request and the browser doesn't
do a full reload. You passes some headers that tell it,
hey don't do a full Perial railroad and communication between

(08:14):
the two point being, to answer your question, if you
go with inertia, there's service any capability.

Speaker 5 (08:21):
So if I want to do a Larrabell and view.
Then I can do that like I am seeing. Okay,
to be clear, I'm looking. I opened it up in
a second and I'm showing me some not js.

Speaker 3 (08:33):
On Well, it's possible. I haven't used.

Speaker 5 (08:37):
It's like it's the way to do these kind of
things typically is there is some no JS little notes
thing running and doing the job.

Speaker 4 (08:45):
I don't know.

Speaker 5 (08:45):
It somewhere, okay, because in the problem is that with
modern front and frameworks you need the areizomorphic. So you
have the same Java skipt code that runs on the
front and on the back end, and in order to
do some side rendering you have to render it on
on the back.

Speaker 4 (09:05):
Okay.

Speaker 1 (09:05):
So jovscripture on time on the back end.

Speaker 4 (09:08):
And you need a Java sleap run time on the
back okay to.

Speaker 3 (09:11):
Do this it's underneath. Yeah, okay, I get you.

Speaker 4 (09:14):
So this is why I'm saying.

Speaker 5 (09:15):
This is the point of there is always some no
JS everywhere in in In.

Speaker 2 (09:21):
And then kind and then PLATFORMA. They kind of flipped
the script there where you kind of put WordPress and
Narvel on top of note or something.

Speaker 5 (09:30):
Yes, So last last year we shaped a few experiments.
We were able to run full pitchp inside no JS.
It works really well. It's actually very performant, to be honest.
So there is literally nothing stopped that kind of those
kind of deployments. But it's let's see what the market says,

(09:55):
and if there is, if they are attractive for the market,
we will keep for showing those.

Speaker 2 (10:01):
Is it raging or something?

Speaker 4 (10:03):
No binaries.

Speaker 5 (10:05):
It is the actual PHP right high from the operating system.
It's the same thing. It's it's the same hooks that
the patchy uses.

Speaker 2 (10:12):
Hm hmm, Okay, now I understand what you're doing. That's interesting.

Speaker 1 (10:19):
So we were talking about benchmarking. Does how does this
tie back in?

Speaker 5 (10:23):
Yeah, so we've been doing this is the benchmarks. Okay,
we've done a few. I just wanted to point out
chew one is and let's see where the chat is.
Here is a chat.

Speaker 1 (10:41):
Yeah, there's a chat. It's on the right. It's got
a little chat bubble.

Speaker 4 (10:44):
Okay, here we go. I'm passing in the chat. So
this is one. I am passing it.

Speaker 5 (10:49):
The second one that we have done, and then I
have a few more.

Speaker 4 (10:58):
To talk about.

Speaker 5 (10:59):
So the first one is we've done last year. It's
a benchmark showing next JS performance. Okay, under very high traffic.
So for Next, yes, so what happened, What is happening
is we have done a lot of tests, okay, and

(11:21):
it's with a lot of tests for example, with one
thousand requests on per second for I mean, for a
couple of minutes on against next JS and those were
hitting essentially saturation.

Speaker 4 (11:38):
This was a hellower page.

Speaker 1 (11:39):
Okay.

Speaker 5 (11:40):
It's very normal for your system to go to if
you're using Next or a React based server side system,
to go between eight twenty, between eight and twenty maybe
fifty requests per second at.

Speaker 4 (11:55):
Best, okay.

Speaker 5 (11:56):
If you have a very complex system like it's low
okay in the genetic terms of things, okay. So the
critical point okay of this was the success rate, but
more important in the latency okay. The latency for this
kind of system is very bad okay. And this is

(12:19):
affecting a lot of companies out there, okay. And a
good chunk of that problem is due to our scheduling
is done of of multiple parts in kubernets okay, round robin. Unfortunately,

(12:39):
it's it's not the best algorithm most of the time, okay,
But the one that's the one we have. And last,
but not least, there is the problem of event look blocking.

Speaker 4 (12:53):
Event look blocking it's critical.

Speaker 5 (12:56):
So if the if the event look blocks, then know
the system becomes responsive after this, So it's it's it's problematic.

Speaker 2 (13:07):
But then the whole thing about note that the event
loup is kind of never supposed to be blocked.

Speaker 4 (13:14):
Well, tell that to all the developers using React, like,
that's the absolutely, that's the world point the idea. Yeah,
that's the idea.

Speaker 5 (13:27):
But reacts over side rendering is super expensive, okay, and
it's super expensive.

Speaker 2 (13:37):
So yeah, a lot of string operations and stuff.

Speaker 5 (13:42):
No, it's a massive So basically what React does It
creates a full virtual dam of all the elements in
the page and then it stringifies that and you need
to walk through a massive tree for every request.

Speaker 4 (13:55):
So this create a massive pressure on the GC as.

Speaker 5 (13:58):
Well as the computational cost of a locating of stringifying
all of those elements.

Speaker 2 (14:02):
That's really unfortunate given that it then immediately discards that
entire virtual dome exactly.

Speaker 4 (14:10):
You know why I've been a pretty like there is.

Speaker 5 (14:13):
The only framework that does better is solid I think
is significantly better on the topic.

Speaker 2 (14:18):
Okay, maybe because it doesn't have a virtual dome.

Speaker 4 (14:23):
This is a good point. This is actually a good point.

Speaker 5 (14:29):
Okay, And yeah, so the word point of note is
not blocking the end loop and I can really subscribe
to that sentence. Okay, So to the point, so to
the point that if the event look blocks for a
long time, it's better to kill that node process and

(14:51):
start a fresh one up because keeping that running is useless.

Speaker 2 (14:57):
Yeah, if you're going to be doing really significant GC,
then why I mean, just you know, I'm reminded of
what the Apache I think the approach was about, like
managing like the heap in in like sort of chunks

(15:19):
and then discarding the entire chunk rather than trying to
do fun grain GC.

Speaker 5 (15:24):
Well, it's to some extent is relatively similar what we
are doing. So with what or not just application server
we have based on this on this thing, we can
monitor the state of the event loop from the outside
and if you detect it, it is totally blocked. Nothing comes true,
nothing is going to come through. We just shut the

(15:44):
shut the thing down. So and because we can, we
shut the thing down and we started from and restart,
we can essentially recover a really broken pad back to
life and let some traffic pass through.

Speaker 2 (15:59):
So the basic idea is saying, instead of trying to
do this really really complex GCS at a high frequency,
because of all the incoming requests, every once in a while,
just kill the pod and start fresh.

Speaker 5 (16:15):
Well, it's when the event will be is blocked. So
it's literally like when there are too many like. The
problem is also that there are all those requests are
piling up to be processed and after five seconds it's
no point.

Speaker 4 (16:29):
There's no point in processing them. You' just abort them.

Speaker 2 (16:32):
And it's because of the GC, because of the virtual dome.

Speaker 4 (16:36):
It's all of both of them.

Speaker 5 (16:37):
It's it's a very it's a very superre intensive operation,
especially with a lot.

Speaker 2 (16:41):
Of interesting You would think that they would have figured
it out a way to offload it to workers.

Speaker 4 (16:50):
Or something, which is what we did.

Speaker 2 (16:53):
Is that a different thing or the no.

Speaker 5 (16:55):
So basically with what we can have multiple workers listening
to the same socket so that you can do the
load balancing easier. It's very similar to say, oh, it
is similar to nod cluster or PM two and not cluster,
but instead of doing the load balancing inside not JS,

(17:16):
which is what nod cluster and pmhould do with in
that we use a new node feature that let us
do load balancing inside the kernel using scores, a flag
calls so on the score reuse port, which is significantly faster.

Speaker 2 (17:34):
Can you elaborate a little bit about what actually is?

Speaker 5 (17:38):
Because it's an application showy for not JS, you can
just give it your app. It will run it inside
a worker thread and the main thread will just minor
it and you can scale it up and down multiple threads,
multiple course, and if you want, you can even have
aterogenerus system. You can have multiple different applications running there
and they can communicate via message passing or just h GDP

(17:59):
over memory.

Speaker 2 (18:00):
See so what does it compete with? What are they like?
When would I use what? And would I put like
next JS? On top of what?

Speaker 5 (18:10):
If you're if you're deploying not JES in Kubernetus, you're
probably not doing the not doing the right thing if
you're not doing it today using what?

Speaker 2 (18:19):
Yes, what does it stand for? By the way?

Speaker 4 (18:23):
What come on? What can what be? Can that be?
Come on?

Speaker 2 (18:29):
How do you exactly spell it?

Speaker 4 (18:31):
W A T T. It's an honor to over James vat.

Speaker 2 (18:36):
Ah Okay, yeah, the power. Yeah, so we need a name.

Speaker 4 (18:44):
So on MPM is VATPMH.

Speaker 2 (18:46):
I now I sit in your blog post. Yes, so
whenever I use node in Kubernetes, you recommend using it
on top of what I.

Speaker 5 (18:55):
Would say, Yes, it gives you more reliability in this
example with jes that I've shared in the chat, essentially
we can move down P ninety five from a second
to two one hundred and thirty five milliseconds.

Speaker 1 (19:12):
Oh wow. And just for those who don't follow along
with benchmark stuff of P ninety five, is ninety five
percent of your requests take this long or less?

Speaker 2 (19:23):
So in other words, yeah, beneficial for the five percent
slowest users.

Speaker 4 (19:29):
Is beneficial for everybody.

Speaker 1 (19:30):
If fits for everybody. Yeah, essentially, Yeah, so all the
all the requests now, so ninety five percent of the
requests instead of taking up to a second, now take
up to two hundred and thirty five milliseconds. Now you
assume that the other five percent it also speeds up
for But yeah, that's kind of the measure, and it's

(19:51):
it's one of the more common ways of measuring how
fast your application is because the load and the requests
and what it has to do and what else is
running on the machine can vary from time to time,
and so this kind of averages it out.

Speaker 2 (20:03):
Also, think about it from the perspective of a business
loto you like, you want to think about the customers
that have it the worst, and you can't really afford
to lose five or ten percent of your business because
it's just too slow. Exactly. But I'm thinking about what

(20:26):
you said. It does mean though, that you want to
allocate more than one CPU per yes, no instance in
your kubernets in how.

Speaker 4 (20:37):
You absolutely this actually helps. Okay, let me explain why
it helps.

Speaker 5 (20:43):
Okay, The cost of spinning up a new pod in
Kubernatis is more or less fixed independent of the amount
the amount of resources that are attached, okay, or anyway,
it's not very much different.

Speaker 4 (21:03):
Okay.

Speaker 5 (21:04):
If I am scheduling largest things, each unit of scale
gives me more power to handle my spikes better. So
it's the edges of scaling are a little bit steeper.
But this actually helps smooth the curve way quicker because
these new things.

Speaker 4 (21:26):
Make it.

Speaker 5 (21:28):
Can handle more load per unit. Okay, So this is
one thing.

Speaker 1 (21:33):
Okay.

Speaker 5 (21:33):
The second thing is Kubernatis takes minutes to scale, so
when the load typically reacts in one two minutes is
very slow, tiny to to to schedule things up. And
by having this system you can actually absorb the shock
completely inside your pods.

Speaker 2 (21:52):
Interesting, very interesting. I need to think about this some more.
I will definitely make sure that our develops people see this.
I mean literally everybody is using kubernets these days, whether
they need.

Speaker 4 (22:06):
To exactly exactly.

Speaker 5 (22:09):
We also have built, but it's not mentioned in this benchmark,
built another product called Intelligent Command Center that is open
source as well, that reduced the decision time of kubernets
from minutes two seconds. So the pod starting is down

(22:32):
is making less than five seconds the decision to start
a new part.

Speaker 2 (22:36):
Doesn't that make the system kind of more noisy.

Speaker 5 (22:40):
Yes to some part, not to the other, because it's
actually it's actually very fast in scaling up. Okay, but
it can scale up on very specific signals from the app,
so it and so it can be a little bit
more noisy, but it actually allows you to reduce your

(23:00):
baseline of instance significantly.

Speaker 2 (23:03):
So you can scale up when you need to.

Speaker 5 (23:06):
You can scale up way quicker when you need to,
so you can reduce your baseline and during off peak
hours you can actually save a lot of Yeah.

Speaker 1 (23:15):
I guess that's always the thing that I'm concerned with
when you have this kind of automation, is, you know,
does a scale up too much? Does it? You know,
does it handle things when you know when I need
it to scale down? Because yeah, it costs a lot
more when you scale way up. But if that's what
you're getting in traffic, and usually traffic translates in some
ways to money, not always, but yeah, so that anyway

(23:41):
pretty cool.

Speaker 4 (23:42):
So this was part of our results.

Speaker 5 (23:45):
We published this study, okay, and hopefully we can get
some results from our rock click customer down out soon.
But this is our own and all the benchmarkt and
ernests done for this is open source, so you can
check it out and run it yourself.

Speaker 4 (24:02):
If you're this.

Speaker 2 (24:03):
Should be making a lot more noise than it is.
I think I was kind of aware of this, but
I was not fully aware of this. And like I said,
literally everybody is doing non kumberinators these days. So if
the impact is so dramatic and so significant and so
readily achievable, yes, you know, there's literally no reason not

(24:29):
to try it out. This is.

Speaker 5 (24:33):
Partially the reason why when you asked to come to
join the show. I said, I'm coming join the show.
This is the research that we published. So we published
late last year, I think, and it's pretty solid.

Speaker 4 (24:49):
I would say. Then we have done another article.

Speaker 5 (24:57):
Okay, I'm more spicy one if you if a more
spicy one, I would say, okay. And we benchmarked on
the same benchmark on the first one, slightly different traffic
load whatever, Okay. We benchmarked the note the tree no

(25:17):
dress run times in Kubernetes so bunn no JS as
well as our own way of scheduling things with what
so we got some really unexpected results, not the results
that I would expect, and it showed that bun So.

Speaker 2 (25:41):
Just before you you tell what you found, just to clarify,
what is only for node, it's not for the other
For the other platforms, you can't use it to DNO
with bun.

Speaker 4 (25:52):
No you can't.

Speaker 5 (25:53):
Well like you can't because those other platforms are not
fully not GS compatible. And the approach that we have
taken with what is instead of creating a custom built
not just run time with our patches, we have upstream
all our patches up to note core of the things
that we needed, and that is only is written mostly

(26:17):
in JavaScript mostly every now and then we had to
have a little bit of C plus plus to implement
some feature for all not Jazz versions.

Speaker 4 (26:28):
That are not being released yet.

Speaker 5 (26:30):
So if we need a feature, we need to extend
support for it.

Speaker 4 (26:35):
But it's right now, I think it's all JavaScript.

Speaker 1 (26:40):
I have to say before you go too much further
that I like this idea of hey, we needed this
in node in order to make what work, and so
you contribute it back and so it's stuff that other
people can use.

Speaker 5 (26:52):
Exactly one like this is the whole point. Like part
of the reason why I funded Platformatic was can I
try to build a business that can uh make the
open source economically viable and and allow us to grow
with it? So let's try. This is the this might

(27:15):
try Okay, I might succeed, might not succeed. I hope
I succeed, but I needed to try this. So my journey.

Speaker 1 (27:25):
I'm going to go into a tangent here real quick
because I'm kind of curious. So when you say make
the open source uh economically viable, what do you mean?

Speaker 2 (27:33):
Like?

Speaker 1 (27:33):
What what the fundamental point is?

Speaker 5 (27:35):
The fundamental point is there is a substantial lack of
investment in core technologies from companies, and we need more
companies that are that invest significant amount of money into

(27:59):
the commons.

Speaker 4 (28:00):
In order to do so, we need them.

Speaker 1 (28:03):
To be.

Speaker 5 (28:04):
Economic, to be good businesses so they can contribute back
and up. Okay, And you cannot rely on the sponsor
model because it's too little, too late. So you need
if you need to pay to do payroll, you need
to have significant sales involved. So the goal is to

(28:30):
build a significantly big enough company that can afford multiple
people and working full time on the core technologies, and
not because it's it's a good thing to do, but
because it needs them to be there as a core
function of the business so that it's not a donation,
it's a function.

Speaker 1 (28:50):
Okay.

Speaker 5 (28:51):
And because it's a function and it's a core part
of it, it will not stop.

Speaker 2 (28:57):
And what is that company selling them?

Speaker 1 (29:00):
That was what I wash.

Speaker 5 (29:02):
So our current business model okay, after several pivot iterations
and stuff, we sell enterprise version of all our technologies
plus support and on boarding. So if somebody needs anything
related to no JS, we can provide support, We can

(29:24):
provide and we can provide an enterprise license for our
core technologies and include.

Speaker 2 (29:32):
What does an enterprise license.

Speaker 5 (29:33):
Mean this is an answer for Michael question for micro founder. Okay,
so there is for the Intelligent Command Center.

Speaker 2 (29:45):
There is a.

Speaker 5 (29:48):
Premium version with added features for example like more audit controls, loggins,
these kind of things so far, but it will grow more.
It's more related to SLAS and response to incidents and

(30:08):
being available that.

Speaker 4 (30:11):
Like other things.

Speaker 1 (30:13):
So it's more on the support side than the future side.

Speaker 5 (30:17):
It's the future side is more on all these technology
are moving dynamically, so they our customers can steer, can
steer the wheel and I'll pass the side.

Speaker 4 (30:29):
Where we go next?

Speaker 5 (30:30):
And what what they need? What features are missing? And
you know their partners.

Speaker 2 (30:34):
I think that esslas are the way to go, to
be honest, To.

Speaker 4 (30:38):
Be honest, I would say they sell very.

Speaker 2 (30:39):
Well because like literally, if I'm running your back in
my back end on node, I need ESLAS and and
if you know, if I if I can out kind
of guaranteed by licensing your services, then it's no brainer.

Speaker 4 (31:01):
That's what it is. So anyway, that's exactly the point.

Speaker 2 (31:07):
Cool. So now let's go back to where we were
before we went on the tangent.

Speaker 4 (31:12):
If we can remember, yeah, okay, we can go on
the tangent all the time. So anyway we are, I
was chatting, I've over the break, I've done this extensive
benchmark on band Dino and note okay, and I got
very surprising results. The benchmarks included running the same next

(31:34):
Jaess application that.

Speaker 5 (31:35):
We talked about before. Okay, reactions are rendering? Have your memory?
Have you on CPU?

Speaker 4 (31:41):
Really like.

Speaker 5 (31:44):
Possibly the worst load but also the most common load
that you can have running on OJS these days, And
I got very surprising result that I didn't expect them
to be so specifically.

Speaker 4 (31:59):
I got but p ninety nine of.

Speaker 5 (32:08):
Seventy four milliseconds for ban one three dot five they
did new versions of.

Speaker 2 (32:13):
So approximately one second.

Speaker 5 (32:16):
Yes, well not JS was one hundred and seventy four.
Do you know at one hundred and not JS with
what at one hundred and fifteen?

Speaker 2 (32:27):
So Bun was noticeably slower than everybody else exactly. To
be honest, I know that Bun has a reputation for
being fast, but the people need but people need to
understand that fast can mean different things in different situations.

Speaker 4 (32:45):
Exactly that.

Speaker 1 (32:47):
Well, I hear people tell other things about Bun too,
but yeah, you run a different application the different engines
manage memory differently and concurrency differently than other things differently,
and so yeah, it's.

Speaker 2 (33:00):
Beyond a different application. I think it's it's like a
different scenario, yes, because you've got you've got startup times,
and you've got and you've got run times, and there's
a question of when optimizations kick in. If they kick in,
what do you do in the jet stage stuff like that.

(33:21):
So what could be really fast for a long running
a no type service could be really slow when you're
building a utility that just runs, does something and then terminates,
and an expectation that a certain platform will do everything
better is well, it's happened before, but it's not always realistic.

Speaker 4 (33:47):
It's so a few notes.

Speaker 5 (33:50):
Okay, after chatting with a few people, they gave me
this informal feedback. You can take what we do with
a gain of salt jsc which is the JavaScript run
time behind ban and Safari is optimized for cold starts
to start very immediately. Imagine when you open Safari on

(34:11):
your iPhone, it opens up super quick.

Speaker 4 (34:14):
Okay, while V eight is more optimized for running or
wrong running application. Thanks Jmail.

Speaker 2 (34:25):
Yeah, that's the thing, you know, people talk about like
the various You know, there's this been trend of rewriting
the JavaScript utility ecosystem in other programming languages, be it
go or be at rust or be it whatever, instead
of doing it in JavaScript or typescript. And you kind

(34:47):
of hit your head on the nail there, matel Because,
for example, if we think about.

Speaker 3 (34:51):
And that's a nail on the head, not head on
the nail unless you really want to hit your head
on the nail.

Speaker 2 (34:55):
Or is that what I said? Yeah, okay, just.

Speaker 1 (34:58):
To point ound was painful.

Speaker 2 (34:59):
Well know Hebrew we right, we right right to left.

Speaker 3 (35:03):
So well, but I mean, gives gives new gives new
meaning to the term hammerhead, doesn't it.

Speaker 2 (35:09):
Yeah? Anyway, what I was saying is that the JavaScript
optimizer in EA, I always forget the name whether is
a turbo fan or what.

Speaker 4 (35:18):
A turbo fan. We also have mag Lab now.

Speaker 2 (35:22):
But yeah, it's basically based on identifying hot code and
then optimizing that while the code is actually executing. But
in order to identify hot code, the application needs to
be running for a while. And if you're running a
tool that just starts up, does its job and then finishes,
you'll never get to that optimization stage.

Speaker 5 (35:45):
Exactly, which is long enough you get into that optimization state.

Speaker 2 (35:52):
Which is kind of my concern by the way, with
some Lambda function usage.

Speaker 4 (35:58):
Well, I let me say this, if you are moving
serious traffic, you are probably better served using ECS or
cobnetis or whatever long running process. But to be honest,
Lambda actually okay, let's let's go. Let's open the lambda

(36:20):
point because it's actually a validation of that to some extent.

Speaker 5 (36:25):
So if you if you have followed what has been
launched by a w as in the latest the latest
rainvent in December, is a new Lambda run time for
I troueput scenario I traffic scenario that is not actually
one request per process, okay, but it allows one process

(36:46):
look at this to have as many threads as it
wants to end or requests in a lot of things.
Is actually similar to how that works internally in how
the things are scheduled. So this kind of system allows
Lambda to.

Speaker 4 (37:06):
You know, use all the potential of no js essentially
and actually leverage these long running optimizations that we talked about.

Speaker 2 (37:17):
Interesting.

Speaker 5 (37:19):
So it's actually very interesting model, and a lot of
people are not you know, tapped into this yet, like
they think, oh, no, jes single treded or mostly single traded,
while in reality it's not, and you can do a
lot of interesting things with it, and they just you know,
ignore the point.

Speaker 2 (37:38):
Well to be to be honest, no, JavaScript is a
single threaded language, but Node and the JavaScript Virtual Machine
has never really been single threaded.

Speaker 4 (37:51):
So it's exactly so for.

Speaker 2 (37:54):
Those of you who don't know. For example, the VGC
actually runs off of the main thread to significant extent.

Speaker 4 (38:03):
Yeah, well it has been, not at the beginning.

Speaker 2 (38:06):
Not at the beginning I'm talking about currently.

Speaker 4 (38:09):
Yeah, yeah, it's it's it's off the of it.

Speaker 5 (38:12):
So anyway, I just wanted to say we got these
incredible results, like not expected, to be honest, I didn't,
like I had to check them five times and have
to have some friends check them with me.

Speaker 2 (38:23):
So why was it expected? You you didn't expect such
a band to be that slow in that particular test, yes,
And did you expect Dino to be that fast by the.

Speaker 4 (38:33):
Way, yes, yes, significantly. I was expecting Dino to have
those kind of numbers.

Speaker 2 (38:40):
I think that's a scenario that they've been optimizing for, right, No, no.

Speaker 5 (38:44):
No, it's the way so they their dino event loop
is based on Tokyo, while no event loop is based
on libuv.

Speaker 4 (38:56):
Okay, and Tokyo is.

Speaker 5 (39:00):
Be a decade later than libv type of thing, and
by things have improved, you now you do those kinds
of things, okay, And it's very hard to chase something
like libuv understood, So there is that is the problem,
Like it's it's not just LIBUV by the way, it's

(39:20):
also the node machinery in entirety. So how we get
the data out of libuv, how we schedule new connections
and we do all Like there's a lot of work
over there and a lot of over it, but some
of that over it is essentially legacy, and it's very
hard for us to like it's possible, it would be
possible to optimize, but it's a hell of a lot harder.

Speaker 2 (39:42):
So could you remind me again what the numbers are
for node versus note with what.

Speaker 4 (39:48):
So on p.

Speaker 5 (39:49):
Nineteen nine we add one hundred and seventy four millisecond
I may we measured one hundred and seventy four million
second with node and with what one hundred and fifteen.

Speaker 2 (40:00):
One hundred and fifteen that's one one five.

Speaker 4 (40:03):
Yep, one seven four versus one one five.

Speaker 2 (40:07):
So we're talking about close about thirty percent reduction, forty
percent reductions.

Speaker 1 (40:12):
Something like that.

Speaker 2 (40:13):
Yeah, that's significant.

Speaker 4 (40:15):
I know last Dino VAT and Dino are very close.

Speaker 2 (40:19):
And that's the SSR scenario.

Speaker 4 (40:22):
Yes, by the way, So I guess.

Speaker 1 (40:23):
What I'm wondering is is so for the people watching
at home right this, you're throwing out numbers and scenarios,
But what does this look like for me? Right? So
I have a next JS setup, or i have a
note application that I've written, and I've got React on
the front end and I've got server side rendering setup
or whatever, like, how does this actually translate? And what

(40:46):
does this look like when I'm troubleshooting or you know,
measuring my own benchmarks or things like that.

Speaker 5 (40:53):
So the key difference is the point of so when
you're doing in your is when you do saturation or
stress testing. Stress testing, so you're putting it to a
very high load scenario and you want to know when
your up breaks.

Speaker 4 (41:13):
And essentially.

Speaker 5 (41:16):
These numbers tells create more or less ranking of where
your applications stay responsive and is usable by the end user.

Speaker 4 (41:25):
Okay, in those scenarios, I'll.

Speaker 2 (41:28):
Give another way to look at it. You're doing SSR
to improve application startup times. Yes, that's the primary motivation
of doing SSR. And what we've literally learned now is
that you might be doing SSR with the goal of
improving startup time and end up part of my French

(41:52):
screwing yourself because your back end will not be able
to properly handle the extra load. And I'm actually looking
at the Crux data. We've spoken about it on the
show on several occasions, so a quick reminder what it is.

(42:14):
Google collects anonymous performance information from all browser sessions or
Chrome browser sessions and unless you opt out, and it's
not really easy to opt out, so assume it's more
less everybody. And they are looking and then they are
breaking it down by technologies used using the HTP archive.
So basically for each domain, they're looking if a domain

(42:37):
has sufficient amount of traffic, so they're looking at the
top ten million domains more or less in terms of traffic.
They're segmenting them by technologies used, and then they actually
release this information to the world so you can actually
see which technology is more likely to give you better performance.
And I'm currently looking at the graph that compares all

(43:01):
the websites within cracks, the WordPress websites, the Wix websites,
and next JS websites. And I'm looking at what percentile
of websites get good performance results. According to Google, it's
the cob vitals. Okay, wow, yeah, And if we're talking
about all technologies, we're talking about about fifty one percent,

(43:25):
So approximately half of websites get good coed vitals and
about half get poor web vitals. If we're talking about WordPress,
the number is forty six percent. So WordPress is slightly
lower than all technologies at large, but pretty close. So
WordPress and all technologies is more or less the same.

(43:45):
Maybe also the fact that like half the web runs
on WordPress. Wis currently is at seventy three percent.

Speaker 4 (43:54):
And what is this website? Is the cracks data set? Right?

Speaker 2 (43:57):
Yes, I can send you. I'll put the link in
the chat.

Speaker 4 (44:00):
An Houp going fantastic. I found it.

Speaker 2 (44:03):
So Wix has seventy three percent. So if you're building
a website on Wix, there's a seventy three percent probability
that you will be getting good performance. Okay, what's the number? Sorry,
what's the number for next JS? Now you assume that
next YS would be great because the whole thing about
next GS is that it's as SARRD. So what's the

(44:27):
probability for next gs?

Speaker 1 (44:28):
Can you guess feel like you're setting me up to
let me down so well, I would have assumed before
you said it, kind of skeptically that it'd be you know, yeah,
somewhere around wis you know, sixty seventy percent, but you're
making you're making it sound like it's probably like thirty percent.

Speaker 2 (44:47):
Exactly, it's twenty nine percent. So the probability of getting
good performance when you're using NEXTJS, you know, you're you're
putting all this effort into building let's say AI is
not doing your entire job yet you're doing putting all
this effort in encoding your website and react and hosting
it and whatever you and your probability of getting good

(45:09):
co ed vitals is less than thirty percent, And that's
really unfortunate.

Speaker 1 (45:16):
Yeah, that's bad. So the stuff that Mateo is talking about,
then do you do you get those kinds of performance
increases kind of for free just by upgrading your note
or make.

Speaker 4 (45:28):
It better by using what on top of next which
it just works.

Speaker 2 (45:32):
So it's not and I can do it on versall, no.

Speaker 5 (45:36):
Versall ransom your own thing. So the fundamental problem, the
fundamental point is next JS is designed to run well
on versall and to run it well on your own infrastructure.
You're missing a few components, and we added those few.

Speaker 2 (45:53):
So with verse cell out of the box, I'd be
getting comparable performance to what I have.

Speaker 5 (46:00):
Absolutely no idea. I've not measured. I've not benchmarked their cloud.
To be honest, I don't even it's a good product.
I am a customer like Performati is a customer overrsell. Okay,
we are as most startup. Is the greatest thing ever
to be using perself. Okay, yeah, it's easy, it's easy.
There are a lot of companies out there that cannot

(46:22):
use yourself for all sorts of reasons, okay, from and
that is critical.

Speaker 2 (46:29):
I know that the companies are running next gs on
top of Amazon a.

Speaker 4 (46:34):
W Yeah exactly, So this is what I'm saying.

Speaker 5 (46:36):
Okay, they are running those things, and there is even
a thing called open next run it on top of
cloud Flare and other stuff. Okay, what we've done make
it run very well on top of Kubernetus.

Speaker 2 (46:51):
By the way, I'm curious, what's your opinion of nest JS.

Speaker 5 (46:55):
You're asking me tough questions, then I am not I
am I do have opinion.

Speaker 4 (47:04):
I have one opinion.

Speaker 1 (47:07):
Nest is the back end framework, specifically, isn't it?

Speaker 2 (47:10):
Nest is like NOE for Java developers I have.

Speaker 5 (47:17):
I have a problem with it. Okay, the problem I
have with nest is its reliance on the old time
skip decorators. So I don't know if you've been following
the story of Java skip decorators with the year thirty nine.

Speaker 2 (47:39):
That standard that never ever materializes. It's been stuck in
stage two and a half like forever exactly.

Speaker 4 (47:49):
So the problem is that.

Speaker 2 (47:54):
Just you know what, before you do, let's just clarify
that all our listeners I kind of assume that listeners
were familiar with Kubernetes, which might have been either correct
or incorrect. An assumption to make, but let's not assume
the same for decorators. Decorators are a language feature in
JavaScript or typescript which allow you to decorate function method

(48:19):
classes and methods and properties. You put the ad sign
and then some words, and basically it wraps the declaration
in a function call and that function call can modify
the actual class definition or the method definition. So for example,
let's say the canonical example is I want to print

(48:44):
out a log whenever a method enters and exits. Instead
of explicitly adding a log everywhere, I can decorate the
class maybe and thenates automatically. It basically modifies the behavior
of all the class methods. Whenever I instantiate the instance,
I get this functionality automatically. So it's a it's a

(49:05):
way of implementing cross cutting concerns.

Speaker 4 (49:09):
Yes, it has two problems though, Okay.

Speaker 2 (49:13):
Oh, just to finish it's it's been a part it's
it's very very popular in in Angular. Uh, it's been
part of typescript for a while, and there's a proposal
to add it to the JavaScript language itself, which, like
we said, is kind of stuck in purgative.

Speaker 4 (49:35):
Yes, okay, let me explain the situation there. Okay, So
the current so this pack.

Speaker 5 (49:46):
As it was originally proposed and done in typescript okay,
all types types four and something okay, and before was
was very hard to poly fil Okay. If you look
at the JavaScript code that is being those syntax transpiles to,

(50:07):
you can get very scared.

Speaker 4 (50:09):
Okay, lets let's go eight. It's like regenerator style things.
I don't know if you ever looked at the cover
of what our generator does, but is pretty ugly, okay,
because there is a lot of global state. There is
a lot of things happening. It's not nice.

Speaker 5 (50:31):
Then the standard changed in a way that it's essentially
Java is essentially function wrappers okay, which can be attached
to classes because classes are functions okay, or functions okay,
which makes it way easier to to reason about this thing, okay.

(50:52):
And also it's just a function, so it literally is
easier to you know, implement some extent.

Speaker 2 (50:59):
The function that gets cold with the function as its
argument and in context, and then it returns a function
that gets used instead of the original function.

Speaker 4 (51:08):
Exactly, Very straightforward, Okay.

Speaker 1 (51:11):
I was just thinking, Yeah, it sounds like I'm still
not sure I follow anyway.

Speaker 4 (51:18):
Anyway, It's it's simple, but there is a difference, okay.

Speaker 5 (51:21):
The old standard allowed to attach decorator to.

Speaker 4 (51:27):
Arguments parameters hmm.

Speaker 2 (51:29):
Yeah, and nest chess uses that a lot.

Speaker 5 (51:33):
Exactly, and in the new standard this is not possible.

Speaker 2 (51:38):
Anymore because they're not functions. They're just parameters.

Speaker 4 (51:42):
Exactly, and and that is my world problem.

Speaker 2 (51:49):
Okay, that nest chess is tied to a syntax which
goes against the grain of where JavaScript is heading exactly.

Speaker 4 (51:57):
Also, its transpiled is really bad. That's it.

Speaker 5 (52:03):
I care a lot about the Java skity is being executed,
and that is transpiled to some really two things that
I would not have running on my servers.

Speaker 2 (52:16):
I'll say it again. It's really popular with people that
come to note from Java, so I know a lot
of back end developers that literally swear by it. It's
a back end that you use as a back end
for API. Course. Yes, it's it's not about necessa or
anything like that exactly.

Speaker 4 (52:36):
But I am, I am.

Speaker 5 (52:37):
I have a side on all of this, so you
can take all of what I said with a gain
of salt. I have built to Fastify to solve this problem.
Been using it for the last decade and very happy
with it.

Speaker 2 (52:49):
Yeah, it's really opinionated anyway. Moving But in terms of performance,
what can you say aboutn SGS.

Speaker 4 (52:57):
I have not benchmarked it signific Okay.

Speaker 5 (53:01):
I suspect is slower than Core Express or Fastify. You
can use Express or Fastify underneath, and I suspect is
slower and it adds a little bit over it on top.

Speaker 2 (53:13):
Yeah, it has to kind of because it's literally built
on top of it.

Speaker 5 (53:16):
So yes, I hope is as little as possible. But look,
you're asking so you might get an article on it.
So I'm my co found is telling me to do it,
so to do the research. So I'll do the research.

Speaker 2 (53:34):
I can say that it's pretty popular. It's popular to
the extent that it's boring, you know, like the best
compliment you can give about the technology is that it's boring.

Speaker 4 (53:44):
Yeah, I know, I know, I do the same.

Speaker 2 (53:47):
Okay. So moving back to what we were talking about
with so you talked about the surprising results that you got. Now,
so obviously, if I'm running the bottom line is that
if I'm running currently node on Amazon, and especially if

(54:07):
I'm using it for a s SR, not necessarily, but
especially if I'm using it for as SR, then I
should be looking at what because bun won't save me
pretty much. And okay, cool, anything else to add on
that particular.

Speaker 4 (54:23):
Topic, Nope, I think I covered it all.

Speaker 2 (54:26):
So you had a list, let's go to the next one. Yay.

Speaker 1 (54:29):
So so just just on the issue of time. We
have been recording for about an hour, which I'm totally
fine sticking around for however long, but I need.

Speaker 5 (54:42):
To probably go at when these meeting ends that I
have on my calendar.

Speaker 2 (54:47):
So that doesn't it just means that you want to
bring it on and I bring you on again.

Speaker 5 (54:51):
Absolutely, I'm coming again. I'm coming again, of course.

Speaker 4 (54:58):
Okay.

Speaker 5 (54:59):
So the second one that I wanted to cover is
the topic of flame graphs. Now, in all of these
benchmarking to do a lot of optimizations and look at things, okay,
and we created a brand new frame graph tool to
do performance analysis.

Speaker 1 (55:18):
I don't know what a flame graph is, So imagine
that you are.

Speaker 5 (55:25):
You want to do a performance optimization. Okay, you have
you know your application is low, and you want to
know where it's low.

Speaker 4 (55:31):
Okay. A flame graph shows.

Speaker 5 (55:34):
You the hottest points in your code base that consume
the most time.

Speaker 1 (55:42):
Okay, I've seen them, I just didn't know that's what
they were called exactly.

Speaker 4 (55:45):
Okay.

Speaker 1 (55:46):
So Cinema GRAPHA and a new relic, so yeah.

Speaker 4 (55:49):
They can.

Speaker 5 (55:50):
You can click a button and get the flame graph.
The key point is you the flame graph abstract time.
So it takes an internet of time and says, let
me represent this the function calls that happen in this
interval of time. Okay, because in that way, I know
how much a function is being called compared to the others.

Speaker 4 (56:08):
So I can make a comparison.

Speaker 5 (56:10):
Okay, so I can, so we can detect how much
function was called and how hot it is.

Speaker 4 (56:16):
Okay, but I've been doing this for for a long time.

Speaker 5 (56:21):
I created the second kind of two third generation tool
that I create with these kind of things. Okay, a
new version of note require differently tools to get it done.
PingER Cross is the last, but probably there will be
another one in a few years.

Speaker 4 (56:35):
Okay.

Speaker 2 (56:36):
Now, somebody who's listening to us and here's a flame
graft to measure NOTE performance might be thinking, Hey, why
do I need this from a platformatic where I have
it built into dev tools for like forever for why

(56:57):
do I need at another one? What's wrong with the
one that's built in death tools.

Speaker 5 (57:01):
The tools gives you a flame shart, not a flame draft.
It's not as readable, it doesn't give you the full picture. Also,
it's the way. The part of the problem is the

(57:23):
collection of that data is very expensive, so by running
it in the tools, you are essentially altering, like the
act of observing something modifies the behavior.

Speaker 4 (57:40):
Quantum mechanics, right, Yeah, it's quantum mechanics at play.

Speaker 2 (57:44):
Yes, just to clarify, I'm aware of the issues and
I totally agree with you. I'm just bringing it up
so you can rebut it perfect.

Speaker 4 (57:52):
Okay.

Speaker 5 (57:52):
So it's quantum mechanics at work. You observe it, you
change it.

Speaker 4 (57:56):
Okay.

Speaker 5 (57:57):
The way the what we have done instead of relying
on the inspector to to get that data, okay, we
are using a C plus plus module from our good
friends at Data Dog that they're using their agent to
collect those data from C plus plus straight out of
the eight in the fastest possible way. So it does

(58:19):
not interfere much with the application itself to the point
that you can use it in production to collect those
flame graphs. Now, if you try to enable the inspector,
you are looking at a fifty percent performance job.

Speaker 2 (58:32):
It's beyond that. First of all, let's start with the
fact that you probably don't want to attach the development
tool to your production environment. Yes, somebody might click pause,
Oh yeah, you're not going to be running in production

(58:55):
Node servant production with as inspect you know, yeah, yeah,
and you're not and you're not going to believe that
that port open. Well, you know, you can do it
as such tunneling and whatnot. But anyway, and like Matteo said,
the overhead of actually doing a flame chart is really high.

(59:21):
And by the way, also for that same reason, it's
time constrained. You can't run it forever. You can run
it for a very limited amount of time. Now, I
have in the past implemented certain scenarios in certain applications
where we sent a signal or an event into a

(59:42):
process to kind of trigger it. But it's you can again,
you can only run these sort of things for a
really limited amount of time.

Speaker 4 (59:52):
Exactly.

Speaker 5 (59:54):
You can also still run this kind of tool for
a limited amount of time, So it's a you know,
you can even the way you do it, you run
it for essentially one minute to collect what's happening. And
in our platform, we can even start collecting it when

(01:00:14):
usage goes over a certain threshold, so that you know,
you don't you're not wasting money. But it's actually very good,
so you can actually.

Speaker 4 (01:00:28):
Even running in production get good data out. Data Doctor
is running this in production all the time. It's fantastic.

Speaker 2 (01:00:34):
By the way, I have to say, it was really funny.
So when I found out about this tool and I
started using it, and I started experimenting with it, and
I reported like six issues or something like that back
to Mateo and the guys and the gang, and like
within one day it fixed all of them. It was
it was really amusing.

Speaker 5 (01:00:55):
Yeah, very fast. It's so there is that. Okay, tool
was great. Last week. I think we shaped something new.
We shipped a way to get the representation of the
flamegraph as marked down, so you can essentially feed it
to an l LM and it will just fix things.

Speaker 2 (01:01:18):
So it will basically understand where your bottlenecks are in
terms of performance and focus on them automatic exactly. Like
this function is slow, but it's not just slow. It's impacting.
It's being called a lot, so it has a significant impact.
Or that function is hardly used, there's no point in

(01:01:40):
optimizing exactly.

Speaker 1 (01:01:43):
Yeah, but like you said, Matteo, it seems also that
some of the fixes are pretty commonly understood and easy
for the LLM to implement, and so I can also
you know, it's like add add a database index or hey,
if you can't if you do it this way instead
of that way. This structure is more performant than that one.
And you know it's it's it's little changes, but they're

(01:02:07):
low risk, low risk, and the LAM is great at it.

Speaker 5 (01:02:10):
Okay, I called the low hanging fruits. Okay, so the
low hanging fruits are super easy to do.

Speaker 4 (01:02:18):
For the alarms. Okay.

Speaker 5 (01:02:20):
Now from the frame graph you can even spot some
bad architectural patterns happening. And the bad architectural patterns are
harder so to figure out.

Speaker 4 (01:02:32):
So during my research I've done, I opened a few bugs. Okay.

Speaker 5 (01:02:37):
One is on a React router. I found that it
for every rendering its schedules a timer that's never cleared,
so it runs to completion. It's it's like five second,
but that cause it's becomes a hot spot for the
garbage collection.

Speaker 1 (01:02:57):
Right. I was going to say, it's a memory leak,
but it's nice. It does get it.

Speaker 5 (01:03:04):
Eventually, yes, but it's enough that it gets by. It'll
keep memory located for more and it's enough for that
memory to be moved to old space. So it's actually
creating a some problems for the wrong time that's actually
not needed. That could avoid could be avoided. Okay, I
sent a patch. Another one that I found recently is

(01:03:26):
a bug on with this tool is on GT.

Speaker 4 (01:03:30):
I don't know if you know GT.

Speaker 5 (01:03:32):
By the way, I found this a very horrible bug
and I am really bad.

Speaker 4 (01:03:36):
Let me pass it to you because.

Speaker 5 (01:03:40):
And GT is a module a lot than sixty million
times per week something like that.

Speaker 2 (01:03:46):
GT.

Speaker 4 (01:03:47):
Yeah, GT, this is a bug. I passed the bag
in the chat J I T I yeah.

Speaker 5 (01:03:54):
It makes any any function that export in a function
between sixteen seventy times lower.

Speaker 2 (01:04:01):
What is chitty.

Speaker 5 (01:04:03):
It's a module to load the typescript straight from node,
similar to tes what tes no does, but that differently
typed syme of things is used by yes, lint, nxt, netro,
post CSS.

Speaker 4 (01:04:22):
I don't know.

Speaker 5 (01:04:23):
Tailwind is very popular in front and I have I
had no idea this even existed until it showed up
in my flamegraphs.

Speaker 2 (01:04:30):
Man, don't you love it when people use proxies?

Speaker 4 (01:04:34):
Yes? You see see I have you know it's it's
it's one of the most misused technologies that you can
get in that Like, if you're using a proxy, you
should ask am I doing it wrong?

Speaker 2 (01:04:47):
And the answer would probably be yes, yes, not always,
not one hundred percent of the time, but you should
definitely be able to justify yourself.

Speaker 1 (01:04:56):
Yeah. So I'm going to kind of push us to
wrap up this particular topic because we only have like
eight minutes left.

Speaker 2 (01:05:03):
So I just have to say that before we conclude
on this, that the ability to gather performance information throughout
the lifetime of a process in production is invaluable. You know,
we've had similar technologies in other programming languages, like the

(01:05:25):
what's it called in Java? Java has the Java black
box sort of thing, I forget the name. That they
have the ability to collect performance information without usually without
significantly impacting runtime performance, that you can do it in production.

(01:05:46):
The ability to do the same thing or similar thing
in for node is really invaluable. And I'm really grateful
for Mattel and everybody Platformatic for releasing this game.

Speaker 5 (01:05:59):
Is there free tried out if you want, if you need,
you know, talk a little bit about my company enough.
But if you using this tag and you it's core
part of what you do, you can reach out.

Speaker 4 (01:06:14):
We'll be very happy to help you.

Speaker 1 (01:06:18):
Cool. All right, Well, I'm going to push us two picks. Uh,
this is where we do shout outs about stuff we
like and uh yeah, I know that you're kind of
under a time crunch Matereo, do you want to go first?
Or do you want one of us to go first?

Speaker 2 (01:06:34):
Oh?

Speaker 4 (01:06:35):
Let me let you go first and then I go last.

Speaker 1 (01:06:38):
Okay, Dan, what are your picks?

Speaker 2 (01:06:41):
Okay? So I've got two picks. The first pick is.
We've been playing this amusing game in our family these
past couple of weeks. It's called Hitster. It's this kind
of a game where you've got a certain like deck
of cards and each card has this QR code that

(01:07:06):
you scan, and it goes with your phone and it
goes to the and it actually starts playing that song.
I think it uses Spotify, but I'm not. I don't
remember off the top of my head. And the idea
is that you play every you divide into teams. You
play the song for about twenty seconds, and then the

(01:07:28):
team that turn it currently is needs to guess the artist,
the title of the song, the artist, and the year
in which it came out. If you need to guess
at least two to get a point, If you guess
all three, you get two points. Something along these lines.
And we've been playing this in our family, and it's

(01:07:50):
songs from all eras. In the case of Israel, it's
both Israeli music and you know international or American music
or British music, and it's really a lot of fun.
We enjoy it very very much. You know, you listen
to music, what's you know and and try to guess
the songs. It's it's a lot of fun. So that

(01:08:13):
would be my first pick, and the second pick is
again is actually Matteo. I want to mention that on
X Matteo, you put out videos on a fairly regular basis.
It's they're relatively short usually I think they're like twenty
minutes each, usually about a variety of topics related to

(01:08:36):
know the Jass development obviously, and they're uniformly excellent, and
I highly recommend following Matteo and watching the videos that
come out. So that would be my second pick, And
those are my picks for today.

Speaker 1 (01:08:52):
Awesome, Steve, what are your picks.

Speaker 3 (01:08:55):
Before I get to the high point of every episode,
which are the dad jokes of the week. An interesting
video that popped up on YouTube last night by Jeffrey Ray.
Jeffrey Ray, who is the owner creator of Larra Cass, which,
if not Larabelle Community is a pretty well known training

(01:09:16):
platform for Larabell and on many many other topics as well.
And he titled it I'm Done, and it's just sort
of a a it's about thirteen fourteen minutes where he's
just talking about the impact that AI has had on
Larrakass and they just had to layoff a bunch of people,
similar to what happened with Tailwind and the you know,

(01:09:39):
sort of the use of AI and coding and you know,
the pros and cons and sort of almost having to
use it or get left behind. He's a I gotta
agree with him in a lot of what he says.
It's only about fourteen minutes, so it's it's a good watch,
but it's I think it addresses the reality of AI

(01:10:03):
encoding and how it's impact impacting things both I think,
I think both for good and bad.

Speaker 2 (01:10:08):
I think we should probably bring a bunch of open
source creators, people like Matteo, like maybe uh, we've had
a of the Joel we we've had on the show
talking about the slint and t slint uh and and

(01:10:29):
basically talk about the impact that AI is having on
on open source developers. It's really cutting the branch that
a lot of them are sitting on financially.

Speaker 3 (01:10:41):
On that upper Ever note, I'll get to the dad
jokes of the week. So, first of all, pretty straightforward
question here, what do you call a pony with a
sore throat? A little horse?

Speaker 2 (01:10:59):
Right?

Speaker 3 (01:11:02):
So good, thank you, Mateo.

Speaker 2 (01:11:03):
I love that.

Speaker 3 (01:11:07):
So everybody knows who Alan Turing is, right, the term
touring complete Uh, you know in computer science Enigma and yeah,
he cracked the Enigma codes in World War Two, but
nobody knows his sister Kay, who provided drink, snacks and
sandwiches for him and his colleagues. I was in catering, Yeah,
right right.

Speaker 1 (01:11:27):
It took me a minute. Yeah.

Speaker 3 (01:11:29):
And then finally, uh, why does Spider Man hate driving
with his evil twin because he's a bad parallel parker? Oh?
Thank you. Those are the dad jokes of the week.

Speaker 1 (01:11:45):
I usually don't laugh at the dad jokes, but Mateo's
reaction was priceless.

Speaker 3 (01:11:50):
That's half the fun sometimes.

Speaker 1 (01:11:52):
Oh all right, I'm gonna jump in with some picks.
The first one I always do a board game pick,
and this one we got for Christmas. Man, has it
been that long since I've been able to get on
and record. Yes, thanks Steve. He made me feel better. Anyway.
The game that one of the games we got was

(01:12:13):
Everdell came out twenty eighteen. My wife and I played it,
so it was just two players with us. It probably
took us an hour, maybe a little longer to play.
We were learning it as we went though. I think
I played it with my sister and my wife another
time and it took us about the same amount of
time because at that point we knew what we were doing.

(01:12:34):
And anyway, what it is, it's actually the board's kind
of cool because it's got this tree that you kind
of slide together. It's made out of cardboard, but it
looks really cool when it's set up and it's sitting
on the board. Reminds me a little bit of the
Tower in Fate of the Fellowship, which is a pandemic

(01:13:00):
like game based on Lord of the Rings. But anyway,
so Everdell plays up to four players and you're trying
to collect resources in order to fill missions, and you're
building a little town of animals in you know, basically
in front of you, and that gives you special ability.

(01:13:20):
So it's a pretty standard kind of game. It's just
you know, a couple of little nuances and stuff. Anyway,
it was fun. Definitely enjoyed it. It's not.

Speaker 4 (01:13:33):
It's not so.

Speaker 1 (01:13:34):
Novel or different or whatever that I would just go
and reach for it on my own on a regular basis.
But I did enjoy it. It's definitely a game worth,
you know, having him playing, and the artwork on it
is incredible. So I'm going to pick Everdell board game
has a board game weight of two point eighty three,

(01:13:58):
and that means that it's it's it's a fairly involved game,
but if you've played a lot of the other resource
gathering deck building kind of games, it's nothing outside of
the realm of what you're what you've probably already played.
So I'll pick that, and then what else. I started

(01:14:25):
watching land Man and I've been enjoying that. That's on
Paramount Plus, and so I'm going to pick that. And
then I watched My wife and I started watching the show,
and she's a little bit sensitive to people dropping f
bombs during shows, and so if there's too much of that,
she won't watch it. And so we watched like the
first episode way back when of eleven twenty two sixty three,

(01:14:47):
which is, uh, there's this history teacher. His friend's been
going back in time to try and save JFK from
being assassinated. And so anyway, he takes all of his
friends research and you know, all the preparation that he's done,
and he goes back to save JFK and right then
come back to the future where it's supposed to be

(01:15:08):
better because you know, Linda Johnson wouldn't have gotten us
into the Vietnam War and a whole bunch of other
things that other people did that you know, this particular
guy didn't like wouldn't have happened. And anyway, so I'm
not going to spoil how it changes the future, even
though the show's like ten years old, just in case
you want to go watch it, because honestly, it's it's

(01:15:29):
actually pretty like the whole journey's pretty pretty interesting to
watch him go through and you know, encounter people from
the past and stuff like that. So I'm going to pick.

Speaker 2 (01:15:42):
So you've got to pick Prime Month plus. How are
you enjoying Star Trek Starfleet Academy.

Speaker 1 (01:15:47):
I have not watched it at all. I've seen ads
for it, but I haven't watched it. Is it good.

Speaker 2 (01:15:53):
I've not watched it. I'm going based on the reactions
and the critics. You know, the story that they released
the first episode for free on YouTube and a nerdratic
in competition with him basically just put a video of
doll of Spock sitting on a chair and he got

(01:16:15):
more views.

Speaker 1 (01:16:16):
Oh funny. I have to say that.

Speaker 2 (01:16:20):
I understand that they did. It's Star Treks Acolyte.

Speaker 1 (01:16:24):
Okay, Yeah, I've I've liked a lot of stuff on
Paramount Plus, but yeah, that's not That's not one that
I've been watching. We liked Star Trek Discovery and Star
Trek Piccard, but anyway, I haven't watched that one yet.

(01:16:45):
So yeah, so Landman and eleven sixty three, which I
think was originally on Prime and is now on Netflix. Anyway, Tayo,
what are your picks?

Speaker 4 (01:16:56):
So the first one is.

Speaker 5 (01:16:59):
I've been taking a lot with Ai thinks, Okay, as
everybody and I have having a lot of fun these
last few days on a project called PI. It's a
little open source codeing agent that is highly customizable. The
heart of malt Bot now cloud bot whatever is what

(01:17:22):
that thing uses internally to do work. Okay, and it's
super fun to use and very fun to modify and
change things and so on and so forth.

Speaker 4 (01:17:32):
Is really fun. So I've been tinkling with that.

Speaker 5 (01:17:37):
Also, I can use it with Ulama and even have
a local model running very easily, and I add some success,
some success, so I can run the full AI think
on my machine. Not that I want to, but it's possible.
So I can literally use those things on a plane
if I want to, which is something that I really
wanted to achieve.

Speaker 4 (01:17:57):
So I have done had fun with that. Okay, yeah,
it's very easy. The other thing it's we're talking with
the eye is tile scale. If you're not using tilescale,
tailscale is you're missing out. Okay. You can interconnect all
your devices, servers and so and so force in a
single network. It's phenomenal. Okay, I'm a fan. So try

(01:18:23):
that and combination with those two together, I can more
or ize call things on the phone if I want to,
and whenever I go, I can just have you know,
checking on my agents doing things. And yeah, I'm becoming
one of those people apparently.

Speaker 2 (01:18:38):
So the problem that I have right now, I know
that a lot of people are running multiple agents at
the same time. I'm having problems with that multitasking between
different tasks myself, so it's difficult for me to schedule
enough agents to do things all the time in the background.

(01:18:59):
I maybe it's a fault of my own as a
manager or something, but the end result is that I
often end up waiting for AI to finish something.

Speaker 5 (01:19:12):
Yeah, which is you know, doesn't spit things up essentially, Well, yes.

Speaker 2 (01:19:17):
And no, but but yeah, it's kind of like going
back to the early two thousands when we had slow compilers.

Speaker 4 (01:19:27):
Yep, a little bit.

Speaker 1 (01:19:30):
All right, well, Matteo. If people want to continue to
follow along with the things you're working on, where do
they find it.

Speaker 5 (01:19:35):
They find me on Twitter at mate Hoolina, or they
can subscribe to my newsletter and.

Speaker 4 (01:19:44):
At nodland dot dev and yeah, that's kind of.

Speaker 5 (01:19:48):
It cool, and of course follow at Clubformatic and contact
us if you need any help.

Speaker 4 (01:19:54):
Very happy to chat.

Speaker 1 (01:19:56):
Sounds good, all right.

Speaker 2 (01:19:57):
Support the people who are making no literally work.

Speaker 1 (01:20:03):
Yeah all right, yeah, we'll go ahead and wrap up
until next time. That's out. Mm hmm.

All Episodes

Node.js Performance, Kubernetes, and Why “Fast” Isn’t Always Fast - JSJ 702

Episode Transcript

Popular Podcasts

Hey Jonas!

Dateline NBC

Betrayal Weekly

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Node.js Performance, Kubernetes, and Why “Fast” Isn’t Always Fast - JSJ 702