2013-05-16 14 views
7

Mi chiedo se node.js sia valido per l'applicazione lato server che non comunica effettivamente con il browser, o la comunicazione tra browser è solo un'ulteriore parte di tutta l'app utilizzata piuttosto per la gestione.Node.js per la comunicazione da server a server

L'idea è semplice:

  1. Server riceve elevata quantità di traffico UDP con brevi messaggi contenenti i dati degli utenti da un altro server.

  2. Per ogni messaggio l'app esegue la ricerca del DB e filtra i messaggi con userid che non sono nella whitelist.

  3. I messaggi filtrati vengono elaborati, il che comporta un altro aggiornamento del DB o l'invio di dati a un altro server.

è tale caso, un buon scenario per imparare node.js, o forse non v'è alcun beneficio da esso confronto ad es Java EE?

+3

Penso che questo sia un eccellente programma per gli animali domestici da scrivere (a seconda del database), controllare http://nodejs.org/api/dgram.html per la documentazione –

+1

Il nodo funziona meglio se la maggior parte del tempo viene speso in IO (db, disco, rete, ecc.). Mentre la tua app sta eseguendo l'IO, il nodo è libero di gestire più richieste. Se sta facendo un sacco di elaborazione intensiva della CPU, allora è bloccato a farlo e nient'altro. La maggior parte di ciò che hai elencato sembra perfetto per il nodo, tranne forse "I messaggi filtrati vengono elaborati". Se l'elaborazione è costosa, potresti avere un problema. –

+0

Hai riscontrato un problema con java EE? spettacoli o concorrenza? hai molte soluzioni per la concorrenza all'interno di java, vale la pena aggiungere un altro livello con un linguaggio diverso, non lo penso, a meno che ciò che hai provato non sia riuscito. – mpm

risposta

3

Disclaimer: Lavoro per un'azienda che contribuisce a node.js e ne promuove l'utilizzo, quindi la mia opinione potrebbe essere di parte.

Come altri menzionati nei commenti, node.js dovrebbe essere una buona soluzione per lo scenario. In realtà è uno degli scenari più comuni in cui le persone utilizzano node.js: recupera i dati da fonti (possibilmente multiple), esegue una piccola quantità di elaborazione della CPU e restituisce la risposta o memorizza il risultato. A meno che il filtro dei messaggi non sia costoso per la CPU, l'implementazione di node.js probabilmente supererà la versione di J2EE.

Il motivo è che Node.js è fortemente ottimizzato per soluzioni in cui il server trascorre la maggior parte del tempo in attesa. In attesa di connessione client, in attesa di risposta del database, in attesa di lettura/scrittura del disco, attesa del client per leggere la risposta, ecc.

J2EE utilizza multi-threading, in cui si ha un thread per gestire ogni richiesta, che è non ottimale in questo caso. La maggior parte dei thread sono in attesa, quindi non si ottiene il vantaggio di eseguire molto codice in parallelo, ma si deve comunque pagare il prezzo del cambio di contesto e dell'utilizzo della memoria più elevato.

C'è una cosa che vorrei prendere in considerazione prima di node.js: sei in grado e autorizzato a distribuire node.js nel tuo ambiente di produzione? Il passaggio a una nuova piattaforma comporta alcuni costi associati, le persone che utilizzano la propria applicazione dovranno imparare come gestire le applicazioni node.js.

+0

> 'Node.JS attuazione sarà probabilmente sovraperformare Java EE version' - Hai i dati a sostegno di questa? Questo punto di riferimento per esempio, non è esattamente supporta la sua affermazione: http://www.techempower.com/benchmarks/#section=data-r5 –

+0

> 'Java EE sta impiegando multi-threading, dove si ha un thread per gestire ogni richiesta '- Questa è un'opzione. Java EE supporta anche l'elaborazione asincrona HTTP. Vedi per es. http://www.javakeexample.com/2013/01/creating-asynchronous-servlets-with.html e https://blogs.oracle.com/enterprisetechtips/entry/asynchronous_support_in_servlet_3 –

+0

@ArjanTijms Buoni punti. Non ho dati complessi per supportare la mia affermazione sulla performance. Tuttavia il punto di riferimento a cui ti riferisci è viziata, usano client mysql che ha conosciuto problemi di prestazioni. Per quanto riguarda asincrona J2EE - asincrono servlet non è probabilmente sufficiente, si dovrebbe usare per la comunicazione asincrona a DB, ecc e che non è l'utilizzo di consueto per i componenti J2EE, è vero? –

Problemi correlati