Question about enable_detailed_recording option

Support
, , ,
1

Hello team,

I have conducted load tests on Tyk 5.2.5, and I detected a decrease in capacity with timeouts between Tyk and Redis beyond 1500 requests per second.

After several searches, it seems that enabling the “enable_detailed_recording” option is the root cause of this contention.

I have found a magical option on other gateways that allowed tracing the requests and responses in case of an HTTP error (different from 2xx). Is this option not possible on Tyk?

Thank you for your response.

2

@Alexandre_Wintrebert Could you test with v5.2.6? There were some performance improvements added to that version that could help.

Enabling detained recording can take a hit on the performance of your Redis since it would store all the data from the request and response. That data can be significant depending on the input and output. We recommend never enabling it unless necessary.

As far as I know, there isn’t an option to help with this from the Gateway. The gateway sends the analytics data temporarily to Redis before it is purged permanently to persistent storage via pump.

However, the pump filters can purge analytics data based on some specified conditions.

"filters":{
  "skip_response_codes":[
      401,
      500
  ]
}

For the gateway, you can use some of our documented optimisation techniques to help with performance from this side. Also, consider enabling detailed recording per API or key rather than globally.

TYK_GW_ANALYTICSCONFIG_POOLSIZE=5
TYK_GW_ANALYTICSCONFIG_ENABLEMULTIPLEANALYTICSKEYS=true
TYK_GW_ANALYTICSCONFIG_SERIALIZERTYPE=msgpack # msgpack, and protobuf
TYK_GW_ENABLESEPERATEANALYTICSSTORE=true
3

Hello,
I confirm that I have upgraded to version 5.2.6 and my load tests are significantly better. I even managed to reach 6000 calls/s on three gateways.

Thank you for your response.
For the pump part, I will implement this. See you soon.