Grand nombre de connexions (Valkey et RedisOSS) - Amazon ElastiCache

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Grand nombre de connexions (Valkey et RedisOSS)

Les caches sans serveur et les nœuds individuels ElastiCache (RedisOSS) prennent en charge jusqu'à 65 000 connexions client simultanées. Toutefois, pour optimiser les performances, nous recommandons que les applications client ne fonctionnent pas constamment à ce niveau de connexions. Valkey et Redis ont OSS chacun un processus à thread unique basé sur une boucle d'événements dans laquelle les demandes des clients entrantes sont traitées de manière séquentielle. Cela signifie que le temps de réponse d’un client donné s’allonge à mesure que le nombre de clients connectés augmente.

Vous pouvez prendre les mesures suivantes pour éviter de rencontrer un goulot d'étranglement de connexion sur un serveur Valkey ou Redis : OSS

  • Effectuez des opérations de lecture à partir de réplicas en lecture. Cela peut être fait en désactivant les points de terminaison du ElastiCache lecteur en mode cluster ou en utilisant des répliques pour les lectures en mode cluster activé, y compris un cache sans serveur.

  • Répartissez le trafic d’écriture sur plusieurs nœuds primaires. Vous pouvez effectuer cette opération de deux façons. Vous pouvez utiliser un OSS cluster Valkey ou Redis multipartitionné avec un client compatible avec le mode cluster. Vous pouvez également écrire sur plusieurs nœuds primaires en mode cluster désactivé avec le partitionnement côté client. Ce processus est automatique dans un cache sans serveur.

  • Utilisez un groupe de connexions lorsqu’il est disponible dans votre bibliothèque client.

En général, la création d'une TCP connexion est une opération coûteuse en termes de calcul par rapport aux commandes Valkey ou Redis classiques. OSS Par exemple, le traitement d'une GET requêteSET/est d'un ordre de grandeur plus rapide lors de la réutilisation d'une connexion existante. L’utilisation d’un groupe de connexions client de taille limitée réduit les frais de gestion des connexions. Elle limite également le nombre de connexions entrantes simultanées provenant de l’application client.

L'exemple de code suivant PHPRedis montre qu'une nouvelle connexion est créée pour chaque nouvelle demande utilisateur :

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

Nous avons comparé ce code en boucle sur une instance Amazon Elastic Compute Cloud (AmazonEC2) connectée à un nœud Graviton2 (m6g.2xlarge) (Redis). ElastiCache OSS Nous avons placé le client et le serveur dans la même zone de disponibilité. La latence moyenne de l’ensemble de l’opération était de 2,82 millisecondes.

Lorsque nous avons mis à jour le code et utilisé des connexions persistantes et un groupe de connexions, la latence moyenne de l’ensemble de l’opération était de 0,21 milliseconde :

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

Configurations redis.ini requises :

  • redis.pconnect.pooling_enabled=1

  • redis.pconnect.connection_limit=10

Le code suivant est un exemple de groupe de connexions Redis-py :

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

Le code suivant est un exemple de groupe de connexions 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);
}