I/O Java vs nuovo I/O Java (NIO) con Linux NPTL

Question

I miei server Web utilizzano il solito I/O Java con meccanismo thread per connessione. Al giorno d'oggi, stanno inginocchiandosi con l'utente aumentato (connessione polling lunga). Tuttavia, le connessioni sono per lo più inattive. Mentre questo può essere risolto aggiungendo più server web, ho cercato di fare qualche ricerca sull'implementazione NIO.

Ho avuto un'impressione mista a riguardo. Ho letto di benchmark in cui i normali I/O con la nuova libreria NPTL in Linux superano NIO.

Qual è la vera esperienza di vita della configurazione e dell'utilizzo dell'ultimo NPTL per Linux con I/O Java? C'è un aumento delle prestazioni?

E su una grande domanda ambito:

Qual è il numero massimo di I/O e bloccando le discussioni (che configuriamo in piscina Tomcat filo) in una macchina di classe server standard (Dell con un processore quad-core) ci aspettiamo di funzionare normalmente (con la libreria NPTL di Linux?). Qual è l'impatto se il threadpool diventa veramente grande, ad esempio più di 1000 thread?

Qualsiasi riferimento e suggerimento sarà molto apprezzato.

Answer 1

Provocatorio blog di distacco, (2008) blog affermazioni di "Avoid NIO, get better throughput." Paul TYMA ~ 5000 discussioni senza alcuna difficoltà; gente che ho sentito dicono di più:

1. Con NPTL su, Sole e Blackwidow JVM 1.4.2 scalato facilmente 5000+ discussioni. Il modello di blocco era sempre più veloce del 25-35% rispetto ai selettori NIO . Molte tecniche suggerite da EmberIO erano utilizzate - utilizzando più selettori, facendo più letture (2) se il primo leggeva restituito equivalente EAGAIN in Java. Eppure non siamo riusciti a battere il semplice thread per connessione con Linux NPTL.

Penso che la chiave qui è quello di measure the overhead and performance, e fare il passaggio a non-blocking I/O solo quando si sa è necessario e possibile dimostrare un miglioramento. Lo sforzo aggiuntivo per scrivere e mantenere il codice non bloccante dovrebbe essere preso in considerazione nella tua decisione. La mia opinione è, se l'applicazione può essere espressa in modo chiaro usando I/O sincrono/bloccante, DO THAT. Se la tua applicazione è suscettibile di I/O non bloccante e non dovrai semplicemente reinventare male l'I/O di blocco nello spazio applicativo, CONSIDER trasferirsi in nio in base alle esigenze di prestazioni misurate. Sono stupito quando guardo i risultati di Google per questo motivo, in quanto poche risorse citano effettivamente numeri (recenti)!

Vedere anche Paul Tyma's presentation slides: Il vecchio modo è di nuovo nuovo. Sulla base del suo lavoro su Google, i numeri concreti suggeriscono che l'I/O con thread sincrono è abbastanza scalabile su Linux e considerano "NIO è più veloce" un mito che era vero per un po ', ma non più. Alcuni buoni commenti aggiuntivi here on Comet Daily. Egli cita la seguente (aneddotica, ancora solido legame di parametri di riferimento, ecc ...) comportare il NPTL:

Nei test, NPTL riuscirono a partire 100.000 le discussioni su una IA-32 in due secondi. In confronto, questo test sotto un kernel senza NPTL avrebbe preso circa 15 minuti

Se davvero si esegue in problemi di scalabilità, si consiglia di utilizzare tune the thread stack sizeXX:ThreadStackSize. Dal momento che menzioni Tomcat see here.

Infine, se si è vincolati e determinati a utilizzare l'I/O non bloccante, fare tutto il possibile per costruire su un existing framework by people who know what they're doing. Ho sprecato troppo del mio tempo a cercare di ottenere una soluzione I/O complessa e non bloccante giusta (per ragioni sbagliate).

Vedere anche related on SO.

Answer 2

I collegamenti si possono trovare utili:

• Handling of 100.000+ open connections
• The C10K problem
• Scalable Network Programming

Si può anche avere uno sguardo a http://nodejs.org/ che non è una JVM tecnologia, ma perfettamente gestisce migliaia di connessioni (e, se non sbaglio, utilizza NPTL dietro le quinte)

Alcuni buoni provati framework web NIO sotto JVM:

• Project Grizzly (Glassfish subproject)
• Netty
• Apache MINA

Answer 3

Mi aspetto che qualsiasi server con memoria sufficiente possa gestire decine di migliaia di thread inattivi facilmente, forse centinaia di migliaia.

Answer 4

Sajid, vedo che stai facendo Comet (polling lungo).

Quasi nessuno parla del problema dell'esecuzione del codice utente per gli eventi Comet in NIO. Gli eventi Cometa di invio thread NIO chiamano il tuo codice, se il tuo codice non è abbastanza buono stai bloccando questo thread critico e altre connessioni di Comet DEVI ASPETTARE perché il thread NIO sta facendo un lavoro simile allo scheduler di thread di SO. problema in Comet con IO perché il thread è solo per il tuo evento/attività di Comet e lo scheduler può abbandonare il tuo thread quando lo desidera (non così facile con un approccio NIO).

L'unico problema che vedo con "Cometa sincrona" (basata su IO) è il consumo di memoria delle pile di thread.