Looking for solutions to make Meteor cheaper

[paulishca]

I host my own Kadira APM, there nothing to save.

@eidinov

is it possible to have two layers of load balancing

In my initial post, Reason 2, I explain that most x64 machines in the clouds have at least 2 cores. In the AWS Elastic Beanstalk (the autoscaling environment) a new machine may be added, and I would end up paying 4 processors and 2 x 2 GB RAM when in fact I’d be using 2 processors and 2 x 1GB RAM.
Autoscaling and balancing are one thing. Node multithreading is another thing. I want to use most of the resources of available Linux machines in the cloud, not only half or 1/4 or 1/8 (depending on how many cores a machine has).
Building for os.linux.arm64 yielded no success so far. I am trying various options now.

[eidinov]

How do you deploy and serve your builds?

I’m curious what would happen if each of your machines had pm2 running with multiple instances of Meteor. pm2 will work (PM2 - PM2 in ElasticBeanstalk), but I’m not sure about cluster mode.

[evolross]

@paulishca

Presently, if you run Meteor on a 2vCPU server at 1GB of RAM, you only use 1vCPU and half the RAM, because RAM is divided by processors.

We run our Meteor app on AWS ECS with the following Linux/X86_64 tasks, depending on the micro-service:

• 2 vCPU | 8GB
• 4 vCPU | 8GB
• 4 vCPU | 16GB

You’re saying on the 2 vCPU we only get 1 vCPU and 4GB of RAM. And on the 4 vCPUs were getting 1 vCPU and 2GB/4GB of RAM? I didn’t realize this. Calling my DevOps guy!

Also, I thought there was an ARM build that was in the works… did that never get released?

[paulishca]

@evolross Answer via Perplexity AI

How Node Runs on AWS ECS with 4 vCPU

Node.js Application Behavior on ECS

• Node.js is single-threaded by default, meaning that a single Node process will only utilize one CPU core, regardless of how many vCPUs are available on the ECS instance[5].
• On a server with 4 vCPUs (which equates to 4096 CPU units in ECS terminology), a single Node.js process will not automatically use all available CPU resources[4][5].
• To utilize all 4 vCPUs, you should run your Node.js application in cluster mode, using either the built-in cluster module or a process manager like PM2. This approach forks multiple worker processes (ideally one per vCPU), allowing your application to handle more concurrent requests and make full use of the server’s CPU capacity[4][8].

ECS Task and Container Setup

• In your ECS task definition, you can specify the CPU and memory resources for your container. For a 4 vCPU server, you would set the CPU parameter to 4096 units (1024 units per vCPU)[2][4].
• If you run a single Node.js process in a container with 4 vCPUs, most of the CPU capacity will remain unused due to Node’s single-threaded nature[5].
• The optimal setup is to configure your container to spawn four Node.js worker processes (using cluster mode or PM2) so that each process can be scheduled on a separate vCPU[4][8].

Performance Considerations

• Over-allocating CPU (e.g., assigning 4 vCPUs to a single Node.js process) does not improve performance and can actually introduce overhead and resource waste[5].
• A common best practice is to match the number of Node.js worker processes to the number of vCPUs allocated to the ECS task/container[4][8].
• For high-performance scenarios, running multiple containers (tasks) and leveraging ECS/Fargate’s scaling capabilities is recommended[8].

Example Setup

• ECS EC2 instance or Fargate task with 4 vCPUs (4096 CPU units).
• Container launches Node.js in cluster mode with 4 worker processes.
• Each worker process handles requests independently, maximizing CPU utilization.

Summary Table

ECS Resource	Node.js Setup	Utilization
4 vCPU (4096 units)	1 Node process	Low (1 core used)
4 vCPU (4096 units)	4 Node cluster/PM2 workers	High (all cores used)

Key Takeaway:
To fully utilize a 4 vCPU server on AWS ECS, run your Node.js app in cluster mode or with a process manager like PM2 to spawn one worker per vCPU. This ensures optimal CPU usage and better application performance[4][5][8].

Sources
[1] ECS Instance Size for Node.js Applications Instance Size for Node.js Applications - Flightcontrol
[2] Amazon ECS task definition parameters for the Fargate … Amazon ECS task definition parameters for the Fargate launch type - Amazon Elastic Container Service
[3] Exploring Deployment of Node.js Application to AWS ECS … Exploring Deployment of Node.js Application to AWS ECS Fargate with GitHub Actions
[4] What is the optimal way to run a Node API in Docker … https://stackoverflow.com/questions/27585168/what-is-the-optimal-way-to-run-a-node-api-in-docker-on-amazon-ecs
[5] From Lambda to Fargate: How We Optimized Node.js … From Lambda to Fargate: How We Optimized Node.js Performance with the Right Task Specs - DEV Community
[6] How does a Node.js process behave in AWS Fargate? https://stackoverflow.com/questions/63107690/how-does-a-node-js-process-behave-in-aws-fargate
[7] Tutorial: Deploy an application to Amazon ECS Tutorial: Deploy an application to Amazon ECS - Amazon CodeCatalyst
[8] Scaling Node.js microservices on AWS to handle 5M … https://sirinsoftware.com/blog/scaling-node-js-microservices-on-aws-to-handle-5m-requests-per-minute
[9] Comparison between ARM64 and X86_X64 on ECS … https://www.reddit.com/r/aws/comments/131n3aq/comparison_between_arm64_and_x86_x64_on_ecs/

