I vantaggi in termini di prestazioni dipenderanno in gran parte dalla dimensione dei set di risultati che si inviano, oltre alla larghezza di banda e alla latenza della rete tra il server del database e i client.
Più grandi sono i set di risultati, maggiore è la latenza o minore larghezza di banda, più è probabile che si noterà il vantaggio della compressione.
Il livello massimo del servizio è limitato al collo di bottiglia più piccolo. Quindi, è necessario analizzare dove si sta attualmente per quanto riguarda le risorse della rete e della CPU.
Il server di database più ottimizzato utilizza il 100% della sua CPU il 100% delle volte, altrimenti si sprecano risorse di calcolo avendo un processore che non sta facendo nulla. Certo, non lo vuoi al 101%, quindi il tuo range di destinazione è ben al di sotto del 100%. Tuttavia, il mio punto è che se hai un sacco di headroom prima di raggiungere un collo di bottiglia della CPU, e i set di risultati sono di dimensioni significative, e la rete è un fattore, quindi attiva la compressione. I cicli della CPU sono economici, soprattutto quelli inutilizzati (paghi l'elettricità e il raffreddamento).
Se si paga per la larghezza di banda, l'utilizzo della CPU di negoziazione per la larghezza di banda è facilmente giustificata, e anche se non sei da nessuna parte vicino a raggiungere il collo di bottiglia della larghezza di banda, che la velocità più veloce, e più alto livello di servizio, vale qualcosa.
Non dimenticare che il client deve anche utilizzare i cicli della CPU per decomprimere i dati. Non è un grosso problema, ma ancora un fattore. In generale, le CPU di oggi sono più veloci delle reti odierne.
fonte
2010-03-24 14:42:14
Velocità di rete e velocità di elaborazione si susseguono sempre. La tua configurazione ha una maggiore velocità di rete o una maggiore velocità di elaborazione? Se si dispone di una maggiore velocità di rete, salvare sull'elaborazione non comprimendo. Se si dispone di una maggiore velocità di elaborazione, salvare in rete comprimendo. – Pacerier