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%
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.
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.