[james]

Here you go This is how I deploy my meteor apps to a VPS. One click deploy, handles the server, and handled multiple apps on one server.

https://jamesloper.com/meteor-deployments-without-mup

[paulishca]

@james

multiple apps on one server.

This solution seems very cost-effective but not a production grade solution. It is … the opposite of high availability (low availability ?!), and all projects share the network interface and SDD. I think this could work (except guaranteed uptime) for projects such as multi-tenant SaaS where each client runs a core and the number of users is predictable. But here you are facing another cost issue. A (4-core + 8GB) server is usually at the same price of more expensive than 4 x (1 core + 2GB). And horizontal scalability/elasticity is probably not possible.

[james]

You can put it behind a load balancer like any other node.js app, you just need to enable “sticky session” support. I believe digitalocean has this exact service available without needing to built it yourself too.

Edit: Almost forgot you can run 2 instances on the same server if it’s dual core! (Different ports)

[vlasky]

Response to 1: There is a good chance you can run a Meteor app production bundle on that arm64 CPU running Linux as long as certain conditions are met:

• You must have the correct arm64 Linux-compiled Node.js version installed
• Any NPM packages your app uses must be free of native pre-compiled binary code, otherwise they will need to be rebuilt.

Response to 2: You have been misled. The Node.js cluster module is alive and well.

I have previously posted about using cluster in Meteor apps:

Meteor cluster/load balancing today

@antoninadert, you should not make your success dependent on the whims of a departed ‘guru’. It promotes learned helplessness and stifles your own initiative and creativity which is unhealthy :-). In your situation, I would use Nginx load balancing with Meteor. Basically, you get Nginx to distribute requests across multiple Meteor (Node) processes. And how do you create the multiple Meteor processes? There are a few ways. The approach I find most efficient involves using Node’s inbuilt clust…

[paulishca]

@vlasky

@vlasky

• You must have the correct arm64 Linux-compiled Node.js version installed
• Any NPM packages your app uses must be free of native pre-compiled binary code, otherwise they will need to be rebuilt.

Very good insights, thank you. I used the --architecture: 'os.linux.aarch64' but this probably does nothing or not much. I will need to dig deeper into the build tool and see if it does anything.
I compiled NPMs with Docker with the exact env I am deploying to, added them back to the project and pushed with MUP. I just don’t seem to nail down the right way with all the proper configurations. My next step is to build the whole project in Docker.
To generate a bundle and send it to a bare machine, everything seems straight forward for me. But when I have to push to the elastic environment of AWS, I miss visibility over so many things. For instance, if the machine doesn’t start, I cannot pull logs.

On Response 2, the same situation. I learned a lot from your shares, but again … when I have to do it in my environment, nothing works.

First, I had to discover myself that I cannot put the cluster script in Meteor startup. Right now I am not yet convinced that it actually works with Meteor. I first need to cluster.fork() and then start everything else so that nothing runs on the Master (now cluster.isPrimary). Most examples I’ve seen show this setup:

