'Have you developed or are you in the process of creating an API Server that will be used on a production or cloud environment? In this 4th instalment of my series, I show you how to test the availability of your API Server, so that you can understand how many requests per second it can handle whilst performing heavy duty tasks. Node JS Performance Optimizations This is a very important measure, especially for production environments, because the last thing you want is to have incoming requests queued as a result of your API Server peaking and not freeing up resources often enough. A Quick Note While I’ll be referencing in this article, most of the theory and principles mentioned can apply to any platform and environment. NodeJS Watch The Video On YouTube Which Benchmark Testing Tool To Use The tool I’ll be using for my tests is called . It’s written entirely in and is very similar to , , , , etc. This is good news because you are not forced to use AutoCannon to follow along with this article. If your benchmark testing tool can perform load tests against HTTP requests and can determine the average requests per second, you’re good to go. AutoCannon NodeJS Apache Benchmark Artillery K6 Wrk That being said, should you wish to make use of AutoCannon, it’s as easy as installing it globally as an NPM Module: npm i -g autocannon How To Test The Availability Of Your API Server Firstly, there is an online that you can reference should you wish to run these examples on your local environment. All you will need is NodeJS installed. Source Code Repo The snippet of code below gets you pretty much 99% to where you want to be, with the exception of setting up your package.json, setting the NODE_ENV to Production and PORT to 6000 (reference sample code in provided Source Code Repo and embedded video should you struggle). Add the following to an file. app.js ( ).config() Express = ( ) App = Express() HTTP = ( ) BCrypt = ( ) App.get( , (req, res) => {
  res.send( )
})

App.get( , (req, res) => { hash = BCrypt.hash( , )
  res.send(hash)
}) port = process.env.PORT server = HTTP.createServer(App)

server.listen(port, () => { .log( , port)
}) 'use strict' require 'dotenv' const require 'express' const const require 'http' const require 'bcryptjs' // Router Setup '/pulse' '' '/stress' async const await 'this is a long password' 8 // Server Setup const const console 'NodeJS Performance Optimizations listening on: ' This is a very simple Express Server that exposes 2 Routes: /pulse /stress The endpoint represents a very lightweight API that contains no business logic and returns an empty string as a response. There should be no reason for any delays when processing this endpoint. /pulse The endpoint, on the other hand, uses to salt and hash a password. This is quite a heavy process and because it’s completely written in JavaScript, it will land up blocking the Event Loop quite badly. /stress BcryptJS For our first test, we’re going to use AutoCannon to run a load test against the endpoint, to see how many requests per second the API Server can handle when it’s running idle. The process is as follows: /pulse 1. Start up the Express Server node app 2. Run the AutoCannon test autocannon http://127.0.0.1:6000/pulse 3. This is a simple load test that runs 10 concurrent connections for 10 seconds After the test run, you should receive a report that includes an average requests per second. Depending on the speed of your machine, it should vary between 15 000 and 25 000 requests: Now that we have our baseline measurement, let’s see what happens when the API Server is performing heavy duty tasks: 1. Make sure the Express server is running node app 2. Open 2 Terminal windows for the tests to be performed 3. In window 1, run AutoCannon against the endpoint for a duration of seconds /stress 30 autocannon -d 30 http://127.0.0.1:6000/stress 4. In window 2, while the test is running, run AutoCannon against the endpoint, same as before /stress /pulse autocannon http://127.0.0.1:6000/pulse Make sure the test runs to completion whilst the test is running /pulse /stress After this test run, you should see a significant drop in the requests per second for the test. /pulse As you can imagine, this is a frightening result…one that needs to be handled sooner rather than later. What Does This Mean In The Real World While this example won’t make too much sense in the real world, it forms a template for the kind of tests you should be running on your environment. You need to identify when your API Server is running at peak, and then hit it with load testing against lightweight APIs that belong to your server. You need to determine if they can be processed without much delay, or if they get blocked because your code might not be managing the Event Loop well enough. How do I fix the problem? Well, I have good news: As mentioned at the start, I am busy with a series on “ “. Having already used examples from content I’ve published and content to come, I managed to increase the requests per second for the test from to over . Node JS Performance Optimizations /pulse 117 4 000 What you want to do is to my YouTube Channel, as I publish everything there first and almost on a weekly basis. There are already 4 videos for this series, an important one which is “ “. subscribe Bleeding Code Managing The Event Loop Phases I hope this article proved valuable. Stay tuned for more to come Cheers Previously published at http://bleedingcode.com/how-to-test-availability-of-your-api-server/

Apache

YouTube

Join me on my BleedingCode YouTube Channel

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

How To Monitor Your API Server

Too Long; Didn't Read

Companies Mentioned

John Jardin

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

How To Monitor Your API Server

Too Long; Didn't Read

Companies Mentioned

John Jardin

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES