Quante connessioni socket possibili?

Question

Qualcuno ha idea di quante connessioni socket tcp sono possibili su un moderno server root standard? (In generale c'è meno traffico su ogni connessione, ma tutte le connessioni devono essere sempre attive.)

MODIFICA: useremo un server Linux.

Answer 1

Google around per il " C10K " problema. Questo è fondamentalmente discussione e tecnologia sulla gestione di 10.000 o più connessioni simultanee.

Sospetto che questo numero sia stato scelto perché è difficile, ma teoricamente possibile.

Answer 2

Ho raggiunto 1600k connessioni socket inattive simultanee e allo stesso tempo 57k req / s su un desktop Linux (16G RAM, CPU I7 2600). È un server http a thread singolo scritto in C con epoll. Il codice sorgente è su github , a blog qui .

Modifica:

Ho effettuato 600k connessioni HTTP simultanee (client & amp; server) su entrambi lo stesso computer, con JAVA / Clojure. informazioni dettagliate post , discussione HN: http://news.ycombinator.com/item?id=5127251

Il costo di una connessione (con epoll):

• l'applicazione richiede un po 'di RAM per connessione
• Buffer TCP 2 * 4k ~ 10k o più
• epoll necessita di memoria per un descrittore di file, da epoll (7)

  

Ogni descrittore di file registrato costa circa 90                 byte su un kernel a 32 bit e circa 160 byte su un kernel a 64 bit.

Answer 3

Ciò dipende non solo dal sistema operativo in questione, ma anche dalla configurazione, configurazione potenzialmente in tempo reale.

Per Linux:

cat /proc/sys/fs/file-max

mostrerà il numero massimo corrente di descrittori di file totali che possono essere aperti contemporaneamente. Dai un'occhiata a http://www.cs.uwaterloo.ca/~brecht/servers /openfiles.html

Answer 4

10.000? 70.000? è tutto :)

FreeBSD è probabilmente il server che desideri, ecco un little post sul blog su come ottimizzarlo per gestire 100.000 connessioni, da qualche tempo ha alcune caratteristiche interessanti come socket zero-copia, insieme a kqueue che funge da meccanismo di completamento delle porte.

Solaris può gestire 100.000 connessioni nel secolo scorso !. Dicono che Linux sarebbe meglio

La migliore descrizione che ho trovato è questa presentazione / documento sulla scrittura di un server web scalabile. Non ha paura di dirlo come è :)

  

Lo stesso per il software: i cretini sul   livello di applicazione forzato alla grande   innovazioni a livello di sistema operativo. Perché   Lotus Notes mantiene una connessione TCP   per client aperto, IBM ha contribuito in maniera significativa   ottimizzazioni per & # 8221; un processo,   100.000 connessioni aperte & # 8221; caso su Linux

     

E lo scheduler O (1) era originariamente   creato per segnare bene su alcuni   benchmark Java irrilevante. Il fondo   la linea è che questo gonfiore è tutto   noi.

Answer 5

Su Linux dovresti cercare di usare epoll per l'I / O asincrono. Potrebbe anche valere la pena mettere a punto socket buffer per non sprecare troppo spazio nel kernel per connessione.

Immagino che dovresti essere in grado di raggiungere 100k connessioni su una macchina ragionevole.

Answer 6

Un limite al numero di socket aperti è configurabile nel file system / proc

cat /proc/sys/fs/file-max

Max per connessioni in entrata nel sistema operativo definite da limiti interi.

Linux stesso consente miliardi di socket aperti.

Per utilizzare le prese è necessario un ascolto dell'applicazione, ad es. un server web e che utilizzerà una certa quantità di RAM per socket.

RAM e CPU introdurranno i limiti reali. (moderno 2017, pensa milioni non miliardi)

1 milione è possibile, non facile. Aspettatevi di usare X Gigabyte di RAM per gestire 1 milione di socket.

In uscita Le connessioni TCP sono limitate da numeri di porta ~ 65000 per IP. Puoi avere più indirizzi IP, ma non indirizzi IP illimitati. Questo è un limite in TCP, non in Linux.

Answer 7

dipende dall'applicazione. se ci sono solo pochi pacchetti per ogni client, 100K è molto semplice per Linux. Un ingegnere del mio team aveva fatto un test anni fa, il risultato mostra: quando non esiste alcun pacchetto dal client dopo aver stabilito la connessione, epoll di Linux può guardare 400k fd per la leggibilità a livello di utilizzo della CPU inferiore al 50%.

Answer 8

Quale sistema operativo?

Per i computer Windows, se si sta scrivendo un server per il ridimensionamento corretto e quindi utilizzando le porte di completamento I / O e l'I / O asincrono, la limitazione principale è la quantità di pool non di paging che si sta utilizzando per ogni connessione attiva. Ciò si traduce direttamente in un limite in base alla quantità di memoria installata dalla macchina (il pool non di paging è una quantità finita di dimensioni fisse basata sulla memoria totale installata).

Per le connessioni che non vedono molto traffico, è possibile ridurle rendendole più efficienti pubblicando "letture zero byte" che non utilizzano pool non paginati e non influiscono sul limite di pagine bloccate (un'altra risorsa potenzialmente limitata che potrebbe impedire l'apertura di molte connessioni socket).

A parte questo, beh, dovrai creare un profilo ma sono riuscito a ottenere più di 70.000 connessioni simultanee su un server specificato in modo modesto (memoria da 760 MB); vedi qui http://www.lenholgate.com/ blog / 2005/11 / windows-tcpip-server-performance.html per maggiori dettagli.

Ovviamente se stai usando un'architettura meno efficiente come 'thread per connessione' o 'seleziona', dovresti aspettarti di ottenere cifre meno impressionanti; ma, IMHO, semplicemente non c'è motivo di selezionare tali architetture per i server socket di Windows.

Modifica: vedi qui http://blogs.technet.com/ markrussinovich / archive / 2009/03/26 / 3211216.aspx ; il modo in cui viene calcolata la quantità di pool non paginato è cambiato in Vista e Server 2008 e ora è disponibile molto di più.

Answer 9

Realisticamente per un'applicazione, più di 4000-5000 socket aperti su una singola macchina diventano poco pratici. Il solo controllo dell'attività su tutti i socket e la loro gestione inizia a diventare un problema di prestazioni, soprattutto in ambienti in tempo reale.