DEV Community: Mostafa Moradian

GatewayD: The Case For A Database Gateway

Mostafa Moradian — Tue, 05 Sep 2023 09:26:41 +0000

It has been a year and a half since I embarked on the journey of bringing my long-standing idea to life. This idea had been lying dormant on my list of projects, but I finally decided to develop a database gateway tailored for building data-driven applications. Yes, you read it correctly: a database gateway. Allow me to explain briefly.

The entire project has been carried out in stealth mode, with only a select few witnessing the product demo. During the initial phase, I dedicated three intense months to delve into various database technologies, meticulously examining their internals and understanding the specific needs of users. This extensive reading, research, and investigation allowed me to gain valuable insights and prioritize what truly matters. As a developer myself, I focused on addressing the challenges and demands that I encounter daily, ensuring that the final product caters to my needs effectively.

After spending quite some time on the initial PoC and then the MVP, I had the opportunity to participate in the Nordic PgDay 2023, where I gathered substantial validation for my idea. Throughout the event, I diligently took note of (almost) forty distinct pain points, which I identified while attending talks, workshops, and engaging with professionals possessing diverse levels of expertise. Among the attendees were PostgreSQL maintainers, developers, DBAs, and enthusiasts. I intend to share my findings in a separate post. However, for now, let’s shift our attention to exploring the core aspects of the idea itself.

The Problem

In the vast database world, we encounter numerous layers and actors, but it appears that some areas receive less attention compared to other segments of software engineering and development. One particular aspect of concern is the realm of APIs.

When it comes to HTTP-based APIs, such as REST, gRPC, and GraphQL, we find a plethora of well-established technologies that effectively expose data and functionality to the outside world. An extensive array of supporting tools, including frameworks, webservers, documentation, testing, mocking, versioning, monitoring, security, gateways, load-balancers, and analytics, have evolved to complement these APIs. On the other hand, when we delve into the database realm, we observe that some tools are not as mature as their counterparts. This disparity can be attributed to the unique nature of the databases and varying degrees of attention received by different aspects and parties.

An exemplary illustration of well-developed API-related tools lies in API gateways. These software components sit between clients and servers, offering a range of functionalities like security, monitoring, analytics, load-balancing, caching, and scalability support. Over the years, numerous API gateways have matured and become highly efficient. They excel at intercepting traffic and performing their magic to enhance the API experience.

It is precisely at this point where the concept of a database gateway emerges. Inspired by the success of API gateways, a database gateway serves as an intermediary, bridging the gap between users and the database. Just as API gateways offer a wealth of benefits for APIs, a well-designed database gateway could potentially address the current gaps and bring significant improvements in the database realm. By emulating the magic of API gateways for databases, we can explore new possibilities and unlock greater potential in data management and utilization.

Introducing GatewayD: The Database Gateway Solution

The solution to address the existing database challenges involves the implementation of a database gateway, strategically positioned between clients and databases. With its traffic-intercepting capabilities, this software piece performs its magic to bring forth a range of benefits. From ensuring security and monitoring to enabling analytics, load-balancing, caching, scalability, and various other use cases, the database gateway emerges as a versatile tool.

GatewayD, akin to an API gateway for databases, embodies the very essence of this solution, aiming to tackle the issues mentioned earlier. Comprising several key components, as shown in the below high-level architecture, GatewayD sets out to revolutionize the database landscape:

GatewayD Core (CLI): At the heart of the architecture lies the GatewayD core, positioned between clients and databases, effectively intercepting traffic. Serving as a database-agnostic TCP proxy, it is meticulously crafted in Go and designed to be extensible through plugins. This core component has the exceptional capability to serve multiple databases seamlessly, simplifying the management of plugins through automated installation and management.
GatewayD Plugins: GatewayD boasts an array of dynamic plugins that enhance its functionality. Crafted in Go, these plugins are loaded at runtime, catering to diverse use cases. The following section will provide further insights into the diverse possibilities these plugins offer.
GatewayD SDK: To facilitate the development of plugins, the GatewayD SDK provides a collection of Go utility libraries. These robust tools enable developers to create plugins efficiently, fostering innovation and versatility.
GatewayD Plugin Template(s): Emphasizing efficiency and simplicity, GatewayD offers template projects. Developers can rapidly bootstrap and develop Go-based plugins using these templates. Leveraging the power of gRPC, a GatewayD plugin can be written in any language supporting gRPC. Presently, Go is fully supported, and a Python PoC template is also developed.

