Scrittura a bassa latenza Java [chiuso]

Oltre ai commenti di Martijn aggiungerei:

1. Riscalda la tua JVM. Bytecode inizia inizia a essere interpretato per Hotspot e quindi viene compilato sul server dopo 10K osservazioni . La compilazione a livelli può essere una buona interruzione.

2. Il caricamento in classe è un processo sequenziale che coinvolge l'I / O su disco. Rendere sicuro che tutte le classi per i tuoi principali flussi di transazione siano caricate in anticipo e che non vengono mai sfrattati dalla generazione di perm.

3. Segui il " Principio del Single Writer " per evitare la contesa e le implicazioni dell'effetto di accodamento della Legge di Little, oltre allo studio La legge di Amdhal per ciò che può essere parallelo e ne vale la pena.

4. Modella il tuo dominio aziendale e assicurati che tutti i tuoi algoritmi siano O (1) o almeno O (log n). Questa è probabilmente la più grande causa di problemi di prestazioni nella mia esperienza. Assicurati di avere prestazioni prova per coprire i casi principali.

5. La bassa latenza in Java non è solo limitata a Java. Devi capire l'intero stack su cui è in esecuzione il codice. Questo sarà coinvolgere l'ottimizzazione del sistema operativo, selezionare l'hardware appropriato, i sistemi di ottimizzazione software e driver di dispositivo per quell'hardware.

6. Sii realistico. Se hai bisogno di bassa latenza non eseguire su un hypervisor. Assicurati di avere core sufficienti per tutti i thread che devono essere nello stato eseguibile.

7. Le mancanze della cache sono il costo maggiore per le prestazioni. Usa algoritmi che sono compatibili con la cache e stabiliscono affinità con i core del processore con taskset o numactl per una JVM o JNI per singoli thread.

8. Considera una JVM alternativa come Zing di Azul con una pausa-meno Garbage Collector.

9. La cosa più importante è coinvolgere qualcuno con esperienza. Questo sarà risparmiarti così tanto tempo a lungo termine. Spina senza vergogna: -)

Real-time e bassa latenza sono soggetti nettamente separati sebbene spesso correlati. In tempo reale è più prevedibile che veloce. Nella mia esperienza, le JVM in tempo reale, anche quelle soft real-time, sono più lente delle normali JVM.

Ci sono un sacco di cose da sapere di si. Sono a Creta al momento con accesso alla rete limitato, quindi questo sarà (abbastanza) breve. Inoltre, non sono un esperto di bassa latenza, ma molti dei miei colleghi ne interpretano uno nella vita reale: -).

1. Devi apprezzare Mechanical Sympathy (termine coniato da Martin Thompson ). In altre parole, è necessario capire cosa sta facendo l'hardware sottostante. Sapendo come le CPU caricano le linee della cache, quale sia la loro larghezza di banda di lettura / scrittura, la velocità della memoria principale e molto, molto di più è molto importante. Perché? Perché è necessario ragionare su come il codice sorgente Java influisce su OperatingSystem / Hardware tramite la JVM di runtime. Ad esempio, è il modo in cui le variabili di campo sono disposte nel codice sorgente causando lo sfratto della linea di cache (ti costa ~ 150 cicli di clock), hmmm ...: -).

2. In genere vuoi algoritmi e I / O senza blocco. Anche l'applicazione concorrente più ben progettata (che utilizza i blocchi) è a rischio di blocco, il blocco in bassa latenza è generalmente negativo: -).

3. Comprendi l'assegnazione degli oggetti e la raccolta dei dati inutili. Questo è un argomento importante, ma in pratica si vogliono evitare le pause GC (spesso causate dalla natura di Stop the World di varie collezioni GC). I collezionisti specializzati di GC come il collezionista Azul in molti casi possono risolvere questo problema per te, ma per la maggior parte delle persone hanno bisogno di capire come regolare i GC Sun / Oracle (CMS, G1, ecc.).

4. Il JIT di Hotspot è davvero fantastico. Scopri le sue ottimizzazioni, ma in generale tutte le buone tecniche OO (incapsulamento, piccoli metodi, quanti più dati immutabili possibili) permetteranno all'ottimizzazione di JIT, offrendoti i livelli di prestazioni che il codice C / C ++ ben fornito ti offre.

5. Architettura generale del sistema. Siate consapevoli della rete, del modo in cui le macchine sono co-locate, se siete connessi allo scambio tramite fibra ecc.

6. Sii consapevole dell'impatto della registrazione. logging binary o l'output codificato che puoi analizzare offline è probabilmente una buona idea.

Nel complesso consiglio vivamente di seguire il corso Java Performance Tuning di Kirk Pepperdine [Disclaimer: insegno questo corso da solo, quindi sono di parte ]. Otterrai una buona copertura dei vari aspetti della JVM e del suo impatto su O / S e hardware sottostanti.

PS: proverò a riesaminarlo più tardi ea riordinarlo.