The slowness of database operations from time to time can infuriate users and developers. So why do we always encounter these errors? In fact, we do not observe very simply, the problem occurs before our eyes and we do not take it into account, thinking that it has always been instantaneous. But momentary problems can create serious problems for us in the future.
For example, most e-commerce applications experience constant crashes during Black-Friday times. In fact, the reasons for this can be determined in advance. We ignore it. We do not go over the problems, we can no longer explain these crashes to users.
The problems ahead are actually very clear; scaling, read-write speed, data security, backup, wrong machine selection are our main reasons. We can identify and prevent all of these database problems with load tests.
With load testing, we will essentially be free of manual workload. Normally, instead of looking at these problems manually, we will be able to quickly see what kind of results on which database or what kind of performance problem there is with a load test.
Power of the k6
Let’s take a look at how we can do this with the k6.
k6 offers this feature to us with the extensions it supports. In order to use k6 extensions, you need to do a small operation first.
- Firstly we install xk6.
go install go.k6.io/xk6/cmd/xk6@latest
- Then we build for the extension we will use xk6.
xk6 build master --with github.com/imiric/xk6-sql
Yes, now we can write our script and run our tests. First, we import xk6-sql. Then, with the sql.open command, we first add the sql type we will use, then the db name.
Supported relational databases;
- Microsoft SQL Server
Now it’s time to prepare a nice k6 life cycle, the better you prepare your script, the closer you can get to mistakes. We will use the Setup and Teardown methods that I mentioned in my previous article. This part will be very useful for us in database tests. Because before we create a load, we need to perform table and insert operations, and when our test is finished, we need to delete them. It will be more beneficial for us to work with healthier data every time.
We set up our setup and teardown structure as you can see below. Differently, we run our queries with the ‘exec’ command.
Next came the part where we will run our actual test. We want to do our load with data querying. If you wish, you can also do it with insert using a random generator. As you can see below, we perform our query with the sql.query command.
Finally, we set this script to 200 vus (virtual user) and set it to run for 5 seconds and run our command.
k6 run db.js --duration 5s --vus 200
Yes, as you can see, we have obtained a result as follows. This shows us that the system can support 200 users in 6.3 ms per transaction.
The rest is in your hands, remember that you have no limits with the k6 🤓