Unleashing the Power of GatewayD: Addressing Critical Database Issues

In a manner akin to API gateways, GatewayD empowers users through its plugin system, offering the flexibility to develop customized solutions to tackle pressing database challenges. By harnessing the potential of these plugins, GatewayD aims to address various crucial issues faced in the database world:

High Total Cost of Ownership (TCO): GatewayD seeks to alleviate the total cost of database ownership significantly. By automating tasks and reducing complexity, it curtails expenses related to maintenance, staff, on-premises hardware, cloud infrastructure, migration, and other associated costs. A streamlined approach helps optimize resource utilization and enhances operational efficiency, ultimately leading to cost savings.
Vendor Lock-In: Promoting vendor neutrality, GatewayD aims to support multiple databases, allowing seamless migration from one database to another. By facilitating a smooth transition between databases, it liberates users from vendor lock-in, empowering them with the freedom to choose the most suitable database solution for their needs.
Security and Privacy Enhancement: GatewayD puts a strong focus on bolstering database security and privacy. With capabilities to detect and prevent SQL injection attacks, encrypt data in transit, anonymize and manage data, among other features, it ensures that sensitive information remains well-protected, safeguarding against potential threats and unauthorized access.
Scalability Boost: Emphasizing the importance of scalability, GatewayD strives to enhance the performance of databases. Through scalable solutions, including horizontal scaling, it empowers databases to handle increasing workloads, ensuring smooth operations as demands grow.
Reducing Inherent Complexities (Black-Box Mentality): GatewayD is dedicated to simplifying the complexities often associated with databases. Its innovative approach automates tasks for developers, DBAs, and SREs, streamlining the database management process and making it more accessible to all stakeholders. By lifting the veil on the black-box mentality, GatewayD empowers users to have greater control and understanding of their databases.

GatewayD aims to revolutionize the database ecosystem, providing a powerful solution to elevate the efficiency, reliability, and extensibility of database operations. With its dynamic plugin architecture and extensive capabilities, GatewayD opens the door to a new era of streamlined database management and enhanced data utilization.

The GatewayD Features

GatewayD core boasts a wide range of features, making it a versatile and powerful TCP proxy:

Connection Pooling and Proxying: GatewayD efficiently pools connections to database servers, effectively proxying them to clients. Additionally, it manages connections to clients and proxies them to database servers. This intelligent pooling mechanism optimizes resource utilization and enhances performance.
Database-Agnostic: GatewayD is designed to be database-agnostic, offering seamless compatibility with various databases. PostgreSQL is the current focus, yet we have plans to support MySQL-based databases. This inherent flexibility enables easy extension to support different database systems, enhancing its adaptability.
Plugin-Based and Extensible: GatewayD’s innovative plugin-based architecture allows for limitless possibilities. Developers can craft custom plugins to expand the functionality of GatewayD, tailoring it to meet unique requirements and use cases. This extensibility ensures GatewayD remains future-proof and adaptable to evolving needs.
Multi-Tenancy Support: GatewayD excels at serving multiple databases simultaneously, providing a multi-tenant environment. This capability fosters efficient resource sharing, allowing users to manage multiple databases with ease.
Observability: GatewayD prioritizes observability, enabling users to gain insights into its internal workings and the functioning of its plugins. Comprehensive observability features, including logs, metrics, and tracing, empower users with valuable data to monitor and analyze GatewayD’s performance effectively.

So far I’ve implemented two plugins, and I am working on a few more. These plugins are developed for PostgreSQL, but they can be extended to other databases as well:

