Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The Redis profile has been verified on Redis Labs Enterprise Cluster (RLEC).

Note!

To ensure aggregation functions correctly with the Redis profile, you must have the Enterprise edition of Usage Engine.

Configuration

To create a new Redis profile, click the New Configuration button in the upper left part of the  Desktop window, and then select Redis Profile from the menu.

...

Connectivity Tab

The Connectivity tab  tab is displayed by default.

The following settings are available in the Redis profile:

Setting

Description

Host

Enter the IP address/DNS name of the cluster.

Port

Enter the listening port of the cluster.

Password

Enter the password of the cluster.

Operation Timeout (ms)

Enter the number of milliseconds after which Redis "CRUD" operations, i e create, read, update, and delete, should timeout. Setting a lower value than the default 1000 ms may have a positive impact on throughput performance. However, if the value is set too low, indicated by a large number of operation timeouts  errors in the EC logs, a lower throughput can be expected.

Retry Interval Time (ms)

Enter the time interval, in milliseconds, that you want to wait before trying to read the cluster configuration again after a failed attempt. The default value is 5.

Max Number of Retries

Enter the maximum number of retries. The default value is 30.

Advanced Tab

The Advanced tab contains additional properties that you can use for performance tuning.

...

Connections in use are periodically and unconditionally reset. Use mz.redis.connection.time.limit to control the time between the reset intervals. In case of topology changes the connections are reset after a delay. Use mz.redis.topology.limit.time to set the length of this delay.

...

Note!

When using global variables, the normal locking used by Redis (optimistic locking) can cause the code to become unpredictable, due to the built-in multi-threading of APL. One way to solve this is to use pessimistic locking, which prevents aggregation timeout threads from executing concurrently. In this case global variables are thread-safe. When using pessimistic locking the timeout becomes slower so if no global variables are used, optimistic locking may be preferred.

Use the properties mz.redis.agg.lock.method and mz.redis.agg.locktime for pessimistic locking of aggregation timeouts. The lock algorithm is implemented according to https://redis.io/commands/setnx.