Korzyści w zakresie wydajności będą w dużej mierze zależne od rozmiaru wysyłanych zestawów wyników, oprócz przepustowości sieci i opóźnień między serwerem bazy danych a jego klientami.
Im większe zestawy wyników, tym większe opóźnienie lub mniejsza przepustowość, tym większe prawdopodobieństwo, że dostrzeżesz korzyści z kompresji.
Twój maksymalny poziom usług ogranicza się do najmniejszego wąskiego gardła. Musisz więc przeanalizować, gdzie aktualnie się znajdujesz, jeśli chodzi o zasoby sieciowe i procesora.
Najbardziej zoptymalizowany serwer bazy danych wykorzystuje 100% swojego procesora przez 100% czasu, w przeciwnym razie marnujesz zasoby obliczeniowe, mając procesor, który tam siedzi i nic nie robi. Oczywiście nie chcesz, aby wynosiła 101%, więc twój docelowy zakres jest znacznie poniżej 100%. Jednak chodzi mi o to, że jeśli masz dużo miejsca, zanim dojdziesz do wąskiego gardła procesora, a zestawy wyników są znaczne, a sieć jest czynnikiem, to włącz kompresję. Cykle procesora są tanie, zwłaszcza te nieużywane (płacisz za prąd i chłodzenie).
Jeśli płacisz za przepustowość, zamiana wykorzystania procesora na przepustowość jest łatwo uzasadniona, a nawet jeśli nie jesteś blisko wąskiego gardła przepustowości, ta szybsza prędkość i wyższy poziom usług są coś warte.
Nie zapominaj, że klient musi również zużywać cykle procesora na dekompresję danych. Nie jest to poważny problem, ale nadal czynnik. Ogólnie rzecz biorąc, dzisiejsze procesory są szybsze niż dzisiejsze sieci.
