What’s load testing and why does it matter?

Load testing is a crucial course of for any database or knowledge service, together with Rockset. By doing load testing, we intention to evaluate the system’s habits underneath each regular and peak circumstances. This course of helps in evaluating essential metrics like Queries Per Second (QPS), concurrency, and question latency. Understanding these metrics is crucial for sizing your compute sources accurately, and guaranteeing that they’ll deal with the anticipated load. This, in flip, helps in reaching Service Stage Agreements (SLAs) and ensures a clean, uninterrupted consumer expertise. That is particularly essential for customer-facing use instances, the place finish customers anticipate a quick consumer expertise. Load testing is typically additionally referred to as efficiency or stress testing.

“53% of visits are prone to be deserted if pages take longer than 3 seconds to load” — Google

Rockset compute sources (referred to as digital situations or VIs) come in several sizes, starting from Small to 16XL, and every measurement has a predefined variety of vCPUs and reminiscence out there. Selecting an acceptable measurement depends upon your question complexity, dataset measurement and selectivity of your queries, variety of queries which might be anticipated to run concurrently and goal question efficiency latency. Moreover, in case your VI can be used for ingestion, you need to think about sources wanted to deal with ingestion and indexing in parallel to question execution. Fortunately, we provide two options that may assist with this:

• Auto-scaling – with this characteristic, Rockset will routinely scale the VI up and down relying on the present load. That is essential you probably have some variability in your load and/or use your VI to do each ingestion and querying.
• Compute-compute separation – that is helpful as a result of you possibly can create VIs which might be devoted solely for working queries and this ensures that all the out there sources are geared in direction of executing these queries effectively. This implies you possibly can isolate queries from ingest or isolate totally different apps on totally different VIs to make sure scalability and efficiency.

We advocate doing load testing on at the very least two digital situations – with ingestion working on the primary VI and on a separate question VI. This helps with deciding on a single or multi-VI structure.

Load testing helps us determine the bounds of the chosen VI for our explicit use case and helps us choose an acceptable VI measurement to deal with our desired load.

Instruments for load testing

In the case of load testing instruments, a number of standard choices are JMeter, k6, Gatling and Locust. Every of those instruments has its strengths and weaknesses:

• JMeter: A flexible and user-friendly software with a GUI, ideally suited for numerous sorts of load testing, however could be resource-intensive.
• k6: Optimized for top efficiency and cloud environments, utilizing JavaScript for scripting, appropriate for builders and CI/CD workflows.
• Gatling: Excessive-performance software utilizing Scala, greatest for advanced, superior scripting eventualities.
• Locust: Python-based, providing simplicity and fast script growth, nice for simple testing wants.

Every software provides a novel set of options, and the selection depends upon the precise necessities of the load check being carried out. Whichever software you utilize, you should definitely learn by way of the documentation and perceive the way it works and the way it measures the latencies/response occasions. One other good tip is to not combine and match instruments in your testing – if you’re load testing a use case with JMeter, keep it up to get reproducible and reliable outcomes which you could share along with your workforce or stakeholders.

Rockset has a REST API that can be utilized to execute queries, and all instruments listed above can be utilized to load check REST API endpoints. For this weblog, I’ll concentrate on load testing Rockset with Locust, however I’ll present some helpful sources for JMeter, k6 and Gatling as properly.

Establishing Rockset and Locust for load testing

Let’s say we now have a pattern SQL question that we wish to check and our knowledge is ingested into Rockset. The very first thing we often do is convert that question right into a Question Lambda – this makes it very straightforward to check that SQL question as a REST endpoint. It may be parametrized and the SQL could be versioned and saved in a single place, as a substitute of going backwards and forwards and altering your load testing scripts each time you should change one thing within the question.

Step 1 – Determine the question you wish to load check

In our situation, we wish to discover the most well-liked product on our webshop for a selected day. That is what our SQL question appears to be like like (notice that :date is a parameter which we are able to provide when executing the question):

--top product for a selected day
SELECT
    s.Date,
    MAX_BY(p.ProductName, s.Rely) AS ProductName,
    MAX(s.Rely) AS NumberOfClicks
FROM
    "Demo-Ecommerce".ProductStatsAlias s
    INNER JOIN "Demo-Ecommerce".ProductsAlias p ON s.ProductID = CAST(p._id AS INT)
WHERE
    s.Date = :date
GROUP BY
    1
ORDER BY
    1 DESC;

Step 2 – Save your question as a Question Lambda

We’ll save this question as a question lambda referred to as LoadTestQueryLambda which is able to then be out there as a REST endpoint:

https://api.usw2a1.rockset.com/v1/orgs/self/ws/sandbox/lambdas/LoadTestQueryLambda/tags/newest

