Il thread di blocco Web Socket mantiene la connessione mentre la normale connessione http funziona?

Question

Il thread di blocco Web Socket mantiene la connessione mentre la normale connessione http funziona?

#1 da (0 voti)

-1

Prendiamo ad esempio il socket Web di Spring (con tomcat).

Web Socket blocca i thread mantenendo la connessione tra server e client? (Ad esempio, la connessione può durare 2-3 ore).

( Il web socket utilizza thread allo stesso modo della normale richiesta http (ad esempio, blocchi / proprietario thread durante l'esecuzione delle richieste) )

Supponiamo che il server sia configurato per avere 200 thread nel pool di thread e utilizza il blocco io.

Significa che se disponiamo di 200 connessioni websocket long-living aperte, il server non sarà in grado di gestire altre normali richieste HTTP o connessioni socket web mentre quelle 200 connessioni sono aperte?

Da tomcat docs ( link ):

maxThreads

The maximum number of request processing threads to be created by this Connector, which therefore determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to 200. If an executor is associated with this connector, this attribute is ignored as the connector will execute tasks using the executor rather than an internal thread pool. Note that if an executor is configured any value set for this attribute will be recorded correctly but it will be reported (e.g. via JMX) as -1 to make clear that it is not used.

Quindi questo significa che se avremo 200 socket web longevi, il server non potrà più accettare richieste?

Quindi, se un sito web ha una quantità enorme di utenti e ha bisogno di server di almeno 10000 utenti (che aprono WebSocket) contemporaneamente, vuol dire che ha bisogno di 50 server solo per quei 10.000 utenti?

E riguardo il non blocco io? (Netty, Akka http)

multithreading spring websockets tomcat

posta Teimuraz 10.10.2017 - 20:30

fonte

1 risposta

Leggi altre domande sui tag multithreading spring websockets tomcat

Struttura dei dati annidati Rimozione di Obsession Primitive e denominazione delle classi create [duplicate]

score 0 · Answer 1

Ho creato un server con un numero limitato di thread max prima. La soluzione è mettere un limite sulla durata delle connessioni aperte e / o il numero di richieste che una connessione verrà eseguita prima di essere chiusa dal server. Quindi il cliente torna in linea per richiedere un'altra connessione. Questo può funzionare solo se le richieste del cliente sono indipendenti e non richiedono una connessione a lunga durata (che dovrebbe essere il caso). Ho usato il blocco degli I / O, ma ho avuto un timeout sulla ricezione dei dati delle richieste.

Nel mio caso, ho permesso una connessione HTTP (gestita da un thread appena generato) per elaborare fino a 10 richieste e vivere fino a 2 secondi (la richiesta finale viene eseguita fino al completamento, ovviamente), quindi il thread finisce. Questo garantisce equità. Ho usato un semaforo di conteggio per limitare il numero di connessioni / thread aperti. Ho anche fornito un mezzo per più processi del server in modo che, nel caso in cui un processo del server si arrestasse in modo anomalo (cosa che non accadeva), le richieste sarebbero semplicemente passate a un altro processo finché non si fosse riavviato. Potrei aggiornare il software in questo modo, inviando un segnale di hangup per dire al server di riavviare.

Ho avuto modo di monitorare lo stato della connessione su tutti i server e ha funzionato molto bene e bene. Unix ha fatto tutto il lavoro pesante, ho solo dovuto imparare e approfittare di ciò che ha fornito. Era il 1999.