gatewayd-plugin-cache (OSS): Transparent caching in Redis for PostgreSQL with automatic cache invalidation based on incoming queries and TTL
gatewayd-plugin-cache-advanced (Enterprise): Transparent caching in Redis for PostgreSQL with advanced features like WAL-based invalidation
gatewayd-plugin-sql-ids-ips (Enterprise): Detecting and preventing SQL injection attack for PostgreSQL using deep learning and other techniques

The Competitive Landscape

In the realm of database gateway solutions, several notable competitors hold their ground, each with its unique use cases and advantages. Below, I’ll provide factual information on some prominent contenders that I’ve investigated:

Connection Poolers:

PgBouncer: A lightweight connection pooler specifically designed for PostgreSQL. It excels at pooling connections to PostgreSQL but is limited to this database only. PgBouncer operates as a single-threaded solution and lacks extensibility and plugin support. Despite these limitations, it remains a popular choice for efficiently managing PostgreSQL connections, and providing valuable features.
Pgpool-II: Functioning as a middleware, Pgpool-II operates between PostgreSQL servers and database clients. It effectively pools connections to PostgreSQL, offering a range of other features. Similar to PgBouncer, it lacks extensibility and plugin support, and its scope is confined to PostgreSQL.

2. Database Proxies:

ProxySQL: As a high-performance SQL proxy, ProxySQL provides robust features but is not extensible and lacks plugin support. It exclusively supports MySQL, making it an excellent choice for MySQL users seeking enhanced performance and capabilities.
MaxScale: This database proxy supports multiple database servers, including MySQL and MariaDB. Notably, MaxScale stands out due to its extensibility, allowing for customization through C/C++ development. Its versatility makes it a preferred choice for users with heterogeneous database environments.
Acra: Positioned as a comprehensive database security suite, Acra offers encryption, access control, data masking, and intrusion detection features. Although it lacks extensibility and plugin support, it provides valuable security enhancements for both PostgreSQL and MySQL.

3. General Purpose Proxies:

HAProxy: Renowned for its reliability, HAProxy provides high availability, load balancing, and proxying for TCP and HTTP-based applications. While not equipped with traditional plugins, HAProxy supports extensibility through Lua scripting. Furthermore, its database-agnostic nature allows seamless integration with various databases.

Let’s not overlook the remarkable contributions of Vitess and Citus, both of which have significantly enhanced MySQL and PostgreSQL’s scalability to unprecedented levels. These powerful extensions have revolutionized the way we handle data, opening up new horizons for scaling our databases like never before.

How-Tos

Install and Use GatewayD

GatewayD is available as a Docker image and can be installed using Docker. It can also be installed using the binary releases for Linux, macOS and Windows. It can also be built from source. Please refer to the installation guide for more information.

A typical use case is to use GatewayD as a transparent cache for PostgreSQL, which is explained in this guide.

GatewayD is configured using a YAML files. There are two configuration files: one for the core and one for the plugins. Please refer to the configuration guide for more information.

Develop Plugins

GatewayD plugins can be developed using the GatewayD Go plugin template. A Python plugin template is in the works. Please refer to the plugin developers guide for more information.

Contribute

GatewayD is an open-source project and contributions are welcome. Please refer to the contributing guide for more information. Proposals are also welcome.

Conclusion

I hope I could explain the idea behind GatewayD and how it can be used to solve some of the problems we face in the database world. I am working on a few more plugins and will share them in the coming weeks and months. I am also working on more features for GatewayD core. I’ll share more information about them in the coming weeks. The project is still in beta, and we need beta testers to help find issues.

GatewayD Cloud is also in the works and will be available soon-ish. It is a managed service for GatewayD that can be used to deploy and manage GatewayD instances. It can also be used to manage plugins and other related services. Stay tuned!

Load Testing Your API with Postman

Mostafa Moradian — Mon, 20 Apr 2020 00:00:00 +0000

In this article, I'll explain how to use a Postman collection I have created to load test our instance of our test API. The process is pretty straightforward, as is shown below. You need to feed your exported Postman collection to our postman-to-k6 converter, and use the generated k6 script to load test your own API.

# convert postman collection to k6 test
postman-to-k6 test-api.json -e env.json -o k6-script.js

# run load test
k6 run --vus 100 --duration 5m k6-script.js

