Dear Meteor MDG and Other Community Users,
With every new release of Meteor, it is becoming a stronger candidate for large scale Enterprise level apps. We are developing all our apps in our company only into Meteor + ReactJS + React Native.
IMHO, this is a fantastic framework and we are helping Meteor’s awareness among all our clientele.
However, there is one constant question asked by several of our clients on its possible performance when system grows to a very large scale. Many other technology users keep pointing to old 2015-16 reports and articles on internet to show the limitations of Meteor. We know very well that most of those limitations have been taken care and eliminated in subsequent releases of Meteor.
We want a strong article or White Paper where there is clear mention of
- Performance of Meteor app in large scale / large data system?
- Maximum Concurrent Users supported with single database?
- What are possible methods when such limits are hit?
- What possible care we should take while designing and developing large scale apps?
- What are security protocols or best practices to be used for large scale apps?
When such Official article is available, we can confidently go back to our clients and pitch strongly for MeteorJS. That will help widespread use of MeteorJS technology.
Please help us answer above questions.
Thanks
Ashish Naik
Founder & MD
iAssure International Technologies Pvt Ltd
3 Likes
It really depends on your app’s architecture. Does it need reactivity? Will it all be installed in a single datacenter? Is the issue of max concurrent users related to handling traffic spikes or average loads? What’s your user base’s usage patterns? Are there Black-Friday or Slashdot like events? Or is it day-to-day business traffic?
Anecdotally, there are a lot of applications that hit 1000 users per node server; and some apps manage to squeeze 2000 or even 5000 users per node. But if you don’t need reactivity, and can remove the tracker, ddp, and related reactivity packages, and run on pure REST or Meteor Method calls, you can boost that up to 20,0000 or 40,0000 calls that the raw node servers can handle. But then it’s not a reactive application. There are tradeoffs.
Alternatively, you can try to scale horizontally and bring up more nodes. Bring up 100 or 1000 app nodes. We’ve definately heard of installations that run 100+ app nodes. Or do a multitenant architecture; or peer-to-peer architecture. Those architectures would let you install many thousands of server nodes. But then you have loadbalancing and database query bottlenecks.
This ‘scalability’ question is complicated, because scalability tends to be dependent on your application’s use and intent. And scalability always boils down to resolving bottlenecks.
Also, the question is sort of like asking what the MPG fuel efficiency of a car is. Well, highway or urban driving? Are you pulling a trailer? Is it a hybrid vehicle with electric assist? Those are all application and architecture considerations that can affect your car’s performance. So, too with Meteor apps.
13 Likes
@awatson1978 Although your comment is valuable, the way you criticise @iassureit’s question, I think, is not fair. The five questions regarding performance of Meteor are the basis that need to be addressed or answered for any IT platform/application/system that categories itself as an enterprise grade solution. If there are no answers or only generic answers, like in your comments, in official documentation, then it means this solution would only be an experimental one or an immature one. (Consider if these questions were asked for a Oracle DB solution, or for Java, etc., they have official docs for all these)
4 Likes
Oracle is a database*. Read the equivalent mongo docs if you want those sort of questions answered. Meteor is a whole lot of things, not just a database - @awatson1978’s answer is completely on point and the analogy is apt.
* and I’m not sure how those first three questions would apply to a language
4 Likes