I vantaggi in termini di prestazioni dipenderanno in gran parte dalle dimensioni dei set di risultati che stai inviando, oltre alla larghezza di banda della rete e alla latenza tra il server di database ei suoi client.
Maggiore è il set di risultati, maggiore è la latenza o minore larghezza di banda, più è probabile che vedrai i vantaggi della compressione.
Il livello massimo di servizio è limitato al minimo collo di bottiglia. Quindi, devi analizzare dove ti trovi attualmente per quanto riguarda le risorse di rete e CPU.
Il server di database più ottimizzato utilizza il 100% della sua CPU il 100% delle volte, altrimenti stai sprecando risorse di elaborazione avendo un processore seduto lì che non fa nulla. Ovviamente, non lo vuoi al 101%, quindi il tuo intervallo target è ben al di sotto del 100%. Tuttavia, il mio punto è che se hai molto margine prima di raggiungere un collo di bottiglia della CPU e i set di risultati hanno dimensioni significative e la rete è un fattore, allora attiva la compressione. I cicli della CPU sono economici, soprattutto quelli inutilizzati (l'elettricità e il raffreddamento si pagano).
Se paghi per la larghezza di banda, scambiare l'utilizzo della CPU con la larghezza di banda è facilmente giustificato e, anche se non sei affatto vicino a raggiungere il collo di bottiglia della larghezza di banda, quella velocità più elevata e un livello di servizio più elevato valgono qualcosa.
Non dimenticare che il client deve anche spendere cicli della CPU per decomprimere i dati. Non è un grosso problema, ma è comunque un fattore. In generale, le CPU di oggi sono più veloci delle reti odierne.