Our Test API & Its Testing Scenario

In order to demonstrate the power of k6 in different scenarios, we have created our test API with various example endpoints, which is available at test-api.k6.io. These endpoints are available in the Postman collection:

Public APIs

List all public crocodiles
Get a single public crocodile

Registration and authentication

Register a new user
Bearer/JWT token authentication

Private APIs

List all your crocodiles
Get a single crocodile
Create a new crocodile (max 100)
Update your crocodile
Update selected fields on your crocodile
Remove your crocodile

The scenario is to test all the public and private APIs. For the private APIs, a user is created and its token is extracted. The extracted token is used to make other API calls. The order is very important in the private APIs, since you cannot delete a non-existing resource, for example. By the way, crocodile is our mascot.

Our Test API Postman Collection

To ease testing of our test API and demonstrate the usage of our Postman to k6 converter, I've created a Postman collection with almost all of our test API requests. You'll see how you can access this Postman collection shortly.

This collection includes a set of collection variables, environment variables, pre-scripts, tests, authorization with two different mechanisms, and usages of the Postman Sandbox API.

Load Testing Our Test API with The Postman Collection

We have created a tool that converts your Postman collection to k6 script, which is called postman-to-k6. You can read more about its features in its release notes.

In order to convert your Postman collection to k6 script, you should take the following steps:

1. Optional: Clone the repository and skip to the step 5 :

I've created a repository for this article that contains the exported Postman collection, along with the converted script and related files. You can clone the repository and import the test-api.json and env.json files into the Postman application and possibly play with them if you want.

This repository contains everything that is needed for load testing our test API, so you can skip to step 4. When using your own collection, you should take all the steps to be able to have a k6 script out of your Postman collection, and to be able to run your load test with it.

$ git clone https://github.com/k6io/example-postman-collection.git

2. Install Node.js (if you haven't already done so):

For this, I highly recommend that you use something like nvm, which is a Node.js version manager that you can use to have multiple version of Node.js at the same time on your machine and be able to switch to any of them quickly.

3. Install the postman-to-k6 tool :

The postman-to-k6 tool is developed to help you convert the requests inside your Postman collections to k6 scripts, which are actually JavaScript code.

$ npm install -g postman-to-k6

4. Convert your exported Postman collection to k6 script :

Assuming your exported collection is named test-api.json, you can run this command to convert it to a k6 script. The env.json includes all your environment variables that are exported from Postman.

$ postman-to-k6 test-api.json -e env.json -o k6-script.js

If you need more fine-tuning of your test (like we did above), like adding data or changing environment variables inside your code, just take a look at the Options section of the postman-to-k6 README.

The script generated by the converter should look like below. As you see, I've manually added the duration (of the test run) to be 1 minute and also added the virtual users (VU) count. These two options let the script run for a minute with 100 virtual users. These 100 VUs try to make as many requests as they can to test the server, which you'll see in the next screenshot.

import "./libs/shim/core.js";
import "./libs/shim/urijs.js";
import URI from "./libs/urijs.js";
import {
  group
} from "k6";

export let options = {
  maxRedirects: 4,
  duration: "1m",
  vus: 100
};

const Request = Symbol.for("request");
postman[Symbol.for("initial")]({
    options,
    collection: {
        BASE_URL: "https://test-api.k6.io/"
    },
    environment: {
        USERNAME: "test@example.com",
        PASSWORD: "superCroc2020",
        FIRSTNAME: "John",
        LASTNAME: "Doe",
        EMAIL: "test@example.com",
        ACCESS: null,
        REFRESH: null,
        CROCID: null
    }
});

export default function () {
    group("Public APIs", function () {
        postman[Request]({
            name: "List all public crocodiles",
            id: "3ddd46c4-1618-4883-82ff-1b1e3a5f1091",
            method: "GET",
            address: "{{BASE_URL}}/public/crocodiles/"
        });

        postman[Request]({
            name: "Get a single public crocodile",
            id: "9625f17a-b739-4f91-af99-fba1d898953b",
            method: "GET",
            address: "{{BASE_URL}}/public/crocodiles/1/"
        });
    });

    // NOTE: The rest of the requests can be accessed
    // from the repository in step 1
});

