Compute Time for Methods with HTTP

1

I’m trying to pinpoint sources of CPU spikes on my Galaxy instances. I figured a good place to start would be going to Meteor APM → Methods → sort by Compute Time. Every single method at the top are basically HTTP calls with callback functions.

According to the Kadira docs, the Compute Time metric is defined as: “Time spent on CPU-intensive tasks inside a method (e.g. time spent sorting and calculating some value).”

Here’s my highest compute time method:

Meteor.methods({
    getData(url) {
        this.unblock()
        return new Promise((resolve, reject) => {
            HTTP.get(url,function(error, response){
                if(!error){
                    resolve(response.data)
                } else if (error){
                    reject(new Meteor.Error('getData failed',JSON.stringify(error)))
                }
            })
        })
    }
})

All of these methods coming back as high CPU use return new Promise in their underlying structure. Is that where I’m running into issues? Is this actually locking up my CPU? Or is it just a funky reporting behavior in APM?

If so, what alternatives should I use? This seems like it has the same result – is there any reason Meteor would handle this differently from a Compute Time perspective?

Meteor.methods({
    async getData(url) {
        try {
          var data = await HTTP.get(url)
          return data.data
        } catch(err) {
          console.log(err)
          return 'getData failed'
        }   
    }
})
2

I’m almost 100% sure that’s it’s a faulty reporting: your original getData method does not consume CPU time beyond a negligible minimum.

As to the alternative code, it wouldn’t work that way: HTTP.get is waiting (internally) in a Future rather than returning a Promise, so you can’t await it.

As a side note to your original method, you might want to use Node.js’ util.promisify.

3

The first one returns a promise, therefore, Meteor methods will automatically await that promise before returning. It is not blocking your event loop but that should hold a thread while waiting for results. You are getting the correct compute time of the method which is until the http call has been resolved and the method returns.

For the alternative, it is possible that APM handles compute time differently because it already knows that the method is async at the start.

In my view, if you are really after knowing the compute time, the first one gives you a better understanding that if an http call is slow, it is affecting the performance of your app because the client is waiting for the results.