Many faces of performance in Meteor

About me

Definitely more at
radekmie.github.io/about
  1. Software Architect at Vazco
  2. Over 6 years with Meteor in production
  3. Creator of uniforms

Motivation

A big part of my job is a performance consultant in Node.js applications (not all of them are Meteor apps) and I can tell, that most often Meteor is not the source of the problems. Start with treating your app as a standard Node.js app - use profiler, measure all the things you can, analyze your monitoring data. From my experience, the vast majority of performance problems is clearly visible, even with basic monitoring.

forums.meteor.com/t/meteor-performance-optimizations-summary-as-of-2021/55043/10
vazco.eu/blog/how-to-effectively-monitor-the-performance-of-meteor-projects

Frontend

Backend

Database

3rd parties

Meteor

 

 

 

 

 

 

Bundle

DDP

GraphQL/REST

Queries

Network

Example

Application

(simplified)

#1 & #2

#3 & #4

#5

#6

#7

We won't focus on code that much as there's enough content about it elsewhere.

CRON

#1 Bundle size

Step 1: Measure

meteor --extra-packages bundle-visualizer --production

Step 2: Improve

  • Use dynamic imports
    • It does not magically get rid of the code - it's just loaded later.
  • Use smaller package alternatives
    • Remember to make sure it covers all of your needs!
  • Removing dead code
  • Treeshaking

#2 Readiness time

Step 1: Measure

developers.google.com
/web/tools/lighthouse

Lighthouse

Step 2: Improve

#3 Methods
response time

Step 1: Measure

Meteor APM

Step 2: Improve

  • Use this.unblock()
    • Especially useful for external service calls with large delays.
  • Reduce the number of operations
    • Database operations, API calls...
  • Improve database access times
    • We'll talk about it in #7.
  • Optimize the code itself (duh)

#4 Publications
response times

Step 1: Measure

Meteor APM

Step 2: Improve

  • Publish fewer documents
  • Extract shared publications
    • The fewer unique database observers the better.
  • Use cult-of-coders:redis-oplog
  • Reduce the number of operations
    • Database operations, API calls...
  • Improve database access times
    • We'll talk about it in #7.
  • Optimize the code itself (duh)

#5 API response times

Step 1: Measure

Step 2: Improve

Basically everything, really.

#6 CRON jobs

Step 1: Measure

I'm not familiar with any CRON-specific monitoring services or solutions, but most of the APMs give you a possibility to send custom traces or timings.

Also, you could expose the CRON jobs through some API and use your APM.

Step 2: Improve

  • Improve the code of the CRON job
    • It's just code like any other.
  • Perform them less frequently
    • If needed, split it into multiple jobs with varying frequencies.
  • Offload them
    • "Worker nodes" or even entire microservices only for that.
    • Sometimes a single MongoDB aggregation is enough ($merge).

#7 Database throughput

Step 1: Measure

(MongoDB edition.)

MongoDB Atlas provides great tools.

Step 2: Improve

  • Check your indexes
    • Remember to remove the unused ones to reduce the overhead.
  • Check your RAM usage
    • Once the database won't fit in the RAM, the performance will drop.
    • Pruning old or incorrect data may be more beneficial than you think.
  • Check your queries

Takeaway

(Yes, only one.)

Treat them like that and make use of all of the content out there.

There's a lot, really.

Meteor applications are Node.js applications and web applications.

A grain of salt

(Yeah, I had to.)

People do care whether the software they use is fast; that's a fact. But do they care about exact numbers? Not directly, of course, as it doesn't matter whether the page took 990 or 1010 milliseconds to load. But if it's one second versus two, everyone will notice it.

Full text at
radekmie.github.io/blog/on-software-performance

Q&A

Thank you!