Prestatievoordelen zullen grotendeels afhankelijk zijn van de grootte van de resultatensets die u verzendt, naast de netwerkbandbreedte en latentie tussen de databaseserver en zijn clients.
Hoe groter de resultatensets, hoe groter de latentie of hoe minder bandbreedte, hoe groter de kans dat u het voordeel van compressie zult zien.
Uw maximale serviceniveau is beperkt tot het kleinste knelpunt. U moet dus analyseren waar u zich momenteel bevindt met betrekking tot netwerk- en CPU-bronnen.
De meest geoptimaliseerde databaseserver gebruikt 100% van zijn CPU 100% van de tijd, anders verspil je computerbronnen door een processor te hebben die daar zit en niets doet. Natuurlijk wil je het niet op 101%, dus je doelbereik ligt ver onder de 100%. Maar mijn punt is dat als je veel hoofdruimte hebt voordat je een CPU-bottleneck bereikt, en de resultatensets een aanzienlijke omvang hebben, en het netwerk een factor is, compressie dan moet worden ingeschakeld. CPU-cycli zijn goedkoop, vooral ongebruikte (je betaalt wel voor elektriciteit en koeling).
Als je betaalt voor bandbreedte, is het gemakkelijk te rechtvaardigen CPU-gebruik te ruilen voor bandbreedte, en zelfs als je niet in de buurt komt van het bandbreedteprobleem, is die hogere snelheid en het hogere serviceniveau iets waard.
Vergeet niet dat de client ook CPU-cycli moet gebruiken om de gegevens te decomprimeren. Geen groot probleem, maar toch een factor. Over het algemeen zijn de huidige CPU's sneller dan de huidige netwerken.