2.1.3 update throttles server

[WayneUong]

After executing a few complex searches with 2.1.3 update, the server becomes incredibly slow. After rolling back to 2.1.0, performance is fast again.

[WayneUong]

Might be related to #553

[WayneUong]

When I test locally, mongod has very high CPU usage, 80-90%. The same pattern is observed on server.

[WayneUong]

Note that this is the mongo server. The meteor server is running fine.

[matteodem]

does this problem still persist?

[WayneUong]

Yes. It's still happening after your latest update. The database server CPU jumps to 100% and stays there until I reboot the meteor server.

Once I revert to 2.1.0, mongo server CPU jumps to 100% on heavy search, but goes back down right after searching is done.

[WayneUong]

more testing: closing the browser tab will decrease CPU load, meteor server reboot is not needed. So the problem might be client-side.

[WayneUong]

more testing: updating easysearch:core from 2.1.1 to 2.1.2 causes the problem

[WayneUong]

I think this is the problem:

      const intervalID = Meteor.setInterval(() => this.changed(
        collectionName,
        'searchCount' + definitionString,
        { count: cursor.mongoCursor.count() }
      ), 500);

      this.onStop(function () {
        Meteor.clearInterval(intervalID);
        resultsHandle.stop();
      });

The search that is causing the problem is a global search that's always visible, thus, onStop is never called. Other search will stop once I navigate away to another page. Nevertheless, this is still a performance issue. Sacrificing this much CPU power for a count is not worth it IMO. Can you make an option to disable this?

[WayneUong]

@matteodem do you have any update or work-around on this issue? I need the latest update to fix a bug with auto-suggest, but this issue is blocking me from updating. Best!

[matteodem]

maybe it helps to put down the setInterval down? you can test the package locally by cloning the repository and symlinking it into your meteor project (packages/easysearch:core).

[WayneUong]

Removing intervalID locally reduces my local mongod CPU usage from constant 40% to occasionally 7%. So it does help.

Can we add a non-reactive option to save CPU usage? Can you point me to where you observe changes on collections?

[matteodem]

I think we could just make the ms configurable of the interval. and maybe if it's false have it be non-reactive, as in set setInterval is never called.

Does that make any sense?

[matteodem]

Just added the config called countUpdateIntervalMs (see here). Please let me know if setting the property to false helps.

[WayneUong]

Works perfectly now. Thank you (: