Durante lo sviluppo e l’implementazione di un nuovo software ad alto numero di utenti concorrenti, molte volte non teniamo conto dell’effetto che la concorrenza di accesso può causare sui nostri sistemi. Così può capitare che il nostro programma via web testato fino a 500-600 utenti, cominci a rallentare se non a bloccarsi per un eventuale picco di utilizzo. Ovviamente tutta esperienza che si mette da parte… l’unica cosa da tenere presente sono i limiti fisici che un sistema può avere, diciamo un minimo e un massimo all’interno del quale il nostro software può spaziare.
Partiamo con qualche considerazione riguardo l’accesso ai dischi… che per velocità di accesso sono il collo di bottiglia dei nostri super-server. Partiamo dalle operazione di scrittura:
- Scrivere su disco è un’operazione estremamente dispendiosa!!
- Scrivere su disco è un’operazione transazionale
- Ogni accesso al disco significa il posizionamento della testina su una traccia (seeks)
- Come regola una testina impiega 10ms per posizionarsi su una traccia (seeks)
- Se la matematica non è un’opinione in 1s posso fare al massimo 100 seeks
- Ovviamente tutte le considerazioni sopra dipendono dalla grandezza e dalla varietà del vostro dato, nonché dalle ottimizzazioni che i sistemi storage moderni, tramite l’uso di cache ad alta velocità,mettono in atto effettuando operazioni di batch put e batch get
Parliamo delle letture da disco:
- Le operazioni di lettura non sono pesanti
- Una volta letto il dato dal disco è facilmente cachabile in qualche livello applicativo (es. cache del filesystem)
- Una volta messo in cache le letture successive acquisiscono il dato dalla memoria (estremamente più veloce)
- Come regola per leggere 1Mb dalla memoria si impiega 250 microsecondi
- Se la matematica non è un’opinione in 1 secondo posso leggere fino a 4gb direttamente dalla memoria
A questo punto arriviamo ai dati… partendo dal processore del server (es. da cui sto leggendo la posta) per arrivare direttamente nella scheda di rete del mio pc di casa:
- L1 cache reference 0,5 nanosecondi
- Branch mispredict 5 nanosecondi
- Mutex Lock/Unlock 7 nanosecondi
- Main memory reference 100 nanosecondi
- Comprimere 1K con zip 10.000 nanosecondi
- Inviare 2K su una rete a 1gbps 20.000 nanosecondi
- Leggere 1Mb dalla memoria 250.000 nanosecondi
- Facciamo fare un bel giro all’interno del nostro datacenter (roundtrip) 500.000 nanosecondi
- Posizioniamo la testina del nostro disco 10.000.000 nanosecondi
- Leggiamo 1Mb dalla rete 10.000.000 nanosecondi
- Leggiamo 1Mb da disco 30.000.000 nanosecondi
- Mandiamo un pacchetto per esempio Italia–>California–>Italia 150.000.000 nanosecondi
Praticamente da questi semplici numeri possiamo identificare dei limiti ben precisi per i nostri sistemi, ma anche alcune Rule of thumb:
- Le scritture su disco sono 40 volte più lente rispetto alle letture
- Una grande base dati condivisa affetta da un gran numero di scritture da più server, può annientare le performance degli stessi in quanto le scritture essendo transazionali finirebbero per diventare serializzate, nonché si creerebbero problematiche di lock contention sui dati
- Bisogna sforzarsi di pensare e mettere in atto un sistema in grado di poter reggere agevolmente eventuali picchi nelle operazioni di scrittura
- Bisogna ottimizzare i processi di scrittura in modo tale da renderli più paralleli possibili