curl --request POST 
--url https://api.usw2a1.rockset.com/v1/orgs/self/ws/sandbox/lambdas/LoadTestQueryLambda/tags/newest 
-H "Authorization: ApiKey $ROCKSET_APIKEY" 
-H 'Content material-Sort: utility/json' 
  -d '{
    "parameters": [
      {
        "name": "days",
        "type": "int",
        "value": "1"
      }
    ],
      "virtual_instance_id": "<your digital occasion ID>"
  }' 
 | python -m json.software

Step 3 – Generate your API key

Now we have to generate an API key, which we’ll use as a approach for our Locust script to authenticate itself to Rockset and run the check. You possibly can create an API key simply by way of our console or by way of the API.

Step 4 – Create a digital occasion for load testing

Subsequent, we’d like the ID of the digital occasion we wish to load check. In our situation, we wish to run a load check in opposition to a Rockset digital occasion that’s devoted solely to querying. We spin up a further Medium digital occasion for this:

As soon as the VI is created, we are able to get its ID from the console:

Step 5 – Set up Locust

Subsequent, we’ll set up and arrange Locust. You are able to do this in your native machine or a devoted occasion (assume EC2 in AWS).

$ pip set up locust

Step 6 – Create your Locust check script

As soon as that’s completed, we’ll create a Python script for the Locust load check (notice that it expects a ROCKSET_APIKEY surroundings variable to be set which is our API key from step 3).

We are able to use the script beneath as a template:

import os
from locust import HttpUser, process, tag
from random import randrange

class query_runner(HttpUser):
    ROCKSET_APIKEY = os.getenv('ROCKSET_APIKEY') # API secret's an surroundings variable

    header = {"authorization": "ApiKey " + ROCKSET_APIKEY}

    def on_start(self):
        self.headers = {
            "Authorization": "ApiKey " + self.ROCKSET_APIKEY,
            "Content material-Sort": "utility/json"
        }
        self.shopper.headers = self.headers
        self.host="https://api.usw2a1.rockset.com/v1/orgs/self" # exchange this along with your area's URI
        self.shopper.base_url = self.host
        self.vi_id = '<your digital occasion ID>' # exchange this along with your VI ID

    @tag('LoadTestQueryLambda')
    @process(1)
    def LoadTestQueryLambda(self):
        # utilizing default params for now
        knowledge = {
            "virtual_instance_id": self.vi_id
        }
        target_service="/ws/sandbox/lambdas/LoadTestQueryLambda/tags/newest" # exchange this along with your question lambda
        consequence = self.shopper.put up(
            target_service,
            json=knowledge
        )

Step 7 – Run the load check

As soon as we set the API key surroundings variable, we are able to run the Locust surroundings:

export ROCKSET_APIKEY=<your api key>
locust -f my_locust_load_test.py --host https://api.usw2a1.rockset.com/v1/orgs/self

And navigate to: http://localhost:8089 the place we are able to begin our Locust load check:

Let’s discover what occurs as soon as we hit the Begin swarming button:

1. Initialization of simulated customers: Locust begins creating digital customers (as much as the quantity you specified) on the price you outlined (the spawn price). These customers are situations of the consumer class outlined in your Locust script. In our case, we’re beginning with a single consumer however we’ll then manually enhance it to five and 10 customers, after which go down to five and 1 once more.
2. Activity execution: Every digital consumer begins executing the duties outlined within the script. In Locust, duties are usually HTTP requests, however they are often any Python code. The duties are picked randomly or primarily based on the weights assigned to them (if any). We’ve got only one question that we’re executing (our LoadTestQueryLambda).
3. Efficiency metrics assortment: Because the digital customers carry out duties, Locust collects and calculates efficiency metrics. These metrics embody the variety of requests made, the variety of requests per second, response occasions, and the variety of failures.
4. Actual-time statistics replace: The Locust internet interface updates in real-time, displaying these statistics. This consists of the variety of customers presently swarming, the request price, failure price, and response occasions.
5. Take a look at scalability: Locust will proceed to spawn customers till it reaches the full quantity specified. It ensures the load is elevated step by step as per the required spawn price, permitting you to watch how the system efficiency adjustments because the load will increase. You possibly can see this within the graph beneath the place the variety of customers begins to develop to five and 10 after which go down once more.
6. Consumer habits simulation: Digital customers will look forward to a random time between duties, as outlined by the wait_time within the script. This simulates extra lifelike consumer habits. We didn’t do that in our case however you are able to do this and extra superior issues in Locust like customized load shapes, and so forth.
7. Steady check execution: The check will proceed working till you resolve to cease it, or till it reaches a predefined period if you happen to’ve set one.
8. Useful resource utilization: Throughout this course of, Locust makes use of your machine’s sources to simulate the customers and make requests. It is essential to notice that the efficiency of the Locust check may rely upon the sources of the machine it is working on.

