How to stress test back4app ?

[Lucas Verra]

A potential client asked us about the endurance for our API. In theory, b4a is on aws and "very scalable" but how can I give more insight than just plain words? 

ex: https://v.hellovoucher.co/#/cp/WJAjGgBYNW => this URL hits our back4app app an returns a URL 

We wish to know if everything go smootly with ~100 req / min , then maybe 150 req / min . In theory we are on the 30req/s  (so 1800 req /min) 

How can I really test that and give confidence to my lead ? 

Cheers ! 

[al...@back4app.com]

Hello Lucas! That is a really good question so thank you for the opportunity to explain in a little bit more details.

First let me say that here at Back4app, we take scalability very seriously and we are constantly running performance stress tests on our systems to ensure everything is responding as fast as we expect. All our servers are monitored for performance metrics and we have literally thousands of alarms set to inform us if anything is taking too long, and that is done many times per minute, so it is not really necessary for our clients to worry.

That said, if you need to provide such information there are a few tools that can help.

The first one is Artillery (https://artillery.io/) which can send multiple API requests from a single machine, collecting metrics and generating a report. 

This tool is free to use and can generate very trustworthy reports for load tests which you can provide to your client.

It is as easy as write a config file specifying your class path, your App ID and your REST API Key:

- get:

url: "/MyClass"

headers:

X-Parse-Application-Id: "MyAppId"

X-Parse-REST-API-Key: "MyRestAPIKey"

If, on the other hand, you want to collect timing statistics about your requests over time, you can have CURL running over time with the following syntax:

curl -s -X GET -H "X-Parse-Application-Id: YourAppIdHere" -H "X-Parse-REST-API-Key: YourRESTApiKeyHere" -w "%{time_starttransfer}\n" -o /dev/null https://parseapi.back4app.io/classes/MyClass

which will bring you the time_starttransfer statistics.

Other possible statistics are:

time_namelookup

time_connect

time_appconnect

time_pretransfer

time_redirect

time_starttransfer

time_total

Now, it is important to say that doing such tests will perform API requests, which will consume your plan, so use it wisely for tests but do not let it run indefinitely.

I hope this helps you with testing. If you need any further assistance, please, let me know.

Best regards!

[Lucas Verra]

Hello there and thanks for that info. 

Before your answer we've managed to use loader.io (by sendgrid) and installed a txt file (in order to ensure we are the owners of the assets to test)

We've managed effortlessly to show 900 req / min (or 15 clients req / sec for a whole minute) => report is here  http://bit.ly/2VQVaGn ! 

That's more than enough for a lead. 

In our case this is more representative as is closer to business logic : URL endpoint => API=> cloud function => added value. 

Testing a class from database seems not as "business realistic". 

Thanks for answering !