Many working with Meteor JS wonders about performance concerns associated with Meteor JS. This blog points some of those concerns and represents my opinion on why they are invalid concerns.
Database as a Bottleneck
Inability to handle heavy read-write loads, especially, write load/performance; However, with latest releases of MongoDB, MongoDB is good enough to easily handle very large data requirements of read/write. Following are related details:
- MongoDB supports different techniques to scale out appropriately based on the read-write requirements. They are as following:
- Secondary reads (reads from slaves, writes from primary/master).
- Sharding techniques
- MongoDB (3.0+) has come up with new storage engine, WiredTiger, which supports document-level concurrency control for write operations as a result of which multiple clients can modify many different documents at collection level. For most read-write operations, WiredTiger uses optimistic concurrency control and appropriately uses intent locks at global, database and collections level. With servers having multiple cores, multi-threaded write workloads with document level concurrency would turn out to be very beneficial.
- WiredTiger storage engine can prove to be great for write-heavy apps as it supports write-optimized data structures (such as LSM). It comes up with a great feature of snapshot checkpointing combined with Journal (write-ahead on-disk logging) which makes it durable enough. WiredTiger supports compression which is very much suitable for write-heavy loads.
Details on MongoDB benchmarking for read/write could be found on https://www.mongodb.com/blog/post/performance-testing-mongodb-30-part-1-throughput-improvements-measured-ycsb.
Application Scalability Issues
One of the bottlenecks for application scalability is the ease with which application can be scaled out in a very quick manner. Given the support from Galaxy PAAS which is created on underlying robust infrastructure of AWS & Docker containers, one can easily achieve following:
- Scale out easily by running multiple copies of app
- High availability configuration support for mission-critical apps
Inappropriate Caching Configurations
One of most commonly sighted performance issue is higher page load time. Given Meteor supports in-memory cache (MiniMongo) which gets synced with MongoDB running on the server end, this is nailed down quite easily. Caching uses autopublish feature such that any changes on subscription data is pushed to the cache. In this relation, one may, however, want to appropriately choose whether to have autopublish package enabled. Autopublish is good with smaller set of documents. The best practice is to disable autopublish package and turn subscriptions on and off to control how much data should be kept in the cache thereby managing the network traffic. When a subscription is turned off, all of its documents are removed from the cache unless the same document is also provided by another active subscription.
Suboptimal MongoDB Schema Design
There are best practices related with data design which should be followed in order to avoid performance hits. Considerations such as following could help in achieving optimal data design:
Suboptimal Queries Performance
Performance issues could arise due to suboptimal query performance. One may use MongoDB profiler to analyse DB operations and optimize queries appropriately. If done that way, performance could be enhanced.
Indexes (simple or compound) should be considered to avoid performance issues during query execution.
To summarize, Meteor JS should be a good to go framework for any one wanting to start and complete quick app (on Android & IOS). Especially those who are planning a startup in relation with a mobile app, Meteor JS could prove to be a great choice. Be rest assured that it won’t haunt you with performance issue until you become decently big. 🙂