Let’s now interpret the outcomes we’re seeing.

Deciphering and validating load testing outcomes

Deciphering outcomes from a Locust run includes understanding key metrics and what they point out concerning the efficiency of the system underneath check. Listed here are a few of the major metrics offered by Locust and the right way to interpret them:

• Variety of customers: The full variety of simulated customers at any given level within the check. This helps you perceive the load stage in your system. You possibly can correlate system efficiency with the variety of customers to find out at what level efficiency degrades.
• Requests per second (RPS): The variety of requests (queries) made to your system per second. A better RPS signifies a better load. Examine this with response occasions and error charges to evaluate if the system can deal with concurrency and excessive site visitors easily.
• Response time: Often displayed as common, median, and percentile (e.g., ninetieth and 99th percentile) response occasions. You’ll probably take a look at median and the 90/99 percentile as this offers you the expertise for “most” customers – solely 10 or 1 p.c may have worse expertise.
• Failure price: The proportion or variety of requests that resulted in an error. A excessive failure price signifies issues with the system underneath check. It is essential to research the character of those errors.

Under you possibly can see the full RPS and response occasions we achieved underneath totally different hundreds for our load check, going from a single consumer to 10 customers after which down once more.

Our RPS went as much as about 20 whereas sustaining median question latency beneath 300 milliseconds and P99 of 700 milliseconds.

We are able to now correlate these knowledge factors with the out there digital occasion metrics in Rockset. Under, you possibly can see how the digital occasion handles the load by way of CPU, reminiscence and question latency. There’s a correlation between variety of customers from Locust and the peaks we see on the VI utilization graphs. You may also see the question latency beginning to rise and see the concurrency (requests or queries per second) go up. The CPU is beneath 75% on the height and reminiscence utilization appears to be like steady. We additionally don’t see any vital queueing occurring in Rockset.

Other than viewing these metrics within the Rockset console or by way of our metrics endpoint, you can too interpret and analyze the precise SQL queries that had been working, what was their particular person efficiency, queue time, and so forth. To do that, we should first allow question logs after which we are able to do issues like this to determine our median run and queue occasions:

SELECT
    query_sql,
    COUNT(*) as depend,
    ARRAY_SORT(ARRAY_AGG(runtime_ms)) [(COUNT(*) + 1) / 2] as median_runtime,
    ARRAY_SORT(ARRAY_AGG(queued_time_ms)) [(COUNT(*) + 1) / 2] as median_queue_time
FROM
    commons."QueryLogs"
WHERE
    vi_id = '<your digital occasion ID>'
    AND _event_time > TIMESTAMP '2023-11-24 09:40:00'
GROUP BY
    query_sql

We are able to repeat this load check on the primary VI as properly, to see how the system performs ingestion and runs queries underneath load. The method can be the identical, we’d simply use a distinct VI identifier in our Locust script in Step 6.

Conclusion

In abstract, load testing is a crucial a part of guaranteeing the reliability and efficiency of any database resolution, together with Rockset. By choosing the appropriate load testing software and organising Rockset appropriately for load testing, you possibly can acquire precious insights into how your system will carry out underneath numerous circumstances.

Locust is straightforward sufficient to get began with rapidly, however as a result of Rockset has REST API help for executing queries and question lambdas, it’s straightforward to hook up any load testing software.

Keep in mind, the purpose of load testing is not only to determine the utmost load your system can deal with, but in addition to know the way it behaves underneath totally different stress ranges and to make sure that it meets the required efficiency requirements.

Fast load testing ideas earlier than we finish the weblog:

• All the time load check your system earlier than going to manufacturing
• Use question lambdas in Rockset to simply parametrize, version-control and expose your queries as REST endpoints
• Use compute-compute separation to carry out load testing on a digital occasion devoted for queries, in addition to in your major (ingestion) VI
• Allow question logs in Rockset to maintain statistics of executed queries
• Analyze the outcomes you’re getting and evaluate them in opposition to your SLAs – if you happen to want higher efficiency, there are a number of methods on the right way to sort out this, and we’ll undergo these in a future weblog.

Have enjoyable testing 💪

Helpful sources

Listed here are some helpful sources for JMeter, Gatling and k6. The method is similar to what we’re doing with Locust: you should have an API key and authenticate in opposition to Rockset after which hit the question lambda REST endpoint for a selected digital occasion.

• JMeter internet assessments: [https://jmeter.apache.org/usermanual/build-web-test-plan.html]
• Gatling pattern on our RocksetLabs GitHub web page: [https://github.com/rocksetlabs/gatling/tree/main]
• k6 API load testing: [https://k6.io/docs/testing-guides/api-load-testing/]