REST API interface is dominant way of machine-to machine communication because of its flexibility, performance, simplicity and lightweight.
Recently I had to perform a quick performance test to check if response time of one application is in line with SLA (Service Level Agreement).
Such performance tests are particularly important in case of SaaS architecture where you (in case you are not in position of some large enterprise where different rules apply) don’t know actual performance of your hardware/compute nodes and overall architecture where your application is running.
With SaaS Software you usually establish SLA based on what application is doing.
Thus SLA can be based on number of concurrent connections, number of generated requests/responses, number of events and many other application specific metrics.
To properly define SLA, it is especially important to define what is acceptable and reasonable.
My advice is to start with first defining what are the mission critical functionality and start defining your SLA from there.
For Web page loading, acceptable time is under 1 second (usually 500 ms) but that’s definitely too general metrics and in most cases far from enough.
Thus besides Web page loading, you should always define SLA for specific critical business process (like maximum time for executing clearance or promotion in case of Retail software …).
For REST API calls which are important for integration, you can also define general SLA (like 300 ms average response time, 500 ms as a maximum response time), but you can also add specific SLA for some APIs that are critical for your business.
There are many ways of how to quickly perform some stress tests, but the following one is one of the best you can find around.
Prerequisite for our quick test is Linux OS (for IT Professionals I always advice to have a Linux box based on Fedora or Ubuntu at your disposal, but starting with Windows 10, Linux is natively supported as Windows application, thus you won’t need to mess up your PC with Cygwin any longer), Terminator – terminal client “on steroids” (replacement for a default Linux Terminal), and finally up & running application whose performance will be tested.
In this case I want to get system time from the application, according to the available API.
To get system time from my app I need to execute the following command:
curl --request GET --url https://your.application.com/projectToken/system/time --header 'authorization: Basic <basic auth token>' --header 'content-type:application/json'
{"errors": [], "success": true, "time": 1564336036.3965647}
In case I want to measure response time, I just need to add “time” command in front of “curl” like in the following code fragment:
time curl --request GET --url https://your.application.com/projectToken/system/time --header 'authorization: Basic <basic auth token>' --header 'content-type:application/json'
{"errors": [], "success": true, "time": 1564336036.3965647}
real 0m0,449s
user 0m0,019s
sys 0m0,007s
Now that I know how to measure performance for some API, I need to put some load to see how application under the test can scale.
First I need to split terminal horizontally and vertically and/or to add new tabs up to expected number of clients (e.g. if maximum number of concurrent users to perform some action is going to be 50, it means you’ll need to have 50 horizontal/vertical terminal splits).
After creating desired number of terminal windows, I only need to click on the upper left corner of the Terminator, and to select “Broadcast all” option as can be seen in the following picture:
After enabling broadcasting to all terminals, I can test if it is working as expected by typing some text.
Whatever you type in the first screen, should appear to all other screens (check the next screen).
The last step is to just paste the curl command with time command in front of it:
time curl --request GET --url https://your.application.com/projectToken/system/time --header 'authorization: Basic <basic auth token>' --header 'content-type:application/json'
hit the Enter and check the results you’ll get.
In this case you can clearly see that some REST API requests will be completed in around 400 ms, while others will take much longer (5.6 seconds or even more).
If average SLA for that particular REST API (or for all APIs) is defined to be 300 msec while max allowable response 500 msec, your vendor is not within SLA frame.
Summary:
Nowadays, in the age of Cloud computing, you leave control over your infrastructure (IaaS), OS and infrastructure software (PaaS) to your Cloud vendor(s), and sometimes, in case of a SaaS apps, you are even letting your app vendor to handle your apps and your data.
That’s one of the reasons why today is more important than ever to have more ways to control and monitor what is going on with Cloud part of your IT.
In case of SaaS apps, the only performance monitoring you’ll get by default is some kind of Status console, where you can visually check some metrics exposed through the web.
Consequently I believe it’s always good to have a mean of checking what are the actual performance are looking like and to not exclusively rely on what vendor can expose.
Equipped with knowledge from this article, you can perform quick test in almost no time and get back some control over your application and vendor that provides it as a service.
Comments