Gran cantidad de conexiones (Valkey y OSS Redis) - Amazon ElastiCache

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Gran cantidad de conexiones (Valkey y OSS Redis)

Las cachés sin servidor y los nodos individuales ElastiCache (RedisOSS) admiten hasta 65 000 conexiones de clientes simultáneas. Sin embargo, para optimizar el rendimiento, recomendamos que las aplicaciones cliente no funcionen constantemente con ese volumen de conexiones. Tanto Valkey como Redis OSS tienen un proceso de subproceso único basado en un bucle de eventos en el que las solicitudes de los clientes entrantes se gestionan de forma secuencial. Esto significa que el tiempo de respuesta de un cliente determinado se hace más largo a medida que aumenta el número de clientes conectados.

Puede tomar las siguientes medidas para evitar que se produzca un cuello de botella en la conexión de un servidor Valkey o Redis: OSS

  • Llevar a cabo las operaciones de lectura a partir de réplicas de lectura. Esto se puede hacer utilizando los puntos finales del ElastiCache lector en el modo de clúster desactivado o mediante réplicas para las lecturas en el modo de clúster activado, incluida una caché sin servidor.

  • Distribuir el tráfico de escritura entre varios nodos principales. Puede hacerlo de dos formas. Puede utilizar un clúster de Valkey o Redis con varios fragmentos con un cliente compatible con el modo de OSS clúster. También puede escribir en varios nodos principales con el modo de clúster deshabilitado y con partición en el lado del cliente. Esto se hace automáticamente en una memoria caché sin servidor.

  • Usar un grupo de conexiones cuando esté disponible en la biblioteca de su cliente.

En general, crear una TCP conexión es una operación costosa desde el punto de vista computacional en comparación con los comandos típicos de Valkey o Redis. OSS Por ejemplo, gestionar una GET solicitudSET/es un orden de magnitud más rápido cuando se reutiliza una conexión existente. El uso de un grupo de conexiones de clientes con un tamaño finito reduce la sobrecarga en la administración de conexiones. También limita el número de conexiones entrantes simultáneas desde la aplicación cliente.

El siguiente ejemplo de código PHPRedis muestra que se crea una nueva conexión para cada nueva solicitud de usuario:

$redis = new Redis();
if ($redis->connect($HOST, $PORT) != TRUE) {
	//ERROR: connection failed
	return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;

Hemos comparado este código en un bucle en una instancia de Amazon Elastic Compute Cloud (AmazonEC2) conectada a un nodo Graviton2 (m6g.2xlarge) (Redis). ElastiCache OSS Hemos colocado el cliente y el servidor dentro de la misma zona de disponibilidad. La latencia media de toda la operación fue de 2,82 milisegundos.

Cuando actualizamos el código y utilizamos conexiones persistentes y un grupo de conexiones, la latencia media de toda la operación fue de 0,21 milisegundos:

$redis = new Redis();
if ($redis->pconnect($HOST, $PORT) != TRUE) {
	// ERROR: connection failed
	return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;

Configuraciones de redis.ini obligatorias:

  • redis.pconnect.pooling_enabled=1

  • redis.pconnect.connection_limit=10

El siguiente código es un ejemplo de un grupo de conexiones Redis-py:

conn = Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10))
conn.set(key, value)

El siguiente código es un ejemplo de un grupo de conexiones Lettuce:

RedisClient client = RedisClient.create(RedisURI.create(HOST, PORT));
GenericObjectPool<StatefulRedisConnection> pool = ConnectionPoolSupport.createGenericObjectPool(() -> client.connect(), new GenericObjectPoolConfig());
pool.setMaxTotal(10); // Configure max connections to 10
try (StatefulRedisConnection connection = pool.borrowObject()) {
	RedisCommands syncCommands = connection.sync();
	syncCommands.set(key, value);
}