Fun facts¶

Here’s some nice things about Rungutan that will help you build the most complex workflows you could imagine with little to no stress:

Concurrent regions list¶

We currently support the following regions that can be specified within the test_region property of a test or template:

["ap-northeast-1", "ap-northeast-2",
"ap-southeast-1", "ap-southeast-2",
"eu-central-1",
"eu-west-1", "eu-west-2", "eu-west-3",
"us-east-1", "us-east-2",
"us-west-1", "us-west-2",
"ca-central-1",
"ap-south-1",
"sa-east-1"]

These values emulate the following regions:

ap-northeast-1 = Tokyo
ap-northeast-2 = Seoul
ap-southeast-1 = Singapore
ap-southeast-2 = Sydney
eu-central-1 = Frankfurt
eu-west-1 = Ireland
eu-west-2 = London
eu-west-3 = Paris
us-east-1 = North Virginia
us-east-2 = Ohio
us-west-1 = North California
us-west-2 = Oregon
ca-central-1 = Canada (Central)
ap-south-1 = Mumbai
sa-east-1 = Sao Paulo

They are all offered through the Amazon Web Services cloud and are all currently working as expected.

The more concurrent regions you specify, the more concurrent global connections to your API that you simulate!

Overall mode¶

Because we support load testing in multiple regions, we also offer you an “OVERALL” of your Load Testing results across all regions.

However, because the results need to first be computed before that is available, while the test is running, we can only show you “REGIONAL” results, for each region in particular of course.

In short:

If test is in RUNNING_LOADTEST status, you can click on Change Region button to see results for each and every region

When the test moved to FINISHED status, you can click on Change Region button and select the overall option to see the overall results across all regions and threads

Always check the labels on the top of page to get an understanding of the Status, Sharing and Region of the currently viewed results page.

Threads per region logic¶

Since we offer the possibility of running concurrent tests from multiple regions, it means that you should also have the possibility of setting up HOW many IPs are used in each region.

Therefore, the property threads_per_region defined the number of public IPs which are used to send connections to your API !

Simulate 5 million requests per minute¶

-> “You guys bragged about being able to simuate millions of requests per minute. How can I do that myself?”

Reply:

Well, it’s easy :)

Let’s do some math:

test_regions * 100 threads_per_region  = 1500 threads (with a public IP each) that are running the tests

threads * 25 virtual users in each per second = 90.000 requests per second

000 * 60 seconds = 5.400.000 requests simulated in just 1 minute

PS: This scenario works as long as your platform is actually able to sustain at least 280.000 requests/second…

JSON payload¶

We only accept string for payload, but that shouldn’t stop you from actually sending a JSON value like this (by simply escaping it):

{
  "method": "POST",
  "path": "/my/post/path",
  "data": " {\"this\": \"payload\", \"is\": \"escaped\"} ",
  "headers": {
    "content-type": "application/json"
  }
}

Extract nested json response¶

If your response JSON looks like this for instance:

{
  "a":"b",
  "c": {
    "d": "e",
    "f": {
      "g": "h"
    }
  }
}

And you would like to fetch the value of [“c”][“f”][“g”] then your extract key would look like this:

{
    "extract": [
        {
            "parameter_name": "extracted_key",
            "location": "body",
            "key": "c.f.g",
            "default_value": "something"
        }
    ]
}

Extract nested json response with array¶

If your response JSON looks like this for instance:

{
  "a":"b",
  "c": {
    "d": "e",
    "f": {
      "g": "h"
    },
    "i": [
      {
        "j": "k"
      },
      {
        "l": "m"
      }
    ]
  }
}

And you would like to fetch the 1st value of [“c”][“i”] and specifically the “j” property in it, then you would write your extract key like this:

{
    "extract": [
        {
            "parameter_name": "extracted_key",
            "location": "body",
            "key": "c.i.0.j",
            "default_value": "something_else"
        }
    ]
}

Extract specific key with json path expression from response body¶

If your response JSON looks like this for instance:

{
    "test_id": "ad837abd-15d4-47ce-a344-01a3323bdd09",
    "test_name": "test name"
}

And you would like to fetch the property “test_id” from the response, then your extract key would look like this:

{
    "extract": [
        {
            "parameter_name": "extracted_key",
            "location": "body",
            "json_path_expression": "$.test_id",
            "default_value": "some_id_here_as_default"
        }
    ]
}

Extract random key from collection of items with json path expression from response body¶

If your response JSON looks like this for instance:

{
    "employees": [
        {
          "id": 1,
          "name": "Pankaj",
          "salary": "10000"
        },
        {
          "name": "David",
          "salary": "5000",
          "id": 2
        }
    ]
}

And you would like to fetch a random value the property “id” from the response, then your extract key would look like this:

{
    "extract": [
        {
            "parameter_name": "extracted_key",
            "location": "body",
            "json_path_expression": "employees[*].id",
            "default_value": "some_id_here_as_default"
        }
    ]
}

Extract using regex¶

As you may have noticed already, our code, besides offering support for manipulating JSON responses in the body, also allows you to extract information using regex from non-Json response bodies.

This makes it perfect for any structured/non-structured response as long as you have a method of “searching” for the value that you need.

In case your regex returns multiple search results, only the first occurence of it gets taken into consideration.

For instance, if you’re using Laravel and your Login page looks like this:

[...]
<meta name="csrf-token" content="ThtvqtcSr44SSSbypUP7Ho31hQSffRXm00LcI30l"/>

[...]

Then you’d be able to extract that CSRF token as so:

{
    "extract": [
        {
            "parameter_name": "csrftoken",
            "location": "body",
            "element_with_regex": "meta name=\"csrf-token\" content=\"(.+?)\"",
            "default_value": "some_default_token"
        }
    ]
}

Easy, right?

Why blank steps :(¶

If you look closely, the steps that show “blank data”, aren’t just any steps, they are the “last” steps of your workflow.

The reason (usually) why they show up blank is simple -> API calls in PREVIOUS steps resulted in an error (response code NOT between 200 and 399).

Our platform, in order to protect YOUR own infrastructure, does NOT continue with a future step of the workflow, if the previous one has failed.

So in short, all you would have to do is click on the “CSV Failures” button, check the failures for the previous steps and fix them :)

Hoep that helps! If not, well, you know how to reach us :)

Fun facts¶

Concurrent regions list¶

Overall mode¶

Threads per region logic¶

Simulate 5 million requests per minute¶

JSON payload¶

Extract nested json response¶

Extract nested json response with array¶

Extract specific key with json path expression from response body¶

Extract random key from collection of items with json path expression from response body¶

Extract using regex¶

Sharing secret stuff¶

Why blank steps :(¶