The generated script is a little bit different from normal k6 scripts, since it includes various abstractions to support different Postman functionality, but you can mix them with regular http requests from k6. Also, there is a libs directory beside the script that includes shims and libraries needed for the Postman scripts to work correctly.

5. Install k6 :

k6 supports various platforms, including Windows, Linux, macOS and docker. In order to install it, just grab an Windows installer or a docker image and run it on your machine. On Linux distributions, you can use APT or YUM, and on macOS, you can use Homebrew.

NOTE: Regarding installation on Windows, you can also use choco k6 package.

6. Run k6 with the generated script :

Now that you have your collections converted into a k6 script, you can invoke k6 like this:

$ k6 run k6-script.js

The result of running the script is shown in the following console output:


          /\      |‾‾|  /‾‾/  /‾/
     /\  /  \     |  |_/  /  / /
    /  \/    \    |      |  /  ‾‾\
   /          \   |  |‾\  \ | (_) |
  / __________ \  |__|  \__\ \___/ .io

  execution: local
     output: -
     script: k6-script.js

    duration: 1m0s, iterations: -
         vus: 100,  max: 100

    done [==========================================================] 1m0s / 1m0s

    █ Public APIs

    █ Registration and authentication

    █ Private APIs

    data_received..............: 8.8 MB 146 kB/s
    data_sent..................: 4.8 MB 80 kB/s
    group_duration.............: avg=753.07ms min=239.15ms med=495ms    max=4.06s    p(90)=1.37s    p(95)=1.73s
    http_req_blocked...........: avg=12.31ms  min=362ns    med=1.52µs   max=3.47s    p(90)=1.83µs   p(95)=1.96µs
    http_req_connecting........: avg=1.95ms   min=0s       med=0s       max=779.59ms p(90)=0s       p(95)=0s
    http_req_duration..........: avg=211.11ms min=104.42ms med=183.12ms max=924.43ms p(90)=304.25ms p(95)=404.24ms
    http_req_receiving.........: avg=1ms      min=41.14µs  med=169.38µs max=130.94ms p(90)=328.31µs p(95)=2.22ms
    http_req_sending...........: avg=205.91µs min=38.06µs  med=163.76µs max=113.06ms p(90)=258.45µs p(95)=302.86µs
    http_req_tls_handshaking...: avg=8.69ms   min=0s       med=0s       max=2.43s    p(90)=0s       p(95)=0s
    http_req_waiting...........: avg=209.9ms  min=104.05ms med=182.22ms max=891.77ms p(90)=301.29ms p(95)=402.41ms
    http_reqs..................: 26363  439.382653/s
    iteration_duration.........: avg=2.28s    min=1.43s    med=2.01s    max=6.55s    p(90)=2.86s    p(95)=3.64s
    iterations.................: 2588   43.133267/s
    vus........................: 100    min=100 max=100
    vus_max....................: 100    min=100 max=100

Remarks about using the postman-to-k6 converter

1️. Should we base our load tests on the Postman converter and our Postman collections?

If you're using the converter as a way of onboarding, no. If you expect to convert your collection continuously and without doing a lot of manual edits afterwards, yes.

We recommend you to use the converter as an easy way to onboard and then rewrite your scripts to idiomatic k6 code, as we believe it to be more maintainable and less likely to degrade over time. If you convert from postman collections continuously, however, and run the script output as-is, it might make sense to keep it as is.

2. Is everything available out of the box in the converted script?

No. Since k6 uses Goja to run JavaScript, and it is not compatible with browsers' and Node.js APIs, hence there are some missing functionality. This can be fixed by importing bundled JavaScript modules. For a list of compatible libraries, please see jslib.k6.io.

3. What adjustments did you make to the script to make it work?

First, I removed the pre-script containing pm.sendRequest, because it is not supported by the converter. Then, I replaced the jsonData.hasOwnProperty syntax with the equivalent k6 syntax for extracting JSON response information: response.json("selector").

Postman API vs. k6 API

