2010-03-24 18 views
17

Ho imparato che MySQL può comprimere la comunicazione tra server e client.Quando dovrei usare il protocollo compresso MySQL?

compressione viene utilizzato se il client e server di compressione supporto zlib, e il client richiede di compressione.

(da MySQL Forge Wiki)

I pro più evidenti ei contro sono

  • pro: Ridotta dimensione del payload
  • contro: Aumento del tempo di calcolo

Quindi, viene compressa protocollo qualcosa che dovrei abilitare ogni volta che posso permettermi server con specifiche adeguate? Ci sono altri fattori che dovrei considerare?

+0

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

risposta

17

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.

4

Nella mia esperienza, la maggior parte dei server mysql si trovano sullo stesso server del server web, quindi la larghezza di banda della rete non è un problema.

Direi che, a meno che i server db e le app/web non siano geograficamente separati (cioè non sullo stesso server o rete), ci sarà ben poco vantaggio nell'abilitare la compressione.

+2

Totalmente applicabile nella maggior parte degli scenari di applicazioni Web. Ma l'idea che il server di database sia vicino (in termini di rete) non è vero per molte implementazioni client-server. – Elemental

1

Dalla mia esperienza è particolarmente utile se ci si connette a un server MySQL esterno che risiede completamente in un'altra rete (o addirittura in un paese). Il vantaggio derivante dall'abilitazione della compressione in questi casi dipende dalla dimensione dei dati che si stanno trasferendo e dalla distanza tra il client e il server. Come sempre, dovresti testare la tua applicazione con e senza compressione, e quindi prendere una decisione che è più vantaggiosa per la tua situazione. Non c'è una risposta assoluta per questa domanda.

Non vedo molto il punto di attivazione della compressione se si esegue una query su un server MySQL sulla stessa macchina o sulla stessa rete.

9

Lo so che è tardi, ma se potrei condividere questo:

Si scopre che 100 Mbit collegamento (con il tempo di 1,4 ms di andata e ritorno) è non abbastanza veloce ... Con compressione, tempo di indicizzazione totale ridotto a 87 secondi da 127 sec. Questo è quasi 1.5 volte migliorato nel tempo di esecuzione totale. MySQL Il miglioramento del tempo di interrogazione è ancora maggiore. D'altra parte 1 Gbit link era abbastanza veloce; e il tempo di esecuzione totale era 1,2 volte peggio con la compressione .

Se il database e il client non si trovano sulla stessa macchina, su rete 100 Mbit e più lenti, abilitare la compressione!

Tuttavia, la decisione finale potrebbe anche dipendere dal bilanciamento tra il costo dei cicli della CPU (compressione/decompressione) e l'utilizzo di Bandwith (più dati sul filo).

+1

Grandi informazioni! sarebbe importante considerare che questo potrebbe non essere applicabile a tutte le situazioni. Se i tuoi dati sono facilmente comprimibili (molti dati duplicati all'interno di ogni query) o le prestazioni della tua CPU sono molto più alte, potresti voler eseguire i tuoi test. –

Problemi correlati