Galaxy: High CPU on a very simple project

performance
1

Here’s my doubt.

To test Galaxy and Meteor’s performance, I’ve deployed a simple app that consists in two screens, one for the login and the other for signup.

I’m using React 18 with Typescript, TailwindCSS ReactRouter v6 and MongoDB Atlas.

For the authentication, I’m using “accounts-passwordless” package and a Tiny container (free).

Can you explain me why Memory spikes to 30% with only 1 connection, even if the app is pretty minimal?

And What if I’ll have 1000 concurrent connections? Maybe will explode :rofl:

I’m pretty scared and that’s why many people are moving off Meteor. CPU and Memory usage is a big pain in the ass.

Screenshot
Screenshot1170×2532 155 KB

2

Hi @lucalanzano81, please open a ticket to our support at suppot@meteor.com, and our team will investigate this issue

3

Nobody leaves Meteor because of that unless … they come in for running 1000 users on a free box.

I am trying to understand your question or the mentality behind it such as why you ask. So, you use a test box and with 1 user you postulate that many people leave Meteor because of what you see on your screen :))).

Let me please help you by giving you a task: reach 70% memory and see if you can. At this point in a elastic env you would probably start another machine.

ok, don’t mean to be rude but you made me laugh

4

What was your base memory with 0 connections? And how much memory are we talking about (sorry no time to check)

1 Like
5

My impression is that there are always the same people answering to the topics.

Anyway… There are many issues (and posts) around high memory usage in Meteor apps.

@paulishca I’ve started using Meteor since 2013 and this problem remains the same.

Please, be honest! In respect of the community.

6

I am being honest when I say that, since 2013 (which seems to be the year many of us started), all cloud providers started to offer elastic cloud because … on absolutely any backend the memory and CPU tend to go towards 100% instead of 0%.
You and other perceive it as a Meteor “issue” because you use Meteor. But this is a JAVA issue as well or .NET. When the architecture is bad this issue dooms the project. The solution is not changing tech but doing better architectures.

All Node servers work the same, the rest of it is your design.

There are always the same people because this is how open source works. We are all a mix of give and take. You want to see 100 new people showing up?! Post a small job and offer $10K for 2 days work…

7

That’s why Serverless/Microservices is the choice for many developers nowadays.

In any case, if you’re talking about issues in architecture stack, you’re saying that Galaxy is not so good, considering my example above.

Please, give me examples of applications made with Meteor that are managing thousands of connections simultaneously.

I’m pretty curious!

8

I meant issues in architecture of your project built with Meteor.

9

Sure! It’s my architecture, man :rofl::rofl:

Please, don’t make me laugh again.
We’re talking of two simply pages without any subscription and only a simple ValidatedMethod.

And you’re saying It’s my fault!

Please…

10

Hi, with all due respect I do not intend to get into a 1 to 1 debate.
You architecture means everything from power plug on the wall up to your websockets that server your clients.

A summary of your first post: you use a box with 256MB memory out of each you allocate/consume 30% ~ 80MB, just enough to run Node naked. based on this experience you postulate that this is why many people move off Meteor. Therefore I am saying … your architecture is the problem or your understanding of the expectations.

You say there was a spike to 30%. Spike by definition is one occurrence, or more so, what is your memory consumption doing without that use in? 70MB?!

It looks to me like you want to convince yourself that people leave Meteor or that there is something wrong with it but, sorry to disappoint you, it is not the case. You may like it or not, it is just NODE, Meteor, is how you do things and not what you do. Think you have 100$ and you allocate it: you wanna put 80$ into reactivity and less users or the other way around. Except that you don’t have 100 USD you only have … basically nothing, a free box.

I’ll show you some allocations from 0 users running Meteor projects. For the same box size the difference is given by the number of MongoDB Clusters the app is connected to:

T2.nano - 512MB (you can observe with 1 user, memory doesn’t move). Memory consumed - 25%

Screen Shot 2023-06-29 at 1.43.45 PM
Screen Shot 2023-06-29 at 1.43.45 PM774×719 82.4 KB

T2.micro - 1GB. I start to load test it with up to 200 users that run a method to get some data from the user document. 0 users memory consumed - 20% then it follows the folkloric 10 MB per user pattern. This is still a very cheap box, far from production grade.

Screen Shot 2023-06-29 at 2.21.52 PM
Screen Shot 2023-06-29 at 2.21.52 PM1556×740 105 KB

Memory use is predictable, efficient, effective and running a project with Meteor is easy to understand, maintain, monitor and first of all considerably cheaper than other stacks.

Please explain to me again why people are moving off Meteor.

This will be my last comment in this thread.

1 Like
11

This was why I asked what was the base resource with no connections. 30% was the total usage and not the delta from zero connections to 1

1 Like
12

Hey, there are many obvious things to be said here but I’ll try to keep the list short:

  • Tiny containers are not supposed to be used in real projects, it was brought to life as the Meteor community was always asking to get a free hosting alternative back;
  • Memory baseline is very different from a spike;
  • Memory usage is not bad, any framework or stack will not clean up memory if it’s not necessary, that is why we have max heap space in Java and Node.js apps. If the heap space is not full, don’t waste time cleaning it up (of course, there are many other things in GC but you get the point);
  • Assuming that Meteor users are leaving Meteor because of this is nonsense. Meteor has many success cases, including Event apps with huge spikes during Covid;
  • I have no idea what was the point of your post after all.

So there is no issue here, at all.

If you want to battle test your Meteor app you should use something like artillery and then get your final numbers. I already worked closely with more than 30 Meteor production apps and I saw apps that could handle max 20 users with 1GB of memory and I also saw apps handling +1000 users with the same 1GB.

Meteor is not magic, it does a lot of work for you but that uses resources, of course. Then it’s up to you to decide when to use what and in which context.

3 Likes
13

Thanks to everyone.

I apologize. It wasn’t my intention to debate around Meteor.

I’m truly interested in developing my application with it, but I was worried about memory consumption.

I’ll give it a try!

1 Like
14

I found this post wrote in 2019 by RocketChat’s CTO:

15

They are still using meteor.js and if I’m not wrong they are actively helping for version 3.

I had hard times with meteor and it may need more resources as it’s a combination of node app and mongodb. If you are using meteor.js efficiently cpu spikes are not big issues. I’m using both pub/sub, methods and raw collections.

My app has nearly 120 concurrent users and here is the stats.

IMG_9254
IMG_92541170×2532 288 KB

As you can see the resource usage is not a problem.

I couldn’t got you point at all. Rocket chat or anyone else can decide to move away as I do before (we’ve switched to nest+vue and I’m not happy with it) Your claim is not fair. Meteor.js was always a good framework and it’ll become better when it’s fiber-free.

1 Like
16

Run your own server it’s not expensive or difficult. I’ve posted here how to do it so many times.