Server ha inviato eventi, Puma, Rails e max thread dedicati per ciascun client

Question

Sto utilizzando Redis per il mio progetto di rotaie per iscriversi ai canali e pubblicare su quei canali quando si verifica un evento. Sul lato client, mi sto registrando su EventSource che corrisponde a questi canali. Ogni volta che si verifica un evento per il canale sottoscritto sul server, il server esegue una scrittura SSE in modo che tutti i client registrati ricevano l'aggiornamento.

Ora la connessione con il server rimane attiva per ogni client che è sottoscritto a quei canali, il thread del server dedicato a questo client rimane in esecuzione fino a quando il client non si disconnette. Con questo approccio, se ci sono 1000 utenti simultanei iscritti a un canale, avrei 1000 connessioni TCP/IP aperte.

Sto utilizzando Puma come server Web come suggerito in this tutorial. Puma per impostazione predefinita specifica 16 thread max. Posso modificare questo limite a un limite superiore.

Potrei non sapere quanti utenti concorrenti ci potrebbero essere alla volta nella mia app e non so quale max. di thread che posso specificare in Puma. Nel peggiore dei casi, se il numero di thread dedicati a ciascun utente simultaneo raggiunge il numero massimo di thread specificato per il server Web Puma, l'app si bloccherà per tutti gli utenti fino a quando uno degli utenti contemporanei si disconnette.

Ero entusiasta di utilizzare lo streaming live di Rails e il server ha inviato eventi nel mio progetto di rotaie ma con questo approccio rischio di raggiungere il limite massimo di thread specificato nel mio server web e di conseguenza l'app non risponde per tutti gli utenti fino a uno di l'utente concorrente si disconnette.

Non sono sicuro quale sia il numero massimo tipico di thread per Puma per una grande base di utenti simultanei.

Devo considerare altri approcci, ad esempio il polling basato su jax o Node.js che utilizza un modello I/O non bloccato e basato sugli eventi? O semplicemente esegui alcuni benchmark per sapere quale può essere il mio numero massimo di thread?

Answer 1

Attualmente sto lavorando a un progetto in cui siamo andati con il polling a causa dei problemi di connessione aperti. Abbiamo pensato che sarebbe stato più facile eseguire il polling ogni tre secondi, quindi mantenere una connessione aperta e sospesa. Ma i requisiti di freschezza dei dati non erano molto rigidi essendo tre secondi, quindi era fattibile, e una specie di sciocco sprecare un thread per tre secondi.

Quindi, a meno che non si abbiano requisiti molto rigidi per la freschezza dei dati e/o una base utenti limitata e/o la capacità di avere molti thread, il polling regolare è normalmente la strada da percorrere.

E d'altra parte se stanno andando a colpire costantemente il server, e ci vorrebbe più tempo per interrogare nuovamente i dati quindi il requisito di freschezza dei dati, si potrebbe anche tenere aperta la connessione per evitare di dover affrontare l'intero stack di nuovo.

Anche in puma 2, è possibile eseguirlo anche in modalità cluster, il che significa che genera addetti con i propri thread e si può finire con Workers X Threads = Total Threads. Quale potrebbe aiutare nei tuoi calcoli.

https://github.com/puma/puma#clustered-mode