Dans les coulisses, SE.Redis fait un peu de travail pour essayer d'éviter la fragmentation des paquets, il n'est donc pas surprenant que ce soit assez similaire dans votre cas. La principale différence entre le traitement par lots et le pipelining plat est :
- un lot ne sera jamais entrelacé avec des opérations concurrentes sur le même multiplexeur (bien qu'il puisse être entrelacé au niveau du serveur ; pour éviter cela, vous devez utiliser un
multi/exectransaction ou un script Lua) - un lot évitera toujours le risque de paquets sous-dimensionnés, car il connaît toutes les données à l'avance
- mais en même temps, l'ensemble du lot doit être terminé avant que quoi que ce soit puisse être envoyé, cela nécessite donc plus de mise en mémoire tampon et peut introduire artificiellement de la latence
Dans la plupart des cas, vous ferez mieux en évitant le traitement par lots, puisque SE.Redis réalise la plupart de ce qu'il fait automatiquement lorsque vous ajoutez simplement du travail.
Comme note finale; si vous voulez éviter les frais généraux locaux, une dernière approche pourrait être :
redisDB.SetAdd(string.Format(keyFormat, row.Field<int>("Id")),
row.Field<int>("Value"), flags: CommandFlags.FireAndForget);
Cela envoie tout sur le fil, sans attendre les réponses ni allouer une Task incomplète s pour représenter les valeurs futures. Vous voudrez peut-être faire quelque chose comme un Ping à la fin sans fire-and-forget, pour vérifier que le serveur vous parle toujours. Notez que l'utilisation de fire-and-forget signifie que vous ne remarquerez aucune erreur de serveur signalée.
