CODEWITHSUNDEEP
node.jsmongodb
Zane Claes
Zane Claes

Reputation: 14954

Node.js API choking with concurrent connections

This is the first time I've used Node.js and Mongo, so please excuse any ignorance. I come from a PHP background. It was my understanding that Node.js scaled well because of the event-driven nature of it. As such, I built my API in node and have been testing it on a localhost. Today, I deployed it to my cloud server and everything works great, except...

As the requests start to pile up, they start to take a long time to fulfill. With just 2 clients connecting to the API, already I'm seeing 30sec+ page load times when both clients are trying to make several requests at once (which does sometimes happen).

Most of the work done by the API is either (a) reading/writing to MongoDB, which resides on a 2nd server on the cloud (b) making requests to other APIs, websites, etc. and returning the results. Both of these operations should not be blocking, but I can imagine the problem being something to do with a bottleneck either on the Mongo DB server (a) or to the external APIs (b).

Of course, I will have multiple application servers in the end, but I would expect each one to handle more than a couple concurrent clients without choking.

Some considerations: 1) I have some console.logs that I left in my node code, and I have a SSH client open to monitor the cloud server. I suspect that this could cause slowdown 2) I use express, mongoose, Q, request, and a handful of other modules

Thanks for taking the time to help a node newb ;)

Edit: added some pics of performance graphs after some responses below... Apache connections CPU usage

EDIT: here's a typical callback -- it is called by the express router, and it uses the Q module and OAuth to make a Post API call to Facebook:

post: function(req, links, images, callback)
{
    // removed some code that calculates the target (string) and params (obj) variables
    // the this.request function is a simple wrapper around the oauth.getProtectedResource function
    Q.ncall(this.request, this, target, 'POST', params)
    .then(function(res){
        callback(null, res);
    })
    .fail(callback).end();
},

EDIT: some "upsert" code

upsert: function(query, callback)
{
    var id = this.data._id,
        upsertData = this.data.toObject(),
        query = query || {'_id': id};

    delete upsertData._id;

    this.model.update(query, upsertData, {'upsert': true}, function(err, res, out){
        if(err)
        {
            if(callback) callback(new Errors.Database({'message':'the data could not be upserted','error':err, 'search': query}));
            return;
        }
        if(callback) callback(null);
    });
},

Admittedly, my knowledge of Q/promises is weak. But, I think I have consistently implemented them in a way that does not block...

Upvotes: 2

Views: 2107

Answers (1)

Gates VP
Gates VP

Reputation: 45287

Your question has provided half of the relevant data: the technology stack. However, when debugging performance issues, you also need the other half of the data: performance metrics.

You're running some "cloud servers", but it's not clear what these servers are actually doing. Are they spiked on CPU? on Memory? on IO?

There are lots of potential issues. Are you running Express in production mode? Are you taking up too much IO on your MongoDB server? Are you legitimately downloading too much data? Did you get caught in an infinite Node.JS loop? (it happens)

I would like to provide better advice, but without knowing the status of the servers involved it's really impossible to start picking at any specific underlying technology. You may be a "Node newb", but basic server monitoring is pretty standard across programming languages.

Thank you for the extra details, I will re-iterate the most important part of my comments above: Where are these servers blocked?

  • CPU? (clearly not from your graph)
  • Memory? (doesn't seem likely here)
  • IO? (where are the IO graphs, what is your DB server doing?)

Upvotes: 3

Related Questions