From fc2c40d04813ef8ff47f64ee9e275ebb2d341f82 Mon Sep 17 00:00:00 2001 From: Jan Dvorak Date: Mon, 28 Nov 2022 18:24:00 +0100 Subject: [PATCH] Wording improvement --- guide/_config.yml | 2 +- ...{scaling.md => performance-improvement.md} | 49 +++++++++++++------ 2 files changed, 35 insertions(+), 16 deletions(-) rename guide/source/{scaling.md => performance-improvement.md} (75%) diff --git a/guide/_config.yml b/guide/_config.yml index 4e2d6d1e07..b709b58c8d 100644 --- a/guide/_config.yml +++ b/guide/_config.yml @@ -66,7 +66,7 @@ sidebar_categories: Production: - security - deployment - - scaling + - performance-improvement Meta: - CONTRIBUTING - CHANGELOG diff --git a/guide/source/scaling.md b/guide/source/performance-improvement.md similarity index 75% rename from guide/source/scaling.md rename to guide/source/performance-improvement.md index b21776b50a..ee5ffd33cf 100644 --- a/guide/source/scaling.md +++ b/guide/source/performance-improvement.md @@ -1,16 +1,16 @@ --- -title: Scaling +title: Performance improvements description: How to optimize your Meteor application for higher performance when you start growing. --- -This guide focuses on providing you tips and common practices on how to scale your Meteor app. +This guide focuses on providing you tips and common practices on how to improve performance of your Meteor app (sometimes also called scaling). It is important to note that at the end of the day Meteor is a Node.js app tied closely to MongoDB, so a lot of the problems you are going to encounter are common to other Node.js and MongoDB apps. -Also do note that every app is different so there are unique challenges to each when scaling, so +Also do note that every app is different so there are unique challenges to each, therefore practices describe in this guide should be used as a guiding posts rather than absolutes. -This guide has been heavily inspired by [Marcin Szuster's Vazco article](https://www.vazco.eu/blog/how-to-optimize-and-scale-meteor-projects) -on this issue and talk by Paulo Mogollón's talk at Impact 2022 titled ["First steps on scaling Meteor realtime data"](https://impact.meteor.com/meetings/virtual/uo2Er8YPqx2vuRcne). +This guide has been heavily inspired by [Marcin Szuster's Vazco article](https://www.vazco.eu/blog/how-to-optimize-and-scale-meteor-projects), the official [Meteor Galaxy guide](https://galaxy-guide.meteor.com/), +and talk by Paulo Mogollón's talk at Impact 2022 titled ["First steps on scaling Meteor realtime data"](https://impact.meteor.com/meetings/virtual/uo2Er8YPqx2vuRcne).

Performance monitoring

@@ -24,6 +24,8 @@ which is the same as with Monti APM, for simplicity. Once you setup either of those APMs you will need to add a package to your Meteor app to start sending them data. +For working with Galaxy APM and optimizing your app through the data there, don't forget to visit the [Meteor APM guide](https://galaxy-guide.meteor.com/apm-getting-started.html). + #### Galaxy APM [package](https://atmospherejs.com/mdg/meteor-apm-agent) ```sh meteor add mdg:meteor-apm-agent @@ -60,9 +62,23 @@ of use, it is still high, and without any doubt should be optimized first. It’s also absolutely vital to remember that you shouldn't optimize everything as it goes. The key is to think strategically and match the most critical issues with your product priorities. -

Publications

-

Low observer reuse

+For more information about all the things you can find in Galaxy APM take a look at the Meteor APM section in [Galaxy Guide](https://galaxy-guide.meteor.com/apm-getting-started.html). +

Publications

+Publications allow for the most prominent aspect of Meteor, live data. +At the same this is the most resource intensive part of a Meteor application. + +

Proper use of publications

+ +

Methods over publications

+8:00 + +

Publication replacements

+consider GraphQL or REST + +

Low observer reuse

+https://galaxy-guide.meteor.com/apm-know-your-observers.html +https://galaxy-guide.meteor.com/apm-make-your-app-faster.html https://www.vazco.eu/blog/how-to-optimize-and-scale-meteor-projects

Redis Oplog

@@ -81,17 +97,24 @@ https://www.vazco.eu/blog/how-to-optimize-and-scale-meteor-projects

Rate limiting

MongoDB

-* always limit access to your cluster (IP whitelisting) +The following section offers some guidance on optimizing performance of your Meteor application when it comes to the database. +You can find these and more information in other places that deal with MongoDB performance optimization, like on the [official MongoDB website](https://www.mongodb.com/basics/best-practices). +These are all applicable and you should spend some time researching into them as well. The guide here offers some initial and most common patterns. + +

IP whitelisting

+If your MongoDB hosting provider allows it, you should make sure that only whitelisted + +https://galaxy-guide.meteor.com/container-environment.html#network-outgoing

Indexes

10:00 * compound indexes * ESR (equity, sort, range) * only the ones needed +* too many indexes actually slow things down * n + 1 * read from secondaries * do not use regex -* too many indexes actually slow things down

Find strategies

17:46 @@ -104,17 +127,13 @@ https://www.vazco.eu/blog/how-to-optimize-and-scale-meteor-projects * query caching * use aggregation & save them -

Methods over publications

-also consider GraphQL or REST -8:00 -

Scaling

Vertical and horizontal scaling

There are mainly two different ways of scaling: the vertical and horizontal one. -* **Vertical scaling** boils down to adding more resources (CPU/RAM/disk) to your server, while horizontal scaling refers to adding more machines or containers to your pool of resources. -* **Horizontal scaling** for Meteor projects typically includes running multiple instances of your app on a single server with multiple cores, or running multiple instances on multiple servers. +* **Vertical scaling** boils down to adding more resources (CPU/RAM/disk) to your containers, while horizontal scaling refers to adding more machines or containers to your pool of resources. +* **Horizontal scaling** for Meteor projects typically includes running multiple instances of your app on a single container with multiple cores, or running multiple instances on multiple containers.

Container autoscaling