è in streaming un'opzione valida? ci sarà una differenza di prestazioni sul lato server a seconda di quale scelgo? è uno migliore dell'altro per questo caso?polling lungo vs streaming per circa 1 aggiornamento/secondo
Sto lavorando a un'applicazione GWT con Tomcat in esecuzione sul lato server. Per capire le mie esigenze, immagina di aggiornare contemporaneamente i prezzi delle azioni di diversi titoli.
Vuoi che il processo sia basato su client o server? In altre parole, vuoi inviare nuovi dati ai client non appena sono disponibili, o preferiresti che i client richiedano nuovi dati ogni volta che lo ritengono opportuno, anche se potrebbe non essere una volta/secondo? Qual è la probabilità che il cliente sia in grado di restare in attesa di una risposta? Anche se si prevede che gli eventi si verifichino una volta al secondo, quanto tempo ci vuole tra una richiesta da un client e il ritorno dal server? Se è più lungo di un secondo, mi aspetto che ti spinga a spingere gli eventi ai clienti, anche se, al contrario, mi aspetto che il polling sia a posto. Se la risposta richiede più tempo dell'intervallo, significa che lo streaming è essenzialmente in ogni caso, dal momento che c'è un nuovo evento pronto al momento in cui il client riceve l'ultimo, in modo che il client possa eseguire il polling in modo continuo e ricevere sempre gli eventi, in questo caso lo streaming i dati sarebbero effettivamente più leggeri, dal momento che stai rimuovendo il sovraccarico di connessione/negoziazione dal processo.
Sospetto che il carico del server sia più elevato per una sottoscrizione basata su client (pull), anziché una configurazione di streaming, poiché il client dovrebbe rinegoziare la connessione ogni volta, invece di lasciare una connessione aperta, ma ogni connessione aperta in un modello di streaming richiederebbe anche le risorse del server. Dipende da quale sia il trade-off tra l'aggressività del processo di negoziazione e la quantità di memoria/elaborazione richiesta per ciascuna connessione aperta. Non sono esperto, però, quindi potrebbero esserci altri fattori.
UPDATE: This guy parla dei compromessi tra polling lungo e streaming e sembra dire che con HTTP/1.1, il processo di rinegoziazione della connessione è banale, quindi non è tanto un problema.
Certamente, se stai cercando di inviare dati, lo streaming sembrerebbe fornire prestazioni migliori, se il tuo server è in grado di gestire il numero previsto di connessioni continue. Ma c'è un altro problema a cui non ti rivolgi: sei internet o intranet? È stato segnalato che lo streaming presenta alcuni problemi tra i proxy, proprio come ci si aspetterebbe. Quindi, per una soluzione generica, è probabile che tu possa essere meglio servito da un lungo sondaggio: per un'intranet, dove comprendi l'infrastruttura di rete, lo streaming è molto probabilmente una soluzione più semplice e migliore per te.
Lo streaming sarà più veloce perché i dati attraversano il cavo solo in un modo. Con il polling, la latenza è almeno due volte.
Il polling è più resisibile alle interruzioni di rete poiché non si basa su una connessione mantenuta aperta.
Vorrei andare per il polling solo per la robustezza.
Vorrei chiarire che la mia domanda riguarda il polling lungo e il polling tradizionale. Inoltre, NIO dovrebbe essere un dato. – jcee14
Hai ragione, NIO interrompe il thread per limitazione della connessione, alleggerendo il requisito del thread. –
Per i prezzi delle azioni dal vivo, dovrei assolutamente mantenere aperta la connessione e assicurare la segnalazione/riconnessione dell'utente al momento della disconnessione.
Il StreamHub GWT Comet Adapter è stato progettato esattamente per questo scenario di quotazioni di borsa in streaming. Esempio qui: GWT Streaming Stock Quotes. Aggiorna i prezzi delle azioni di diversi titoli contemporaneamente. Penso che l'implementazione sottostante sia Comet che è essenzialmente in streaming su HTTP.
Modifica: utilizza una tecnica diversa per ciascun browser.Per citare il sito:
Ci sono diversi sottostanti tecniche utilizzate per implementare Comet compreso Hidden iFrame, XMLHttpRequest/Script polling lungo, e plugin embedded come Flash. L'introduzione di HTML 5 WebSockets nei browser futuri fornirà un meccanismo alternativo per HTTP Streaming. StreamHub utilizza un approccio "best-fit" che utilizza la tecnica più performante e una tecnica affidabile per ciascun browser .
Non importa. Il sovraccarico di rinegoziazione della connessione è così sottile con HTTP 1.1, non noterete differenze significative di prestazioni in un modo o nell'altro.
I vantaggi di lungo polling sono compatibili e affidabili - problemi con proxy, porte, disconnette rilevazione, ecc
I vantaggi di streaming "vera" sarebbe potenzialmente ridotto testa, ma come già menzionato questo il beneficio è molto, molto meno di quanto è stato concepito.
Personalmente, trovo che un server comet ben progettato sia la soluzione migliore per un numero elevato di aggiornamenti e/o server-push.
Ehi rwmnau, il link che hai fornito è illuminante. Per rispondere alle tue domande, vorrei inviare i dati agli utenti non appena disponibili. – jcee14
Se stai cercando di inviare i dati agli utenti il prima possibile, allora penso che la scelta debba essere lo streaming, dal momento che manterrà una connessione basata su push. Con una configurazione pull, stai aspettando che i clienti chiedano, ma con la spinta, avranno i dati non appena li darai a loro. Fammi sapere cosa finisci a raccogliere e perché! – SqlRyan