Know Your Observers

Observers are among the key components of Meteor. They take care of observing documents on MongoDB and notifying of changes. We usually create observers inside publications. Here are a few common ways to create observers:

Creating observers results in higher CPU and RAM usage because of the work required to detect changes. Fortunately, meteor doesn't create new observers for identical cursors that have the same query selector, fields and sort specifiers. This is normally knows as "observer reuse" and you can check it using Kadira's PubSub dashboard.

Monitoring observers with Monti APM

With Monti APM, you can monitor observers and find out which publications are responsible for creating them. You can also use Monti APM to detect observer leaks, especially if you are working with advance publications and reactive joins.

Let’s discuss how to use Monti APM’s Observer Monitoring to detect performance issues. We’re going to use a sample app which has several observers related performance issues.

High observer usage

High Observer Usage describes a situation in which a large number of observers are being created. We need to find out which publication is responsible and take appropriate action.

See the following video:

You can see how both “Observer Created” and “Observer Deleted” counts are high. Then we can sort publications by Observer Created and find out the exact publication. Then we can check whether that’s something legitimate or not.

Observer leaks

High CPU and RAM usage(and growing) is detected in our app. With Observer Monitoring, we can easily find out which publications are responsible for this leak. See the following video:

Observer Info shows that many observers are being created without being deleted. That’s the reason for the high CPU and RAM usage. This is termed an ‘observer leak’.

Generally, both "Observer Created" and "Observer Deleted" needs to be identical in the long run (24 hours). If not, there seems be a observer leak in your app.

Low observer reuse

Our sample app has a very low percentage of observer reuse. Observer Info shows us that many observer handlers are being created with a very low percentage of reused observers. In most of these cases we can improve observer reuse and boost performance of both Mongo and Meteor.

An observer handler is created every time cursor.observeChanges is invoked. However, Meteor does not create an observer for each observer handler. It will try to reuse an already cached observer: if it cannot, then a new observer will be created.

see following video:

You can learn how to improve Observer Reuse by following this article.