Compare the differences between HTTP benchmarking with tools like wrk and httperf and code benchmarking with Node’s console time and the debug module.
- [Instructor] When developing applications, speed matters. When a site slows down, traffic decreases as the audience looks for better sources. Therefore it's within our best interest to measure site performance to quantify just how fast or slow it is. With those measurements, we can find what's slow and hopefully improve it. In this chapter, we're going to be measuring site performance with a focus on the back end of Node.js applications. Performance optimization is a broad topic, but we'll be exploring some of the fundamentals that should kickstart your exploration.
We'll start with how to measure execution times. We'll compare the differences between tools that measure externally and internally. Finally, we'll profile code execution to measure the internals of programs without changing them. Let's start with benchmarking performance. We discussed performance earlier, but what's a benchmark? A benchmark is a measurement of the time or duration that it takes to complete a whole operation. So what's a whole operation? Here's a few examples of operations that you might want to measure.
There's the server response time when calling a particular route. You could benchmark the duration of a specific function call. Sometimes it's useful to determine how long it takes for one iteration through a loop, which could then generate an average. The duration of database queries is a frequent target. There are two types of benchmarking tools, and it's helpful to know their differences and when to use them. The first are HTTP benchmarking tools, which measure the external responses of a system. The other kind of opposite are code benchmarking tools, which are internal and part of the system being measured.
Let's explore each in turn. HTTP benchmarking tools require no code modification. Typically you just execute the tool with a configuration. HTTP benchmarking measures granular response times, such as how long it takes for the server to respond, how long the transfer from the server takes, and so forth. These tools can be used to simulate the server load by performing a variable number of simultaneous requests for a given amount of time. This makes them useful for stress testing a system, which can highlight problems before they occur in a production environment under load.
There are many HTTP benchmarking tools available. Here are three popular open source examples that can be run on your own workstation. Ab, the Apache HTTP server benchmarking tool, is a utility intended to test Apache servers, but it can be used with any HTTP server. We'll discuss ab in the next video. Httperf is a standalone utility known for its robustness and versatility. And W-R-K, without the O, is an increasingly popular scriptable tool that is capable of, in its own words, generating significant loads on the target server.
In contrast, code benchmarking measures execution times very differently. It typically requires code modification, which is why I referred to it as internal. For example, some systems require placing a timer at the start and the end of the code that you wish to time, then log the end result. Another example is a report that measures and compares specific functions to each other. Using these tools, we can granularly measure how parts of our system work. Unlike HTTP benchmarking, internal benchmarking does not measure latency, such as network response times.
There are many code benchmarking tools, and we actually already have them. For example, Node's console includes time and timeEnd methods. Winston, our logger, includes a simple timer method that can be used to measure execution time. We're going to use Winston to benchmark code later in the chapter. Finally, the debug module provides a minimal timing utility, as well. What about the benchmark module? Where does that fit in? The benchmark module can be used to compare two operations to each other.
For example, whether a regular expression of the letter o in Hello World is faster than indexOf. The answer is strings indexOf, if you were curious. Does that mean you need to rewrite your whole codebase? Probably not. We'll discuss micro-optimizations later in the course. As an overview, benchmarking measures operation times of a system. In the context of the web, benchmarking can be external to the system over HTTP or internal as part of the codebase itself.
HTTP benchmarking can be used to simulate load on a system and test how it responds under stress. Conversely, code benchmarking measures granular segments of a system. Let's apply this theory by stress testing our system using Apache Bench.
- Building a troubleshooting mindset
- Why measure performance?
- What's a microservice architecture?
- Managing microservices with PM2
- Effective logging strategies
- Debugging Node.js applications
- Benchmarking performance
- Profiling code execution
- Knowing what to optimize