Les avantages en termes de performances dépendront en grande partie de la taille des ensembles de résultats que vous envoyez, ainsi que de la bande passante du réseau et de la latence entre le serveur de base de données et ses clients.
Plus les ensembles de résultats sont volumineux, plus la latence est importante ou moins la bande passante est importante, plus vous constaterez les avantages de la compression.
Votre niveau de service maximum est limité au plus petit goulot d'étranglement. Vous devez donc analyser où vous en êtes actuellement en ce qui concerne les ressources réseau et CPU.
Le serveur de base de données le plus optimisé utilise 100 % de son processeur 100 % du temps, sinon vous gaspillez des ressources informatiques en ayant un processeur qui ne fait rien. Bien sûr, vous ne le voulez pas à 101 %, votre fourchette cible est donc bien inférieure à 100 %. Pourtant, mon point est que si vous avez beaucoup de marge avant d'atteindre un goulot d'étranglement du processeur, et que les ensembles de résultats sont d'une taille importante, et que le réseau est un facteur, activez la compression. Les cycles CPU sont bon marché, en particulier ceux qui ne sont pas utilisés (vous payez pour l'électricité et le refroidissement).
Si vous payez pour la bande passante, il est facilement justifié d'échanger l'utilisation du processeur contre de la bande passante, et même si vous n'êtes pas près d'atteindre le goulot d'étranglement de la bande passante, cette vitesse plus rapide et ce niveau de service plus élevé valent quelque chose.
N'oubliez pas que le client doit également dépenser des cycles CPU pour décompresser les données. Pas un problème majeur, mais toujours un facteur. En général, les processeurs d'aujourd'hui sont plus rapides que les réseaux d'aujourd'hui.
