In breve: dovresti essere in grado di ottenere nell'ordine di milioni di connessioni TCP attive simultanee e per estensione richieste HTTP. Questo ti dice le massime prestazioni che puoi aspettarti con la giusta piattaforma con la giusta configurazione.
Oggi ero preoccupato se IIS con ASP.NET avrebbe supportato nell'ordine di 100 connessioni simultanee (guarda il mio aggiornamento, si aspettano ~ 10.000 risposte al secondo sulle versioni precedenti di ASP.Net Mono). Quando ho visto questa domanda / risposte, non ho potuto resistere a rispondere a me stesso, molte risposte alla domanda qui sono completamente errate.
Caso migliore
La risposta a questa domanda deve riguardare solo la configurazione del server più semplice da disaccoppiare dalle innumerevoli variabili e configurazioni possibili a valle.
Quindi considera il seguente scenario per la mia risposta:
- Nessun traffico sulle sessioni TCP, ad eccezione dei pacchetti keep-alive (altrimenti avresti ovviamente bisogno di una quantità corrispondente di larghezza di banda di rete e altre risorse del computer)
- Software progettato per utilizzare socket e programmazione asincroni, anziché un thread hardware per richiesta da un pool. (es. IIS, Node.js, Nginx ... server web [ma non Apache] con software applicativo progettato in modo asincrono)
- Buone prestazioni / dollaro CPU / RAM. Oggi, arbitrariamente, diciamo i7 (4 core) con 8 GB di RAM.
- Un buon firewall / router da abbinare.
- Nessun limite / governatore virtuale - es. Linux somaxconn, IIS web.config ...
- Nessuna dipendenza da altro hardware più lento - nessuna lettura dal disco rigido, perché sarebbe il minimo comune denominatore e collo di bottiglia, non l'IO di rete.
Risposta dettagliata
I progetti associati a thread sincroni tendono ad essere i peggiori rispetto alle implementazioni di I / O asincrono.
WhatsApp ottiene un milione di traffico CON su una singola macchina con sistema operativo Unix - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ .
E infine, questo, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , entra in molti dettagli , esplorando come si potrebbero ottenere anche 10 milioni. I server spesso dispongono di motori di offload TCP hardware, ASIC progettati per questo ruolo specifico in modo più efficiente rispetto a una CPU generica.
Buone scelte di progettazione del software
La progettazione dell'I / O asincrono differirà tra i sistemi operativi e le piattaforme di programmazione. Node.js è stato progettato pensando all'asincrono . Dovresti usare almeno Promises e quando arriva ECMAScript 7, async/ await. C # /. Net ha già il pieno supporto asincrono come node.js. Qualunque sia il sistema operativo e la piattaforma, ci si dovrebbe aspettare che l'asincrono funzioni molto bene. E qualunque lingua tu scelga, cerca la parola chiave "asincrono", la maggior parte delle lingue moderne avrà un supporto, anche se si tratta di un componente aggiuntivo di qualche tipo.
Alla WebFarm?
Qualunque sia il limite per la tua situazione particolare, sì, una web farm è una buona soluzione per il ridimensionamento. Ci sono molte architetture per raggiungere questo obiettivo. Uno sta usando un bilanciatore del carico (i provider di hosting possono offrirli, ma anche questi hanno un limite, insieme al limite di larghezza di banda), ma non sono favorevole a questa opzione. Per le applicazioni a pagina singola con connessioni di lunga durata, preferisco invece avere un elenco aperto di server che l'applicazione client sceglierà in modo casuale all'avvio e riutilizzerà per tutta la durata dell'applicazione. Ciò rimuove il singolo punto di errore (bilanciamento del carico) e consente il ridimensionamento attraverso più data center e quindi molta più larghezza di banda.
Sfatare un mito: 64.000 porte
Per affrontare la componente domanda relativa a "64.000", questo è un malinteso. Un server può connettersi a molti più di 65535 client. Vedi /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284
A proposito, Http.sys su Windows consente a più applicazioni di condividere la stessa porta del server nello schema dell'URL HTTP. Ciascuno di essi registra un binding di dominio separato, ma alla fine c'è un'unica applicazione server che invia le richieste alle applicazioni corrette.
Aggiornamento 2019-05-30
Ecco un confronto aggiornato delle librerie HTTP più veloci: https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext
- Data del test: 06/06/2018
- Hardware utilizzato: Dell R440 Xeon Gold + 10 GbE
- Il leader ha ~ 7 milioni di risposte in chiaro al secondo (risposte non connessioni)
- Il secondo Fasthttp per golang pubblicizza 1,5 milioni di connessioni simultanee - vedere https://github.com/valyala/fasthttp
- I linguaggi principali sono Rust, Go, C ++, Java, C e persino C # si classificano a 11 (6,9 M al secondo). Scala e Clojure si classificano più in basso. Python è al 29 ° posto con 2,7 milioni al secondo.
- In fondo alla lista, noto laravel e cakephp, rails, aspnet-mono-ngx, symfony, zend. Tutto sotto i 10k al secondo. Nota, la maggior parte di questi framework sono costruiti per pagine dinamiche e piuttosto vecchi, potrebbero esserci varianti più recenti che sono presenti più in alto nell'elenco.
- Ricorda che questo è testo in chiaro HTTP, non per la specialità Websocket: molte persone che vengono qui saranno probabilmente interessate a connessioni simultanee per websocket.