Il modo in cui gli SSE vengono creati è il client che apre una connessione al server, che rimane aperta finché il server non ha alcuni dati da inviare. Questo fa parte delle specifiche SSE e non è una cosa specifica per ActionController :: Live. È effettivamente uguale al polling lungo, ma con la connessione che non viene chiusa dopo che è stato restituito il primo bit di dati e con il meccanismo integrato nel browser.
Come tale, l'unico modo in cui può essere implementato è avere più connessioni client aperte al server web che si siedono lì indefinitamente. Per quanto riguarda le risorse necessarie per gestirle, non ne sono sicuro, poiché non ho ancora provato a fare un benchmark, ma per Puma occorreranno abbastanza server per mantenere aperte migliaia di connessioni se si hanno molti utenti con una pagina aperta.
Il limite predefinito per puma è di 16 connessioni simultanee. Diversi post sui blog relativi alla configurazione di SSE per Rails menzionano questo valore ad un valore maggiore, ma nessuno di quelli che ho trovato suggerisce quale dovrebbe essere questo valore più alto. Dicono che il numero di connessioni DB dovrà essere lo stesso, dato che ogni thread di Rails ne mantiene uno in esecuzione. Una specie di suono sembra un modo costoso per eseguire le cose.
"Eseguire un punto di riferimento" è l'unica risposta davvero.
Non posso commentare come invertire il proxy poiché non l'ho provato, ma poiché gli SSE sono eseguiti su HTTP standard, non dovrei pensare che sia necessaria alcuna configurazione speciale.
fonte
2013-10-10 12:55:33
Ok, grazie per il vostro feedback! – tompave
qualcuno ha effettivamente fatto un simile punto di riferimento? – nicolas
Non ho eseguito un benchmark, ma alla fine ho respinto il tentativo poiché _non la produzione era pronta_. Temo che per questo tipo di scenari sia necessario utilizzare un modello evented. – tompave