Ipotesi chiave
I presupposti fondamentali nella progettazione di Chronicle sono
- bassa latenza è il tuo problema, non la velocità. I dati provengono in micro-esplosioni che si desidera gestire più rapidamente possibile lungo prima della prossima micro-esplosione di attività.
- Non è possibile mettere in pausa uno scambio / produttore se si è occupati. (O la pausa l'utente finale non è un'opzione)
- le informazioni sono di alto valore, registrando ogni evento con tempismo dettagliato è prezioso. Registrazione di tutti gli eventi è la chiave per comprendere micro-esplosioni.
- Si vuole essere in grado di esaminare qualsiasi evento che si è verificato in passato.
Bassa latenza è essenziale
Il problema chiave Chronicle è il design per aiutarti a risolvere è bassa latenza coerente. Si presuppone che se la latenza è abbastanza basso, non si ha un problema con un throughput.Molti sistemi web based sono progettati per il throughput e fintanto che la latenza non è visibile agli utenti finali, la latenza non è un problema. Per i morbidi sistemi in tempo reale, è necessario bassa latenza maggior parte del tempo e un caso peggiore di latenza modesto, molto più velocemente di un essere umano può vedere.
Non si può fermare il mondo
Un altro assunto fondamentale è che il controllo di flusso non è un'opzione. Se si esegue lento, non si può dire per lo scambio e tutti i suoi utenti, aspetta un secondo, mentre io raggiungo. Ciò significa che il produttore può mai essere rallentato da un consumatore.
Rallentare il produttore è effettivamente la stessa come l'aggiunta di latenza, ma questa latenza è facile da nascondere. Se si attende fino a quando il produttore timestamp un evento, questo può farvi latenze guardare meglio. Se si vuole una misura più realistica è che si dovrebbe usare il timestamp caso avrebbe dovuto essere trasmessa da un produttore che non è in ritardo.
È necessario registrare ogni cosa per la riproduzione
Riproduzione può essere utile per testare l'applicazione in una serie di condizioni. ad esempio, è possibile modificare l'applicazione e vedere non solo che si comporti correttamente, ma si comporta in modo tempestivo. Per l'analisi quantitativa, avranno bisogno di un insieme di dati per ottimizzare le proprie strategie.
Replay una vecchia evento in tempo reale.
Invece di prendere una copia di evento che si potrebbe desiderare di fare riferimento a tardi, si può invece ricordare che è indice e si può riprodurre l'evento più tardi su richiesta. Ciò consente di risparmiare memoria nel mucchio, o just-in-caso copie dei dati.
Micro-burst sono fondamentali per comprendere il sistema.
Le prestazioni di alcuni sistemi sono caratterizzati in termini di transazioni al giorno. Ciò implica che se non sono state completate le operazioni per le prime 23 ore e tutti completati nell'ultima ora, si sarebbe comunque effettuare questo numero di transazioni al giorno. Spesso le transazioni al giorno è citato perché è un numero più alto, ma nel mio caso avendo tutto il giorno per appianare il carico di lavoro suona come un lusso.
Alcuni sistemi potrebbero essere caratterizzati in termini di numero di transazioni al secondo.Ciò può implicare che tali operazioni possono avviare e completare in un secondo, ma non sempre. Se si dispone di 1000 transazioni e uno viene in ogni milli-secondi, si ottiene un tempo di risposta pari. Quello che trovo più interessante è il numero di transazioni nel secondo più trafficato di una giornata. Questo vi dà un'indicazione della portata del sistema dovrebbe essere in grado di gestire.
Esaminare micro esplosioni
Si consideri un sistema che ottiene 30 eventi tutti nelle stesse 100 micro-secondi e queste esplosioni sono 100 milli-secondi di distanza. Questo potrebbe apparire come una (30 / 0.1) 300 transazioni al secondo che suona relativamente facile se tutto quello che dobbiamo fare è di tenere il passo, ma se vogliamo la risposta il più rapidamente possibile, a breve termine / rendimento scoppio è 30 a 100 micro-secondi o 300.000 eventi al secondo.
In altre parole, per gestire micro-esplosioni più velocemente possibile, avrete bisogno di un sistema in grado di gestire throughput molti ordini di grandezza superiore a quello che ci si aspetta più di pochi secondi o minuti o un giorno. Idealmente, la velocità dei vostri sistemi sarà 100x il secondo più trafficato della giornata. Questo è necessario per gestire le più trafficato 10 milli-secondi in ogni secondo senza rallentare il trattamento di queste esplosioni di dati.
Come Cronaca migliora la gestione di micro-esplosioni
Basso tasso di immondizia
Ridurre al minimo spazzatura è la chiave per evitare pause GC. Per utilizzare la cache L1 e L2 in modo efficiente, è necessario mantenere i tassi di spazzatura molto basso. Se non si utilizza questi la cache in modo efficiente la vostra applicazione può essere 2-5x più lento.
L'immondizia da Chronicle è sufficiente che si può elaborare un milione di eventi senza jstat rilevazione si è creato alcun immondizia basso. jstat visualizza solo multipli di 4 KB, e solo in caso di nuove TLAB viene allocato. Chronicle fa creare spazzatura, ma è estremamente basso. vale a dire pochi oggetti per milione di processi eventi.
Una volta che si fanno le pause GC gestibile, o inesistente, si inizia a vedere altre fonti di ritardo nel vostro sistema. Porta via i massi e si inizia a vedere le rocce. Porta via le rocce e si inizia a vedere i ciottoli.
Supporta un modello tutto in scrittura.
E 'risaputo che se si lascia il livello DEBUG si accede, può rallentare l'applicazione in modo drammatico. C'è una tensione tra la registrazione di tutto ciò che si potrebbe desiderare di sapere più tardi, e l'impatto sulla vostra applicazione.
Chronicle è progettato per essere abbastanza veloce che si può registrare tutto. Se si sostituisce code e le connessioni IPC nel vostro sistema, è possibile migliorare le prestazioni e si ottiene "registrare tutto" gratis, o meglio ancora.
Essere in grado di registrare tutto ciò significa che è possibile aggiungere intervalli di traccia in ogni fase del vostro sistema e quindi monitorare il sistema, ma anche forare i peggiori 1% dei ritardi nel sistema. Questo non è qualcosa che si può fare con un profiler che ti dà medie.
Con cronaca è possibile rispondere a domande come; quali parti del sistema erano responsabili per le lenti 20 eventi per un giorno?
Chronicle è minima interazione con il sistema operativo.
Le chiamate di sistema sono lenti, e se si può evitare di chiamare il sistema operativo, è possibile risparmiare notevoli quantità di latenza.
Ad esempio, se si invia un messaggio tramite TCP su loopback, questo può aggiungere un micro-secondi di latenza 10 tra la scrittura e la lettura dei dati. È possibile scrivere una cronaca, che è una scrittura semplice alla memoria, e leggere di cronaca, che è anche una lettura da memoria con una latenza di 0,2 micro-secondi. (E come ho detto prima, si ottiene la persistenza pure)
Non c'è bisogno di preoccuparsi di rimanere a corto di heap.
Un problema comune con code illimitate e questo utilizza una quantità a tempo indeterminato di heap.
Cronaca risolve questo non utilizzando l'heap per memorizzare i dati, ma utilizzando file mappati in memoria. Questa migliorare l'utilizzo della memoria, rendendo i dati più compatta, ma significa anche un GB JVM 1 può trasmettere 1 TB di dati su un giorno senza preoccuparsi del cumulo o la quantità di memoria principale che avete. In questo caso, una coda illimitata diventa più facile da gestire.
Conclusione
Essendo costruito su ipotesi diverse, Cronaca risolve i problemi di altre soluzioni evitano, come la necessità di un controllo di flusso oi messaggi che consumano (eliminazione dei messaggi elaborati).
Chronicle è progettato per essere utilizzato l'hardware più efficiente in modo non hai bisogno di una nuvola di dire 30 server per gestire circa un milione di eventi al secondo (come un certo numero di soluzioni cloud basato rivendicazione), si può fare questo tasso di eventi con uno sviluppatore portatile.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.