High reported response time values

Sorry, I didn’t mean that.
Here’s the generated report from one of the runs.

  1. Are you performing any custom code that would perform blocking IO, typically in an exec(function) to call an external service, write on disk, etc?
  2. Could you enable asyncNameResolution and try again Gatling - HTTP Protocol?
  1. yes external SimulatorDataProvider internally using Redis cache
scenario(transactionData.flowName)
      .feed(transactionData.LoginFeeder)
      .exec(session => {
        transactionLog.infoMessage(s"Starting ${transactionData.flowName}",session)
        var dataProviderClient: SimulatorDataProviderClient = null
        try {
          dataProviderClient = new SimulatorDataProviderClient(MOBILE, EnvironmentProperties.DataProviderUrl)
          dataProviderClient.setTimeout(EnvironmentProperties.DataProviderTimeout)
          transactionLog.initMessage(s"dataProviderClient created ${EnvironmentProperties.DataProviderUrl}",session)
        }
        catch {
          case e: Throwable => transactionLog.errorMessage(s"Error creating dataProvider client ${transactionData.flowName} ${e.toString}",session)
        }
        session.set("dataProviderClient", dataProviderClient)

      }).exitHereIfFailed
.....
........
.tryMax(3) {
  pause("#{delay}")
  .exec {
    session => {
    …
    //this can call to the utility internally using Redis cache  or  Mysql DB depending on the data requested
        val (inputValue, updatedFlowState, valueSQLStack, valueDPMap) = getValueFromSource(transactionData.flowJson, flowState, actionName, inputObject, session) 
    …
    }
  }
}

.pause("#{delay}")

.tryMax(3,"attemptCount") {

  .exec(http(transactionData.flowName + "_S#{actionIndex}_#{actionName}")
      .post("#{requestUrl}")
      .body(StringBody(session => session("flowState").as[String]))
      .headers(requestHeaders)
      .check(status.optional.saveAs("http_status"))
      .check(status.is(200),
        status.transform(status => 200.equals(status)).saveAs("isOkResponse"))
     ...
...

    }.optional.saveAs("flowState1")))

}

  1. will try
setUp(scn:_*).protocols(http.asyncNameResolution().baseUrl(EnvironmentProperties.host)).maxDuration(EnvironmentProperties.runDuration)

100% sure that’s your issue. You’re performing blocking IO in Gatling’s thread pool, causing massive freezes when this external system slows down.

1 Like

I see. I can’t call a function to get data from redis even in a separate exec block.

The function is required to get the inut data for that particular step.

Users just sends request to redis and all the logic is to run on the redis container only. the response is sent back to gatling container and then the user proceeds to another exec block with application http call.

.exec {
    session => {
    …
    //this can call to the utility internally using Redis cache  or  Mysql DB depending on the data requested
        val (inputValue, updatedFlowState, valueSQLStack, valueDPMap) = getValueFromSource(transactionData.flowJson, flowState, actionName, inputObject, session) 
    …
    }
.exec(actual_request)
  }

I will do a run for the flows which have no redis dependency to confirm that. if the issue is resolved will find a way to get source data from the external function.

Couple of flows have no db calls; only read from response. As far as I remember even these flows had high RT %le values. I’ll do a run once again and update.

Thanks for pointing this out.

Did a run without datafetch call and the report is all good now.
The load was lesser and ran the test for just an hour. but for now this seems to be the root cause.

Hi, I have a related query. Is my understanding wrong here?
Max(All Requests) = Max(Max(all groups))

Never mind :slight_smile:
I’ve put tryMax inside the sub groups hence the values were getting added again.

      .group("G01_Main") {
        group("API_#{requestUrl}") {
            tryMax(3, "attemptCount") {

After removing all the external Java http calls, finally the values are all normal now.
Thank you!

Max(All Requests) = Max(Max(all groups))

Wrong. Gatling - Reports

If your scenario contains groups, this panel becomes a tree : each group is a non leaf node, and each request is a descendant leaf of a group. Group timings are by default the cumulated response times of all elements inside the group. Group duration can be displayed instead of group cumulated response time by editing the gatling.conf file.

1 Like