DNS caching issue

Gatling (Open-Source)
1

Gatling version: 3.11.3
Gatling flavor: java kotlin [ * ] scala javascript typescript
Gatling build tool: [ * ] maven gradle sbt bundle npm

Hi Team,
We are currently working on checking the Disaster recovery of our application, where we would start the test and we will simulate the primary region to down and try to find the time in which it route to secondary region.

When we executed the test and the above steps, the requests were routed to primary region even after our application routed to the secondary region.

Then, we added the system property to set networkaddress cache ttl as zero seconds, which also didn’t help. So, we suspect that the threads are caching the address irrespective of system property when they are initialized.

Below I have added the code snippet. Please help to rectify the problem.

  System.setProperty("networkaddress.cache.ttl", "0") // 30 seconds
  System.setProperty("networkaddress.cache.negative.ttl", "0")

 val httpConfig: HttpProtocolBuilder = http.header("Content-Type", "application/json")
    .header("Cache-Control","no-cache")
    .disableWarmUp
    .disableFollowRedirect
    .disableCaching
 
  var executionSetup: SetUp = setUp(
    
 CreateApplicationToken.applicationTokenScenario.inject(atOnceUsers(PerfConfig.authUser)).andThen(
     CreateAndDelete.createEntitlementV4PreFailOverScenario2.inject(stressPeakUsers(createEntPreFailOver) during(1 seconds)),
      CreateAndDelete.getEntitlementAfterCreateV4PreFailOver.inject(stressPeakUsers(searchLicenseAfterCreateEntPreFailOver) during(1 seconds)),
      CreateAndDelete.searchLicensesAfterCreateV4PreFailOver2.inject(stressPeakUsers(searchLicenseAfterAssignLicPreFailOver) during(1 seconds)),
      CreateAndDelete.assignLicV4PreFailOverScenario2.inject(stressPeakUsers(assignLicPreFailOver).during(0 seconds)).throttle(reachRps(12) in (0 seconds),holdFor(PerfConfig.duration minutes))
            .andThen(
              CreateAndDelete.createEntitlementV4FailOverScenario2.inject(stressPeakUsers(createEntFailOver) during(1 seconds)),
              CreateAndDelete.getEntitlementAfterCreateV4FailOver.inject(stressPeakUsers(searchLicenseAfterCreateEntFailOver) during(1 seconds)),
              CreateAndDelete.searchLicensesAfterCreateV4FailOver2.inject(stressPeakUsers(searchLicenseAfterAssignLicFailOver) during(1 seconds)),
              CreateAndDelete.assignLicV4FailOverScenario2.inject(stressPeakUsers(assignLicFailOver).during(0 seconds)).throttle(reachRps(12) in (0 seconds),holdFor(PerfConfig.duration minutes))
              .andThen(
                     CreateAndDelete.createEntitlementV4PostFailOverScenario2.inject(stressPeakUsers(createEntPostFailOver) during(1 seconds)),
                     CreateAndDelete.getEntitlementAfterCreateV4PostFailOver.inject(stressPeakUsers(searchLicenseAfterCreateEntPostFailOver) during(1 seconds)),
                     CreateAndDelete.assignLicV4PostFailOverScenario2.inject(stressPeakUsers(assignLicPostFailOver).during(0 seconds)).throttle(reachRps(12) in (0 seconds),holdFor(PerfConfig.duration minutes)),
                     CreateAndDelete.searchLicensesAfterCreateV4PostFailOver2.inject(stressPeakUsers(searchLicenseAfterAssignLicPostFailOver) during(1 seconds))
                )
            )
        )
).maxDuration(PerfConfig.duration minutes)

[ * ] I made sure I’ve update my Gatling version to the latest release
[ * ] I read the guidelines and how to ask a question topics.
[ * ] I provided a SSCCE (or at least, all information to help the community understand my topic)
[ * ] I copied output I observe, and explain what I think should be.

2

Hi there,

As we suspect the threads are caching the IP address and we are using “stressPeakUsers” as the injection profile for our DR testing. The threads may alive for the whole duration with that cache IP address.

So, we tried using “constantUsersPerSec” to justify the above point and we were able to see the traffic routes to secondary region successfully.

We would like to know is there any functionality available to have threads make DNS lookup for each request while using “stressPeakUsers” injection profile.

3

Hi,
I don’t think we have any extra level of DNS cache that could trigger the behavior you’re describing. What we do is cache the order in order to emulate DNS round-robin across virtual users: gatling/gatling-http/src/main/scala/io/gatling/http/resolver/ShufflingNameResolver.scala at main · gatling/gatling · GitHub. But we’re always calling the underlying resolver.

What I suspect instead is that you’re not closing the connections to the original servers so they keep on being fetched from the connection pools.

Anyway, that’s not something we can help with without you providing a reproducer so we can investigate autonomously, or contracting if you want us to investigate in your environment.

Regards

4

Hi @slandelle , thanks for the information.
I will check with the script to close the connections to solve this problem.

Thanks

5

I’m not sure trying to tweak the tests is the right thing to do.
If your test properly describes the way the real world clients behave, it means Gatling is merely the messenger and shows what would happen to them. In this case, what needs to get fixed is your application, not your test.