Prestandafördelarna kommer till stor del att bero på storleken på de resultatuppsättningar som du skickar, förutom nätverkets bandbredd och latens mellan databasservern och dess klienter.
Ju större resultatuppsättningar, desto större latens eller desto mindre bandbredd, desto mer sannolikt kommer du att se fördelen med komprimering.
Din maximala servicenivå är begränsad till den minsta flaskhalsen. Så du måste analysera var du befinner dig för närvarande när det gäller nätverks- och CPU-resurser.
Den mest optimerade databasservern använder 100 % av sin CPU 100 % av tiden, annars slösar du på datorresurser genom att ha en processor som sitter där och inte gör någonting. Naturligtvis vill du inte ha det på 101 %, så ditt målintervall ligger långt under 100 %. Ändå, min poäng är att om du har mycket utrymme innan du når en CPU-flaskhals, och resultatuppsättningarna är av betydande storlek, och nätverket är en faktor, slå på komprimering. CPU-cykler är billiga, särskilt oanvända (du betalar för el och kyla).
Om du betalar för bandbredd är det lätt att handla med CPU-användning mot bandbredd, och även om du inte är i närheten av att nå flaskhalsen för bandbredden är den snabbare hastigheten och högre servicenivå värt något.
Glöm inte att klienten också måste förbruka CPU-cykler för att dekomprimera data. Inte ett stort problem, men ändå en faktor. I allmänhet är dagens processorer snabbare än dagens nätverk.