Looking for solutions to make Meteor cheaper

[tcastelli]

Thanks for sharing the idea, I agree that the start of new processes/workers would be something that meteor should support in the core, since adding things on top of the meteor build makes it a little messy for deployment. Also it would be great to be able to define multiple entry points so there can be different “files in the project” that can be started separately without having to create multiple bundles and “orchestrating” everything manually. I know there was a feature request about this at some point, not sure if with Meteor 3 this would be easier to implement.

(Also, I know there was a workaround to create entrypoints by storing files in the private folder, but then imports to npm could fail and generally it was not a perfect solution.)

[italojs]

agree with you, could you(or someone here) open an issue about it? then we could, dicuss the DX, prioritize and work on it

[minhna]

I created a discussion here: Enables Meteor JS application to run multiple instances of itself to maximize hardware utilization · meteor/meteor · Discussion #13823 · GitHub

[lucfranken]

Would there be a way to easily detect whether meteor uses the full available amount of processors and resources? I think many have no idea, if there would be some kind of package / simple script to measure and monitor it would give a lot of insight for many people.

Many things read in this topic are highly interesting and also highly technical on the server side which is not common knowledge for many developers.

We might be surprised about the amount of unused resources I guess.

[paulishca]

@lucfranken

Would there be a way to easily detect whether meteor uses the full available amount of processors and resources

If you don’t use the cluster technology you are 100% sure to only use 1 CPU. If you want to use clustering, you have this:

const os = require('os');
const cpuCount = os.cpus().length;
console.log(cpuCount);

// also Node.js v18+
const os = require('os');
const availableProcessors = os.availableParallelism();
console.log(availableProcessors);

[evolross]

@paulishca

Meteor cannot produce an arm64 build for Graviton (or equivalent) servers in the clouds.

But Support ARM on Linux is merged. Is it not working?

[evolross]

Sorry to bump this, can anyone comment if ARM support is actually working?

[paulishca]

To be frank, I never managed to deploy to a Graviton in AWS.
I see this "os.linux.aarch64": true here: https://github.com/meteor/meteor/blob/e1cfdded027dbf1d43f646d76cf04ef8235cfa48/tools/utils/archinfo.ts#L130

My understanding is that you could build your production bundle in a Docker with a similar environment/image as the server you deploy to.
For instance, on a Mac, you pull something like this in Docker ECR Public Gallery and run your build and deploy on the local Docker instead of your “local machine”.
Or if you use containers for your Meteor in production you could take from here: Looking for solutions to make Meteor cheaper - #17 by jacoatvatfree

Unfortunately, the documentation makes no reference to aarch64.

[dpatte]

I actually have several meteor apps, all with low traffic, running on a single linux box. Am I correct to assume that each meteor app is running on its own core, and if not, is there a way to ensure each has its own core?

[paulishca]

Meteor = Node so this from google searches applies:

Yes, if you deploy multiple, independent Node.js applications on a multi-core Linux server, the operating system’s scheduler will generally distribute these processes across the available CPU cores. However, they do not necessarily get exclusive ownership of a core; the OS will balance them based on load.

Here is a detailed breakdown of how this works and how to optimize it:

1. Default Behavior

By default, Node.js is single-threaded and uses only one CPU core, regardless of how many cores are available.

• Without Special Configuration: If you run two different Node apps (App A and App B), Linux will likely place them on different cores, but if one app is very busy, it might consume 100% of one core while others sit idle.
• With Multiple Apps: If you have 4 cores and 4 independent Node apps, Linux will typically distribute them to run in parallel.

2. How to Utilize All Cores (Clustering)

If you have one high-traffic application and want to use all cores, you should use the Node.js Cluster Module or a process manager like PM2.

• Master-Worker Model: The cluster module creates a “master” process that forks “worker” processes (usually one per core).
• Shared Port: All workers share the same network port.
• Parallelism: Each worker acts as an independent instance of your app running on its own CPU core.

3. Key Considerations

• OS Scheduling: Linux is designed to maximize CPU utilization by distributing threads across all cores. It does not mean each application is locked to a specific processor, but it does mean they can run in parallel.
• Process Isolation: Each Node app runs in its own process, meaning they have separate memory spaces.
• I/O vs. CPU Tasks: Because Node is non-blocking, it handles I/O (database, network requests) very efficiently. Clustering is most critical for heavy CPU-bound tasks (e.g., encryption, image processing).

4. Recommendation for Production

To maximize performance on a multi-core Linux server:

1. Use PM2: PM2 can easily cluster your applications using pm2 start app.js -i max.
2. Use a Reverse Proxy: Use Nginx to distribute traffic to your app instances.
3. Containerization: If using Docker/Kubernetes, each container will typically be scheduled on a specific core by the underlying node’s Linux scheduler.

[dpatte]

Thanks so much. Great info. I use Apache, and I distribute to separate ports for each app. I have more threads than apps, but less cores than apps.