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

[gateway]

Ill be running tests on AWS , since they now have a set up to work with Parse server that uses their Elastic Beanstock system (manages load balancers, auto scaling etc).. More found here http://mobile.awsblog.com/post/TxCD57GZLM2JR/How-to-set-up-Parse-Server-on-AWS-using-AWS-Elastic-Beanstalk

[gateway]

Also above Ill be testing https://www.mongodb.com/migrate-from-parse-to-mongodb-cloud-manager-and-aws provisioning system in aws with beanstalk

[nitrag]

Eagerly following...any updates?

[gateway]

Sorry I was side tracked this weekend with other stuff and am looking into seeing how to integrate PM2 depending on the AWS EC2 I use since you can run one instance of node.js on a core. I want to make sure the nodes also restart if they crash of fail, so a lot of reading up on Elastic Beanstalk.

[markuswinkler]

@gateway any updates?

[gateway]

@markuswinkler last week, got pulled into figuring out what hosting we will be doing and will do my first decent load test with mongo cloud (in aws) and elastic beanstalk with parse servers.. This will give me the ability to scale parse servers up or down based on load and use a nice interface for mondodb cloud manager to have 1 replica set of 3 servers to start with.

[markuswinkler]

@gateway Fantastic! I bet this kind of setup applies to a lot of people who want to migrate, looking forward to the results! Are you going with m3.medium instances?
Also, I hear a lot of different opinions on wether to use a service like MongoLab/Compose.io or manage the mongodb servers yourself. What is your stance on this?

[nitrag]

I think I've tentatively settled on AWS EB and Compose.io. I am very interested to see your results. Thanks!

[gateway]

@markuswinkler it will depend on what your skill level set is or how comfortable you are using other interfaces. For our Likemoji project we will be going the route of Elastic Beanstalk to handle load balancing, scaling of parse servers and connecting to a cluster of mondodb servers running in the same amazon region. We will also be using mondo cloud to admin the mondo databases which provides a nice interface, backup system and ability to fire up various replica sets in amazon east region but better yet in different data centers (to avoid a data center going down and your app to not work)..

Mongo just did a webinar on using their system with aws.. https://www.mongodb.com/presentations/webinar-step-by-step-parse-migration-plan.. anyhow rambling. Most people not really tech savvy can just use heroku and mongolab which works. Ill prob do a writeup on my personal blog about my experiences.

EDIT: btw your data set will grow by 2-4% when you move from Parse.com to a new mongo service due to the lack of compression. So anything you look at as far as a plan make sure you consider the db storage space because its not 1 for 1

[markuswinkler]

@gateway Interesting, thanks for sharing the link, looks very helpful should we go that route!
Btw, your estimated growth of the DB of 2-4% is a significantly lower than the official one from parse.com, stating your DB will need 10x (1000%!) more space as stated here: https://github.com/ParsePlatform/parse-server/wiki/Parse-Server-Guide

[gateway]

@markuswinkler yea, I was going off what the mondodb webinar was saying.. but you deff need lots more space. Its to bad that Parse does not support mondodb 3.2 because they have built in compression with WiredTiger options. Looking at mondo site it says its in 3.0 so maybe ill do some tests with that.

[nitrag]

What will it take to get Parse to support WireTiger MongoDB 3.2 (which I
know nothing about but have heard rumors of good things). Timeframe?

On Tue, Feb 23, 2016 at 1:59 PM, Gateway [email protected] wrote:

@markuswinkler https://github.com/markuswinkler yea, I was going off
what the mondodb webinar was saying.. but you deff need lots more space.
Its to bad that Parse does not support mondodb 3.2 because they have built
in compression with WiredTiger options. Looking at mondo site it says its
in 3.0 so maybe ill do some tests with that.

—
Reply to this email directly or view it on GitHub
#185 (comment)
.

[gateway]

@nitrag see #345

[gfosco]

I believe one of the reasons 3.2 isn't supported is a change in how geopoints are stored, and we're using an older format which is incompatible. So that makes migration difficult unless you handle that on your own after moving to a supported version... and it would be problematic to change how geopoints are stored for any migrated app while old clients are still hitting api.parse.com. For an entirely new app, I think a modified database adapter could be used to work with 3.2.

[gfosco]

I'd like to close this issue, not really seeing much benchmark discussion, and we're still in a state of flux getting closer and closer to production stability.. Seeing examples online for how to properly load-balance and monitor parse-server would be great, and we'd happily link to any good info / blog posts from the wiki.