News KrakenD CE v2.12 released

Enterprise Documentation

You are viewing a previous version of KrakenD Enterprise Edition (v2.8), go to the latest version

Document updated on Dec 12, 2024

Redis connection pools for stateful functionality

KrakenD’s architecture allows developers to define all Redis connection pools in a single redis namespace. Each pool is identified by a unique name (make sure of it), which is then referenced by the components requiring a connection. This approach eliminates the need to repeatedly specify Redis connection details in every component configuration.

For example, a Redis connection pool configuration might look like this:

{
  "$schema": "https://www.krakend.io/schema/v2.8/krakend.json",
  "version": 3,
  "extra_config": {
    "redis": {
      "connection_pools": [
        {
          "name": "shared_redis_pool",
          "address": "192.168.1.45:6379"
        },
        {
          "name": "ratelimit_counters",
          "address": "192.168.1.52:6379",
          "database": 2
        }
      ]
    }
  }
}

The block above creates two Redis connection pools named shared_redis_pool and ratelimit_counters. These names are how other components (like the Redis-based service rate limit) can select which one to use.

Different pools can connect to different redis instances, or to the same instances but with different parameters. The configuration allows you to declare extra options to fine tune how the pool should behave: secure connection, retries, etc ..

Best practices to select those parameters will depend on the components that will use the pool.

Configuration of Redis connection pools

The full list of options is explained below.

Fields of Redis configuration
* required fields

connection_pools array
Defines all the connetion pools available to Redis functionality. The different components requiring Redis will access the pool based on its name
Each item of connection_pools accepts the following properties:
address * string
The Redis host where you want to connect using the format host:port.
Example: "shared.redis.example.com"
client_name string
You can set how this connection shows in Redis when listing all the connections CONN LIST
Example: "krakend_pool"
conn_max_idle_time string
The maximum amount of time a connection may be idle. Should be less than server’s timeout.Expired connections may be closed lazily before reuse. If <= 0, connections are not closed due to a connection’s idle time.
Specify units using ns (nanoseconds), us or µs (microseconds), ms (milliseconds), s (seconds), m (minutes), or h (hours).
Defaults to "30m"
conn_max_life_time string
The maximum amount of time a connection may be reused. When the attribute is not declared, the connection does not expire
Specify units using ns (nanoseconds), us or µs (microseconds), ms (milliseconds), s (seconds), m (minutes), or h (hours).
db integer
The database number to select after connecting
Defaults to 0
dial_timeout string
Dial timeout for establishing new connections
Specify units using ns (nanoseconds), us or µs (microseconds), ms (milliseconds), s (seconds), m (minutes), or h (hours).
Defaults to "5s"
max_active_conns integer
Maximum number of connections allocated by the pool at a given time. When zero, there is no limit on the number of connections in the pool.
Defaults to 0
max_idle_conns integer
Maximum number of idle connections. The value 0 means connections not closed
Defaults to 0
max_retries integer
The number of times you want to retry a Redis command using a different connection from the pool, applying a random delay between min_retry_backoff and max_retry_backoff. Use -1 to never retry (it might not be a good idea)
Defaults to 3
max_retry_backoff string
Every retry is executed increasing randomly starting at the min_retry_backoff until the max_retry_backoff is reached. This is the longest possible time.
Specify units using ns (nanoseconds), us or µs (microseconds), ms (milliseconds), s (seconds), m (minutes), or h (hours).
Defaults to "512ms"
min_idle_conns integer
Minimum number of idle connections which is useful when establishing new connection is slow. 0 means connections are not closed.
Defaults to 0
min_retry_backoff string
Every retry is executed increasing randomly starting at the min_retry_backoff until the max_retry_backoff is reached. This is the shortest possible time.
Specify units using ns (nanoseconds), us or µs (microseconds), ms (milliseconds), s (seconds), m (minutes), or h (hours).
Defaults to "8ms"
name * string
The connection pool name. This is an arbitrary name used to reference this connection in other parts of the configuration needing Redis.
Examples: "shared_instance" , "Redis_for_ratelimit"
opentelemetry object
The OpenTelemetry configuration establishing how to report Redis connection activity
disable_metrics boolean
Disables any metrics of this Redis pool
Defaults to false
disable_traces boolean
Disables any traces of this Redis pool
Defaults to false
traces_static_attributes array
Static attributes you want to pass for traces.
password string
Sets the password to connect to Redis.
pool_size integer
The pool size defines the number of concurrent Redis commands that can be executed by this Redis pool. Take into account that this only saves the connection time to the server, but, Redis will still be a non-concurrent service. When 0 it maps to its default 10
Defaults to 10
pool_timeout string
Amount of time the client waits for a connection if all connections are busy.
Specify units using ns (nanoseconds), us or µs (microseconds), ms (milliseconds), s (seconds), m (minutes), or h (hours).
tls object
An object with any client TLS configuration to this connection
user_name string
The username to connect to Redis
Schema: https://www.krakend.io/schema/v2.8/redis.json

Best practices for Redis connection pool management

While the library sets defaults for all the options (except the address and the name), you might want to tweak several of the parameters available. Generally speaking, the additional parameters are not needed. A few things to have in mind when configuring pools:

  • Set realistic timeouts and limits: Use appropriate values for timeouts and connection limits to prevent overloading Redis and ensure smooth operations during peak traffic.
  • Don’t disable monitoring: Let OpenTelemetry to track metrics and traces, helping you identify and address potential bottlenecks. Add the Redis Grafana dashboard for greater visibility.
  • Align pools with functionality: Use separate pools for different functionalities to isolate workloads and ensure predictable performance.

Unresolved issues?

The documentation is only a piece of the help you can get! Whether you are looking for Open Source or Enterprise support, see more support channels that can help you.

See all support channels