Performance Issues

[mitsol]

Hi! Recently i recognized that my Meteor projects got very slow using chrome (in development). At first I thought it was caused by a Meteor update, however when i tried to start chrome without extensions all went back to rocket speed! Disabling one extension after the other revealed that the meteor-devtools were the reason for this. Any suggestions how to avoid this? All in all i really like meteor-devtools 👍

[leonardoventurini]

Can you share your computer specs (CPU, memory, OS, etc)? I suspect it might be related to the new performance feature capturing every minimongo call or the new Chrome's API. Please share all information you can so it helps with the investigation. Thanks :wink:

[plb666]

Thank you for you work. I have the same issue on my MacBook Pro (16-inch, 2019):

• 2,3 GHz Intel Core i9 8 core
• 16 GB 2667 MHz DDR4
• macOS Monterey 12.3.1
• Chrome version 100.0.4896.88 (Build ufficiale) (x86_64)

[mitsol]

I use it on an IMAC Pro 2017

• 3,2 GHz 8-Core Intel Xeon W
• 32 GB 2666 MHz DDR4
• macOS Monterey 12.3.1
• Version 100.0.4896.127

[HoptimizeME]

Same here on a Mac M1 Max with 32gb. The admin console of our app is does not finish loading anymore. I agree, there are way too much subscribes on this page but still ;-)

[leonardoventurini]

@HoptimizeME I am sad to hear these reports, I am investigating. Thanks for the feedback.

[HoptimizeME]

@HoptimizeME I am sad to hear these reports, I am investigating. Thanks for the feedback.

Thanks a lot Leonardo! It's greatly appreciated. We've just discovered it and we're impressed by how much it's going to help us!

Thanks again!

[leonardoventurini]

Glad to hear that @HoptimizeME.

I suspect it is some edge case specific to your applications, will need your help solving this.

@mitsol @plb666 Do you guys get any unusual amount of calls (or increased processing time) in the Performance tab for any operations when the slowdown occur?

@HoptimizeME Do you get any errors in the console? You can also go to the chrome://extensions page and inspect the extension worker:

[plb666]

In our case, the methods and subscriptions can return fairly large JSONs. I noticed that when the page is loaded, the DDP TAB finishes displaying the information very late, in my case it takes more than a minute with this data:

From a quick performance analysis, it seems that all the time is used by the processTraces function.

[leonardoventurini]

Wait, processTraces is from the old devtools not mine:

Are you guys using this one?

https://chrome.google.com/webstore/detail/meteor-devtools-evolved/ibniinmoafhgbifjojidlagmggecmpgf?hl=en

cc @plb666 @mitsol

[HoptimizeME]

Wait, processTraces is from the old devtools not mine:

Are you guys using this one?

https://chrome.google.com/webstore/detail/meteor-devtools-evolved/ibniinmoafhgbifjojidlagmggecmpgf?hl=en

cc @plb666 @mitsol

Hi,

Chrome says it's using this one yes. When clicking the link, the button says "Remove from Chrome" but it also says : Offered by leonardoventurini Version 1.5 Updated April 13, 2022

So it seems it's made by you. Is it confusing both because of the name or an ID ?

Regards,

Burni

[leonardoventurini]

@plb666 What about you? Can you confirm that?

@HoptimizeME Nah I was just confused since @plb666 mentioned a function not present in my codebase.

If you guys want to pick a time in my Calendly so we can repro together, that would be helpful. :wink:

[plb666]

@leonardoventurini I reinstalled the extension, now I have the 1.5 version of Meteor Devtools Evolved

The performance TAB is always empty and app performance is very slow.

Minimongo:

Subscriptions:

DDP:

The chrome instance uses 222% of the cpu:

Processing of DDP messages seems very slow, as does adding records to Minimongo. Whereas the profiler seems to report nothing interesting.

[leonardoventurini]

@mitsol @plb666 I see now, I believe it is the version of Chrome, it presented this kind of behavior you are describing with Manifest v3 extensions in v100. Please try upgrading if possible. If the issue still occurs then please schedule a time with me in my Calendly.

https://calendly.com/leonardoventurini/quick-call

[JD2k]

Got the MacBook Pro 2020 2,3 GHz Quad-Core Intel Core i7 32 GB 3733 MHz LPDDR4

Just wanted to add, that i got the same performance problems. Got even a total stuck when this extensions is activated. Tested it in Chrome version 104.0.5112.101 and Firefox 103.0.2 (64-Bit) . Everytime same result. If my subscriptions are small everything works fine, but it seem at a specific threshold the perfomance go south. Couldn't find this threshold so far.

[dallman2]

I am having a similar issue in my application. I am sending a few hundred records through a subscription. Each record is approximately 15 to 20 kb. When meteor devtools are enabled, the ddp is super slow to report, and the render performance in my app tanks. Disabling the dev tools totally fixes it. Additionally, I am using the added and changed functions rather than returning cursors from my publish function.

Edit: When I inspected my code, the publish function ran in an acceptable amount of time, about a second or so. The data showed up in minimongo in a reasonable amount of time (maybe 10 seconds or so), but definitely slower than when devtools were disabled. Upon profiling, a lot of the time seemed to be taken up by the useSubscription react hook.

My system is windows with a 12th gen i7 and 16gb of RAM. Most recent version of chrome.

[leonardoventurini]

@dallman2 Can you share an anonymized version of the publication's code so we can repro? And the Meteor version too. Thanks!

[dallman2]

@dallman2 Can you share an anonymized version of the publication's code so we can repro? And the Meteor version too. Thanks!

@leonardoventurini , I do not think I will be able to produce an anonymous version of the publish function, there is a lot of code that backs it up. I can give you a pseudocode version, though. Also we are on meteor 2.7.3

Meteor.publish('mypublish', function(queryInfo){
     if (this.userId) {
        const publisher = new PublicationHelper(this, queryInfo);
        publisher.doQuery();

        this.onStop(() => {
            // this calls `stop` on our live query handles
            publisher.destruct();
        });
    }
    this.ready();
})

Here is a basic look at what happens in doQuery:

function doQuery(){
      // do the query
      console.time('doquery');
      const cursors: Mongo.Cursor<Document, Document>[] = executeQuery();
      console.timeEnd('doquery');
      // about 0.2ms
      // set up query observers
      console.time('cursormap');
      cursors.forEach(singleCursorSetup);
      console.timeEnd('cursormap');
      // about 5s
}

You see some mapping going on here, but really, the list of cursors returned from the executeQuery function is at most two elements. Here is how the data gets sent over in singleCursorSetup:

        const obs = cursor.observeChanges({
            added(id: string, doc: Document) {
                addedHandler(target, id, doc);
            },
            changed(id: string, fields: Document) {
                changedHandler(target, id, fields);
            },
            removed(id: string) {
                removedHandler(target, id);
            },
        });

The handler methods are what eventually invoke the this.added and this.changed functions. Again, the code in the publish function is not what is taking a long time. The added and changed functions are all called within a few seconds (~5) for a result set of about 300 documents. Upon inspection of the front end, a lot of time is spent in the useSubscribe method.

Edit

I just remembered that my application is using a non-default mongo driver. That is, the collections that I'm trying to pull from reside in a different meteor project. Thought that might be good intel to have...

[fn-jenny]

Hi, I also have the same performance problem, high RAM / CPU / power consumption.