if (cluster.isPrimary) {
  console.log(`Master ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  // Worker processes have a http server.
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end(`Hello from worker ${process.pid}\n`);
  }).listen(3000);

  console.log(`Worker ${process.pid} started`);
}

My understanding from the example above: I first fork and once the cluster is forked I can start the webserver per fork. But the webserver in Meteor starts before the startup files, or the entry point main.js (server).
Add to my lack of understanding (or perhaps trust) in your example (in startup) vs these examples on the web, I was not able to find the right configuration to send the NGINX configurations to Elastic Beanstalk.
Part of the problem is that servers are ephemeral and all configurations need to be sent and done in the deployment process as well as when autoscaling and starting new machines.

The thread and code commits you shared are from 7 years ago, and the cluster part seems theoretical. I am curious if you actually deployed Meteor to any kind of servers in cluster mode.
As for the UNIX socks, that seems to be the recommended way to connect behind NGINX (which I never knew). My focus is now on finding the right configuration for Elastic Beanstalk. When you deploy with MUP to a Linux machine, you can add the full proxy configuration. For Elastic Beanstalk … it is complicated :(.
I am learning a lot from your git thread on UNIX ports.

[vlasky]

Your struggle justifies my love of dedicated Linux servers where you can control and monitor everything and no management layer interferes with you.

This is actual code taken from a Meteor app that uses node cluster . You will see the important detail that the PORT environment variable has to be passed to the fork() call. That’s how each worker Meteor instance knows to listen on a different port to the master/primary Meteor process.

Meteor.startup(() => {
    if (cluster.isMaster) {
        const startWorker = (name, port) => {
            const w = cluster.fork({PORT: port});
            w.process.name = name;
            w.process.port = port;
        }

        cluster.on('exit', (worker, code, signal) => {
            const {name, port, pid} = worker.process;
            console.log(`Worker ${name} - ${pid} died`);
            console.log(`Starting over...`);
            startWorker(name, port);
        });

        if(isProduction)
        {
            const portStart = 3002;
            const totalWorkers = 10;
            _.each(_.range(0, totalWorkers + 1), i => {
                startWorker((i+1).toString(), portStart+i);
            })
        }       
    } else {
        console.log(`============================================`);
        console.log(`Worker ${worker.process.env.name} - ${process.pid} started`)
        console.log(`============================================`);
    }
});

[tcastelli]

Thanks for sharing an example and all the info about your take on multiple workers for Meteor, out of curiosity, what kind of strategy do you think is the best for zero downtime deployments when you use dedicated linux servers?

[jacoatvatfree]

We run our meteor apps on caprover (docker swarm) on top of Oracle Cloud arm64 servers quite successfully. The always-free tier allows for quite a lot of compute and enough memory on Ampere (arm64).

The essence of it is to build the node version elsewhere, like github actions, (meteor build --server-only --server https://yourdomain.com) and then use a Dockerfile like this:

# https://github.com/productiveme/meteor-docker
FROM productiveme/meteor
USER app
WORKDIR /built_app
COPY --chown=app:app . .
# Uncomment additional npm steps below if needed
RUN cd /built_app/programs/server \
	&& npm install \
	# && npm rebuild --build-from-source \
	&& true
# RUN cd /built_app/programs/server/npm \
#   && npm install \
#   # && npm rebuild --build-from-source \
#   && true

HEALTHCHECK CMD curl --fail http://localhost:3000/healthz || exit 1

• The healthz endpoint helps docker swarm to deploy with zero downtime.
• You will need a NODE_VERSION env variable for the productiveme/meteor image to start correctly

I plan to write a more complete blog post on this

[paulishca]

After 2 days of struggles I finally made it to find a solution for Reason 2 for my 2-core server. I will need to test the solution with multiple cores and see if results are consistent or not.

My environment is AWS Elastic Beanstalk, and I deploy with MUP with the beanstalk plugin for MUP. The challenge was to send the configurations to the elastic environment. At least 1.5 days I spent to try to make Meteor work with UNIX sockets. It just won’t do it.
I managed to do every configuration I wanted, but Meteor would just not listen on that port no matter what I did. I don’t know if this has something to do with Express which was recently added. I am curious if anyone can confirm they are running UNIX sockets between Node and NGINX on Meteor 3.
Another challenge was with AI chats. Different models provide different answers, and in general, it took me a while to differentiate between pre Linux 2 configurations and post as EC2 (linux machines) handle configuration updates differently.

The result:

At the time stamp on Memory Usage is when I am hammering the server with multiple methods per second and multiple users.

The exact same test after implementing the cluster, shows half of everything, because APM only sees one process. The real load is 2x, like in the previous test screenshot.

I now know that I use what I am paying for.

@vlasky I didn’t manage to use UNIX sockets. I am pretty sure I do everything right in Meteor (not much to do here anyway) and in NGINX but my Linux skills are almost 0.You mentioned it above in the thread and back in 2020 too … go simple, one dedicated server. Unless you want to have a look together at your convenient time, I will have to abandon this venue. I managed to make the cluster work with http ports, and the NGINX is using a round robin algorithm to send to the ports.

[italojs]

Looks like Meteor support cluster but does note implement it self as you can see here

if (cluster.isWorker) {
        const workerName = cluster.worker.process.env.name || cluster.worker.id;
        unixSocketPath += '.' + workerName + '.sock';
      }

did you try to use node cluster for your main.js server app?
like this

const cluster = require('cluster');
const os = require('os');

// Número de workers (instâncias)
const numWorkers = process.env.NUM_WORKERS || os.cpus().length;

if (cluster.isMaster) {
  // Fork workers
  for (let i = 0; i < numWorkers; i++) {
    const worker = cluster.fork();
  }

  // Listen for worker exit and restart
  cluster.on('exit', (worker, code, signal) => {
    cluster.fork();
  });

  // Graceful shutdown
  process.on('SIGINT', () => {
    for (const id in cluster.workers) {
      cluster.workers[id].kill();
    }
    
    setTimeout(() => {
      process.exit(0);
    }, 5000);
  });

} else {
  // Worker process - start the Meteor app
  // Set unique port for each worker if needed
  const basePort = parseInt(process.env.PORT || 3000);
  const workerPort = basePort + cluster.worker.id - 1;
  
  process.env.PORT = workerPort;
  
  // Start the Meteor application
  require('./main.js');
} 

[minhna]

I think these kinds of code should be a part of meteor core, and we can configure max number of workers Meteor App may use in Meteor settings.

[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);