Here's a quick comparison of the Postman API versus the k6 API. To be fair, I have included features from Postman GUI application. Since k6 is scriptable from the start, you have the option to write the logic in JavaScript. Postman also supports javascript to do various tasks, but the focus is on exposing features via a richer set of GUI elements.

Feature	Postman API	k6 API
Importing external libraries	Selected libraries	Selected libraries plus bundled ones (non-browser, non-Node.js APIs)
Making requests	✅	✅
Processing response	✅	✅
Parametrization	✅	✅
REST	✅	✅
GraphQL	✅	✅
Cookies	✅	✅
Proxy	✅	✅
SSL	✅	✅
OpenAPI/Swagger	✅ (import directly)	✅ (via k6 generator in openapi-generator)
Checks	✅ (assertions)	✅ (Check API)
Groups	✅ (Collections)	✅ (Group API)
HTML parsing	✅ (needs library)	✅ (internal HTML API)
File upload	✅	✅
Test Lifecycle	✅ (only with scripts)	✅ (internal)

As you saw above, there are many features supported by each API, each to some extent. Some features needs external libraries, some are internal. Both APIs are scriptable in JavaScript, and not everything is supported by both, due to the various browser and Node.js APIs used in the libraries.

Yet, there are some features only available on k6, which is partially due to the fact that the Postman is catered for API testing or API functional testing, but k6 is focused more on API load testing.

Functional testing vs. load testing

Functional testing concerns with giving input to the system (as a black-box) via an API and examining the results, while load testing is basically doing the same thing as functional testing, but with additional load on the input to the system.

Functional testing provides input on each endpoint, and the returned results are verified in terms of correctness against a set of specifications. In turn, load testing provides a huge amount of load on each endpoint, and rather tries to aggregate the metadata returned by all the responses.

Load testing metrics for measuring performance

Concerning the measurements, the metadata will include the time it took for the request to settle and the response to return, which are measure by various metrics. For example you can measure the HTTP request duration of all requests and get their minimum, maximum, average, median, 90th and 95th percentiles.

Pass/fail a test with thresholds

You also have the option to pass/fail a test if it does/doesn't reach certain threshold(s). For example, you can specify that you want the average response time to be less than 500ms. If the average is below that, the test will fail, much like asserts in software testing.

Filter results with tags

Since you're dealing with lots of different results from different endpoints, your life would be easier if you could filter the results. Tags are supported by k6 to fulfill this requirement.

Load testing WebSocket servers

In terms of protocol implementation, WebSocket is one of the features available only in k6, compared to Postman, and you can load test your WebSocket server with it.

Conclusion

In this article I've tried to give a quick introduction to Postman, the postman-to-k6 converter and our k6 load testing tool. All these tools combined can help you turn your API requests in Postman into k6 script in order to load test your API. Many of the Postman features are supported by the postman-to-k6 tool.

Our ultimate goal is to streamline the process of onboarding you to our load testing tool, k6. In doing so, we have created a bunch of tools that can help you easily integrate load testing in your infrastructure.

Beginner's Guide to Load Testing with k6

Mostafa Moradian — Sun, 23 Jun 2019 11:01:52 +0000

Let’s start with some questions:

Have you ever thought about ways to find out if your infrastructure setup could stand under high loads of users?
Have you ever been able to run a load test without dealing with so many configurations and steep learning curve of current testing tools?
Have you ever thought about ways to script your way through testing, either for load/performance or otherwise?
Have you ever thought that load testing can be simplified and be included as part of your CI/CD process?

You are not alone in that. I remember days when I was the lead developer of a team working on developing an API to serve our ever-increasing set of Apps with many micro-services like content- and user-management, billing, analytics and the like. At that time, we used to use the latest best practices in software engineering in source control and CI/CD processes. We have set up our CI/CD process using docker and hosted GitLab and used GitLab CI to deal with CI process. After a while of testing and code-push, we have decided to go with an alpha-stage API that can answer our needs with a new App we used to develop.

After a while of development, testing and improvement, we decided to test our API under load to see if it can hold up to the promises. Since we have seen that after 200,000 users subscribing and 60,000 of them using one of our other Apps, there is an slow-down on the request/response flow to the other API, which roughly had the same setup.

