Server Performance issue, Wait time getting high on methods, Getting slow

Hi, I’ve built a sample chat application with Meteor 1.4.1. Here I’m trying to do a stress test by sending 10 messages per second. to monitor this I’m using Kadira APM.

Click here for the Trace for one send method.
In case link got expire here, I’m attaching the screenshot as well.

I can’t even user Meteor.defer or this.block here because I need to send the response to the client confirming whether the message is sent to the server or not.

Any help or tip will be helpful, thanks in advance.

1 Like

Any workaround solution to this?

Could you post your code? That does look like it was implemented wrong.

You need to use this.unblock() in your methods and publications. Performance will always suck until you do this.

1 Like

@rjakobsson here below is my send method

      let st = process.hrtime();
      if (! this.userId) {
                throw new Meteor.Error('error-not-authorized','User need to login', {method: "send"})
      //check for the validation
      NonEmptyString = Match.Where(function (x) {
        check(x, String);
        return x.length > 0;
      check(msg, {
        id: String,
        msg: NonEmptyString,
        rid: String,
        lts: String

      let u = Meteor.user()
      let r = Rooms.findOne({_id: msg.rid})
      if(! r){
        throw new Meteor.Error("error-room-invalid", "Invalid Room id",;

      //find the recepient user and check if he is online or not, if not send a push notification.
      let ru = Meteor.users.findOne({$and: [{username: {$in: r.users}},{username: {$ne: u.username}}]})

      if(! ru){
        throw new Meteor.Error("error-invalid-recipient","No recipent user found",;

      // TODO: Check for message limit
      let record = {
                msg: msg.msg,
                rid: r._id,
        u: u.username,
                ts: new Date(),
        lts: msg.lts
      let result = null;
      try {
        result = Chats.insert(record);
          //increase the msg counter
          Rooms.update({_id: r._id}, {$set: {mc:}})

          if((ru && ru.status) ? ! : true){
            Meteor.defer(function() {
      } catch (e) {
        if ( === 'MongoError' && e.code === 11000)
          result = record._id;
          throw new Meteor.Error('error-500','Something went wrong', e)
      let et = process.hrtime(st);
      return {_id: result};

@veered I can’t use this.unblock() here because I need a response back from the method. Though I’ve used this.unblck() in my subscriptions now.

This issue arises only when I try to send messages like 10 messages per second.

this.unblock() doesn’t stop you from getting a response back from a method, it just makes it so that other methods/publications can be processed while this one is running (with the magic of fibers).

1 Like

In the above send function, How can I restructure it with this.unblock ? should I use with every DB operation?

Just call this.unblock() on the first line


Thanks, It helps, I had the wrong assumption about the this.unblock() function.

You need to use this.unblock() in your methods and publications. Performance will always suck until you do this.

Always wondered why this isn’t the default behavior …

1 Like

isn’t this could be overhead to use in all the methods and publications. There could be some drawback of using this all the times.
Here I can use this for methods like send , read, and delivery report.

Because it can cause very hard to debug situations. The nice thing about the meteor calls now is that they work in serial. Unless you unblock off course.

A simplistic example here:

It is clear now. Thanks

I think that it’s best to use this.unblock in almost all situations, for both methods and publications. Qualia has a pretty sophisticated wrapper around all methods and publications, that makes this the default (and automatically does other things, like permissioning, rate limiting, debouncing, logging). We have yet to encounter a situation where this has caused issues.

If you don’t use this.unblock you will struggle to achieve acceptable performance. Unless you call this.unblock literally ZERO other methods or publications will be run until the current one completely finishes. For long running methods/publications that’s a total disaster.


Sorry to bump this… but trying to understand this.unblock and Meteor.defer. When you say:

Do you mean for just that client’s methods and publications? Or the entire server - thus all clients? It’s my understanding this is per client unblocking.

Yeah it’s per-client/ddp connection, not the whole sever

1 Like