Parse Server Benchmarking

[gateway]

Hey Guys I did some simple benchmarking today with a Jmeter script , just does a POST and a GET of the object created and I also used apache benchmark... From the looks of the data I'm seeing pretty high response times from the results.. I'm not sure if its the connection between you guys and MongoLab or the small free dyno im running.. here are some of my findings.. Any thoughts?

https://groups.google.com/forum/#!topic/parse-developers/puldzNyFEGs

[doender]

If having multiple cores, you could use the cluster module to scale up the number of processes to the number of cores. Here is an easy example to do this for an express server like parse-server: http://www.sitepoint.com/how-to-create-a-node-js-cluster-for-speeding-up-your-apps/

I tested this snipped and it seems to work:

var cluster = require('cluster');
if (cluster.isMaster) {
    var numWorkers = require('os').cpus().length;
    for(var i = 0; i < numWorkers; i++) {
        cluster.fork();
    }
    cluster.on('online', function(worker) {
        console.log('Worker ' + worker.process.pid + ' is online');
    });
    cluster.on('exit', function(worker, code, signal) {
        console.log('Worker ' + worker.process.pid + ' died with code: ' + code + ', and signal: ' + signal);
        console.log('Starting a new worker');
        cluster.fork();
    });
}
else {
    var api = new ParseServer({
      databaseURI: process.env.DATABASE_URI || 'mongodb://localhost:27017/dev',
      cloud: process.env.CLOUD_CODE_MAIN || __dirname + '/cloud/main.js',
      appId: 'myAppId',
      masterKey: 'myMasterKey'
    });

    var app = express();
    // Serve the Parse API on the /parse URL prefix
    var mountPath = process.env.PARSE_MOUNT || '/parse';
    app.use(mountPath, api);

    // Parse Server plays nicely with the rest of your web routes
    app.get('/', function(req, res) {
      res.status(200).send('I dream of being a web site.');
    });

    var port = process.env.PORT || 1337;
    var httpServer = http.createServer(app);
    httpServer.listen(port, function() {
      console.log('parse-server-example running on port ' + port + '.' + process.pid);
    });
}

Does this help in your benchmark?

[codebreach]

Very interesting data.
Newrelic (last screenshot in the linked google groups discussion) lets you break down requests into DB, Async, IO etc. I believe it is under transaction traces if you click into one of the paths.

Can you take a look at those metrics for a better understanding of what is the slow piece? Maybe you could share your findings so we can also learn from them.

[gateway]

@doender right now im just using a free dyno at Heroku which is prob a small container on some VM that they let you use. I just wanted to see how that preformed with the Free instance at MongoLabs as well.

@codebreach Thanks for reminding me here it is

I dont get the post value being 812ms.. thats crazy..

Next steps is to add some sort of profiling to the code, but I its been ages since I tried to profile node.js and not sure where to start again on a remote server.

[gateway]

Here is my jmeter script, its very simple but you need to change a few things which can be done via text editor if you do not have jmeter.

          <stringProp name="Header.name">X-Parse-Application-Id</stringProp>
          <stringProp name="Header.value">yourappid</stringProp>

add your appid you added for your parse server

line 55 add your domain in

      <stringProp name="HTTPSampler.domain">yourserver</stringProp>

no http.. just whateveryourdomain.com

line 85

change your domain as above

      <stringProp name="HTTPSampler.domain">yourserver</stringProp>

save that and sign up for a free account at blazemeter.. when you log in select jmeter and upload your script..

You can download the script from my server here

[francocorreasosa]

You can run parse-server with PM2 in cluster mode to solve this.

[gateway]

@francocorreasosa could you explain this a bit more , esp for people reading this thread.

[francocorreasosa]

Sure,
You can install pm2 from npm and run
"pm2 start server.js -i 3"
So pm2 will run a 3-node cluster for your server. I think this can be done
to load balance the traffic between parse-server instances plus a load
balancing server.

[jamiechapman]

If you're using Heroku and don't want the complexity of configuring pm2, you could also consider a plugin like Adept Scale to handle this for you: https://devcenter.heroku.com/articles/adept-scale

[gateway]

@francocorreasosa be nice to see if this works, im assuming this would be running on like AWS to scale your EC2 instances or?

@jamiechapman I read though the docs, seems like some of this is still in beta, it would be good to figure out if this could be used with parse-server because nobody is really talking about scaling or how to potentially scale a parse server.

[doender]

"pm2 start index.js -i 2" could also be used one a single instance with 2 cores to distribute the load. I tried it, works perfectly and no changes to the code needed like in the snippet I posted.

[gateway]

@doender If I have time this week Ill test this out and run some benchmarks.. what cloud provider are you using?

[doender]

DigitalOcean

[gateway]

@doender thanks for that. From building my own backend for a game called TouchFish as you scale you will need to eventually have load balancers in front of your parse servers that will then based upon the parse server health or requests send the data to x server. I have yet time to mess around with this and might try it in aws since they have already load balancers you can use with one of their many services.

[steven-supersolid]

Here are a suggestions for a few other load tests that may be useful to do, in clustered and non-clustered configurations:

1. Test HTTP request to non-Parse Heroku Node.js app, e.g. a simple hello world - this will give you the baseline speed
2. Test empty Cloud Code function call - this won't hit the database, should be similar to baseline
3. Your test original test - will include database latency overhead
4. Test Cloud Code function that makes a database call - will test impact of additional resources used by Cloud Code when it makes an API call request