So, in order to not miss the opportunity of (load) testing before customers coming in, we decided to investigate ways to load test our API. After our investigations into Locust, Apache JMeter and the like, we decided to go with Apache JMeter, which was (and still is) the tool of the trade. We thought it would be a good candidate for this purpose. It took us almost three days to be able to learn and execute simple load tests with the GUI version. We were able to produce load test from one server and analyze the results. The results were good, because it gave us a bit more insight into what we should expect from our API, in terms of number of concurrent users and our API’s response time under load.

But later we didn’t use the tool, since there was no clear way to integrate it into our CI/CD process at that time, and we didn’t have enough time to learn and use it. We wanted something more developer-friendly, more integrable to our workflow, and easier to learn. Nowadays, it has been improved very much and it integrates with CI/CD pipelines easily.

Now, I am working for a company, Load Impact, which deals with load and performance testing as their core business. They have a FOSS, easily scriptable tool (JavaScript), called k6, which can be used for load testing. They also offer a cloud service on top of the same exact tool, for provisioning and running the tests, from different regions of the world (Cloud Execution), and it finally give you a nice dashboard (Insights) with analyzed results of the tests with shiny charts. It also has good integrations with CI/CD tools and platforms.

Enough said! Let’s dive deep into what load testing is and how we can use k6 for doing load testing on our infrastructure. I will try to write more about the cloud service in the future, too.

What is Load/Performance Testing?

Performance testing is a subset of performance engineering in computer science practice which deals with quality assurance of software by putting pressure and workload, either manually or automatically, on the software to see how it behaves and to make sure it is responsive and stable enough under that load. It’s all about expectations. For example, you expect your API or website to serve 10K users simultaneously, but when you put pressure on it, it quickly becomes evident that your calculations differs from the reality and the reverse proves to be the case. Then you should analyze the weak points in your design or setup to see how you can benefit from high load.

There are many types of tests catered for different purposes in performance testing (Source: https://en.wikipedia.org/wiki/Software_performance_testing):

Load testing: basically, putting load on the system to see how it behaves.
Stress testing: load testing to find the maximum amount of load the system can handle.
Soak testing: load testing a system continuously and monitoring for memory leaks and behavior of the system.
Spike testing: load testing with sudden increase or decrease of the load.
Breakpoint testing: like stress testing, but incremental load is put on the system over time to see how it behaves.
Configuration testing: changing configuration to see how the system behaves under different configurations, under load.
Isolation testing: Isolating a fault domain and repeating the test to confirm the failure.
Internet testing: global load testing for big companies to see how to system behaves from different regions.

The most common purpose of performance testing is to find out how reliable, stable, performant and responsive the system is. Metrics like throughput and response time is a good measure of such a system.

k6: Scripting, Running and Monitoring Load Tests

k6 is a Free/Open-Source tool, written in Go, which can ingest tests written in JavaScript (ES5.1+) and turn them into requests to load test your website or API.

You can either build the k6 from source or download and install an official binary distribution. There is also an official docker image.

The not-so-beginner approach is to build k6, which obviously you should have Go installed on your machine. To do this, first download and install Go and while having $GOROOT and $GOPATH environment variables set on your shell of choice, run this command:

go get github.com/loadimpact/k6

It will automatically download and install k6 on your machine’s $GOPATH/bin directory, which you can then run it using the following script:

Once you have saved this script somewhere accessible to k6, naming it script.js or your own desired file name, you can run it with 10 virtual users (VU) and over a period of 30 seconds, as follows:

k6 run -u 10 -d 30s script.js

It basically runs k6 on your machine using 10 virtual users over the course of 30 seconds, and it checks to see if the test URL returns 200 in all tests.

This was a very short introduction to performance/load testing and the k6 tool. I will try to write more advanced load testing articles to show you how to load test your website and/or API.

This series will continue with more in-depth performance/load testing articles assuming the readers don’t have previous experience on this topic.

As always, I do really appreciate your suggestions, comments and inputs on this.