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!

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 10 million users

-> “You guys bragged about being able to simuate 10 million users. How can I do that myself?”

Reply:

Well, it’s easy :)

Let’s do some math:

15 test_regions * 25 threads_per_region  = 375 threads (with a public IP each) that are running the tests

375 threads_per_region * 250 num_users * 1 req/second = 95.750 simulated users in total across those 375 threads each second

95.750 * 2 req/second = 191.500 simulated users if you set it up so that there are at least 2 requests done per second

191.500 * 60 seconds = 11.490.000 users simulated in just 1 minute

Usual question -> “How do you set it up so that there are at least 2 requests / second ?”

Reply:

By tweaking the values for min_wait and max_wait. The default values of “1000/1000” literally mean that exactly 1 request is done every 1.000 miliseconds.

But if you would set it up as 500/500, it would mean that 1 request is done every 500 milisseconds, which means that there will be 2 every 1.000 milisecond -> 2 req/second

Sample:

"num_clients": 250,
"hatch_rate": 250,
"threads_per_region": 25,
"test_region": [
    "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"
],
"min_wait": 400,
"max_wait": 600

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"
        }
    ]
}

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"
        }
    ]
}

Sharing secret stuff

First, define the API key as a SENSITIVE vault key in Vault, with any name that you find fit, such as: my_api_key, and then use it in your workflow like this:

If your response JSON looks like this for instance:

"workflow": [
    {
        "path": "/v1/api/tests/list",
        "method": "POST",
        "data": "{\"team_id\":\"rungutan\"}",
        "headers": {
            "X-Api-Key": "${vault.my_api_key}",
            "content-type": "application/json"
        },
        "extract": [
            {
                "parameter_name": "testId",
                "location": "body",
                "key": "Tests.0.test_id"
            }
        ]
    }
]

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 :)