#Reduce Nodejs start up memory cost

51 messages · Page 1 of 1 (latest)

ripe patrol
#

Reduce Nodejs start up memory cost

vernal junco
#

no, require will cache the entire import anyways

ripe patrol
#

mhmm .. ok

vernal junco
#

and createServer will have to use a bunch of other stuff in http, too

ripe patrol
#

Would you be able to tell me how I would be able to reduce my memory start up cost?

#

Like what would I be able to use to debug this issue

#

I feel like the method I'm using which is comment stuff out and see if it uses less memory isnt effective enough LOL

vernal junco
#

i mean, it's really specific to what you're doing, i don't think i can give general tips

#

have you tried profiling?

ripe patrol
#

I did get that setup last night

vernal junco
#

not sure if that's viable tbh...

ripe patrol
#

but i couldn't read it really LOL

#

but will profilling the memory show like actual what's taking up MB ?

#

I had it connected with chrome

#

Are there programming techqunies to use to maybe achive better memory footprint?

#

Currentl I'm running express Js webserver

vernal junco
scenic sinew
brave prism
#

I think if you're that concerned with memory costs for squeezing maximal useage out of resources you're better off using something like Rust where you can carefully controll memory constraints for most CRUD applications without a stretch.

#

From an operational standpoint, this is mostly silly and best served by instead using a process management plane like Kubernetes that can monitor and assign worker nodes to utilize underlying hardware better... or provisioning more smaller machines, which are cheaper (or dockerizing them and then paying per MB consumed by running processes or the underlying worker nodes)

In addition you do not wish to actually use a machine perfectly, and instead leaving some headroom for overflow and buffer processes, so getting "good enough to run n of a process", since you're probably only going to be able to actually run n-0.5 to n-1 processes.

In terms of like battery performance, again node is a poor choice here and I would reccomend using some other language that is compiled to do so.

#

Your OS, monitoring, and maintenence tools need headroom to operate in without impacting the underlying services.

ripe patrol
#

So are you saying that people just build node applications without worrying or trying to fine tune the application to use less memory ?

#

Like there are no programming paradigms to make sure you’re writing some efficiently ?

#

But thank you. I just want to see if there’s anything can do to get it from 80MB to maybe 40MB on startup and maybe it max out at 70

Currrntly it starts at 80 and maxes like 127MB

#

And when I say cost I don’t mean money. I mean just using less.

brave prism
#

People just build applications first!

Generally you start to worry about optimization only if it ever becomes a bottle neck or a problem.

Focusing on clean and well maintainable code allows you to make these changes where applicable, if applicable, but not before.

Generally you'll go through some iterations of throwing hardware at the problem (getting 64gb in a machine is pretty trivial nowadays), or more machines (8x4gb applications is probably cheaper than the 64gb memory one) before you go "ah shit" and have to figure out whatever is constraining your service.

ripe patrol
#

Again trying to do some specific reducing memory usage. I know I could put more memory at it. I know I could throw more money at it. That wasn’t the question I was asking.

brave prism
#

Yes, and I am saying it's not an important question to be asking.

At 127mb you're running like, 10 of those on a cheap, and for server processes it's really only the maximum you want to worry about, since your servers are likely to be long lived enough that they reach the maximum eventually and it is your constraint usage that is the concern.

If you're running on lambdas and it's a short-lived process and you're wanting to reduce costs/improve responses, it's a more reasonable thing to worry about.

#

By the time memory footprint is a concern, I would be guessing you're running into io constraints instead

ripe patrol
brave prism
#

Sorry, I will stop then and hope you find your solution

#

I manage and operate applications on the day to day, so I am approaching this from a practical perspective, if you're doing it for fun, go ahead! But your initial comment was about running as many as possible, which is a different goal implication (More running on less means less cost mostly)

ripe patrol
#

Yes I want to run more.. and if I can take an application that is 100MB and I can get it to 50MB I can run more

#

I can also run more by throwing more RAM at it

#

but I dont want to throw more ram at it if I can make better code

#

Now if there is no way to do that because node does what it wants.. then I'll have to be stuck with that

#

or use a different lang.. but I want to see what I can do before I say we have to throw more money at it

brave prism
#

The hours you spend on trying to solve this will be more expensive than just throwing more ram at, or approaching the problem differently (orchestrating across machines) it is mostly what I am trying to get across.

If the goal is to service more users then that is mostly my advice.

ripe patrol
#

The goal is to make the best code possible.

brave prism
#

For who?

ripe patrol
#

The goal is to use nodejs as efficent as possible. To use my resource as best as possible.

brave prism
#

The end user kinda doesn't care, they just want it to go fast and be nice.

Your organisation doesn't particularly care if it meets their metrics to do whatever, and doesn't exceed costs.

An ideological reason is a reason, but it's primarily for you, and like... I get that! I work in games a lot so penny pinching on performance of code is the name of the game.

ripe patrol
#

Again if someone is paying me to do something .. then they do care

#

and if they care then I care..

#

anyway.. thanks

brave prism
#

Less than you think tbh, because they're paying you, and paying you to do feature is probably better use of money over paying you to improve quality of that code...

But yes whoops I've gone in a loop again, my apologies.

I have had to deal with the nuts and bolts of dollars recently, and I have that xkcd comic about automation in my head all the time because I will take 3 weeks to automate something that is really 1 minute every 3 months of actual drudgery...

ripe patrol
#

Your time would be best spent just answering the questions people ask or saying nothing. Because in the end I still need my question answered and we spent time going in circles

#

I also don't even want to be in this discord because of you

scenic sinew
#

He not wrong about node not being the best language if you care very highly about minimizing memory use, js runtimes just don't give you the kind of low level primitives to manage memory very precisely. In general tho, if you're trying to minimize memory, look for e.g. places where you're allocating arrays, objects, or functions within a loop or "hot" code path

#

No, there are not paradigms that will ensure maximum efficiency. It's true that e.g. functional programming tends to use more member than procedural code, by preferring immutable modifications that allocate more memory