Wie viele Socket-Verbindungen kann ein Webserver verarbeiten?

114

Angenommen, ich sollte ein gemeinsames, virtuelles oder dediziertes Hosting erhalten. Ich habe irgendwo gelesen, dass ein Server / Computer nur 64.000 TCP-Verbindungen gleichzeitig verarbeiten kann. Stimmt das? Wie viele kann jede Art von Hosting unabhängig von der Bandbreite verarbeiten? Ich gehe davon aus, dass HTTP über TCP funktioniert.

Würde dies bedeuten, dass nur 64.000 Benutzer eine Verbindung zur Website herstellen könnten, und wenn ich mehr bereitstellen möchte, müsste ich auf eine Webfarm umziehen?

David
quelle
2
Entschuldigung an die Antwortenden, ich habe diesen Thread wie einen Tornado durchgerissen. Es gab einfach zu viele falsche Antworten für meinen Geschmack und immer noch keine direkte Antwort. Ich benutze Stackoverflow häufig und finde viele qualitativ hochwertige Antworten. Ich hoffe, dass andere diesen Thread finden und eine nützliche informierte Antwort finden können.
Todd
Hallo David, hast du die richtige Antwort auf diese Frage gefunden?
Dish
64000 TCP-Verbindungen über eine einzelne IP des Servers. Sie können Ihr Servernetzwerk aktualisieren, um mehr als 64000 zu skalieren und zu unterstützen.
Airy

Antworten:

108

Kurz gesagt: Sie sollten in der Lage sein, in der Größenordnung von Millionen gleichzeitig aktiver TCP-Verbindungen und durch Erweiterung HTTP-Anforderungen zu erreichen. Dies zeigt Ihnen die maximale Leistung, die Sie mit der richtigen Plattform mit der richtigen Konfiguration erwarten können.

Heute war ich besorgt, ob IIS mit ASP.NET in der Größenordnung von 100 gleichzeitigen Verbindungen unterstützt (siehe mein Update, erwarte ~ 10.000 Antworten pro Sekunde bei älteren ASP.Net Mono-Versionen). Als ich diese Frage / Antworten sah, konnte ich nicht widerstehen, mir selbst zu antworten. Viele Antworten auf die Frage hier sind völlig falsch.

I'm besten fall

Die Antwort auf diese Frage muss sich nur mit der einfachsten Serverkonfiguration befassen, um sich von den unzähligen Variablen und Konfigurationen zu entkoppeln, die nachgeschaltet möglich sind.

Betrachten Sie also das folgende Szenario für meine Antwort:

  1. Kein Datenverkehr in den TCP-Sitzungen, außer für Keep-Alive-Pakete (andernfalls würden Sie offensichtlich eine entsprechende Menge an Netzwerkbandbreite und anderen Computerressourcen benötigen).
  2. Software, die für die Verwendung von asynchronen Sockets und Programmierungen anstelle eines Hardware-Threads pro Anforderung aus einem Pool entwickelt wurde. (dh IIS, Node.js, Nginx ... Webserver [aber nicht Apache] mit asynchron gestalteter Anwendungssoftware)
  3. Gute Leistung / Dollar CPU / Ram. Sagen wir heute willkürlich i7 (4 Core) mit 8 GB RAM.
  4. Eine gute passende Firewall / Router.
  5. Kein virtuelles Limit / Governor - dh. Linux somaxconn, IIS web.config ...
  6. Keine Abhängigkeit von anderer langsamerer Hardware - kein Lesen von der Festplatte, da dies der kleinste gemeinsame Nenner und Engpass wäre, nicht die Netzwerk-E / A.

Detaillierte Antwort

Synchrone Thread-gebundene Designs weisen im Vergleich zu asynchronen E / A-Implementierungen tendenziell die schlechteste Leistung auf.

WhatsApp erhält eine Million WITH-Traffic auf einem einzelnen Unix-Betriebssystem - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ .

Und schließlich geht dieser, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , auf viele Details ein und erkundete, wie sogar 10 Millionen erreicht werden könnten. Server verfügen häufig über Hardware-TCP-Offload-Engines, ASICs, die für diese spezielle Rolle effizienter entwickelt wurden als eine Allzweck-CPU.

Gute Auswahl an Software-Designs

Das asynchrone E / A-Design unterscheidet sich zwischen Betriebssystemen und Programmierplattformen. Node.js wurde asynchron entwickelt. Sie sollten mindestens Promises verwenden, und wenn ECMAScript 7 verfügbar ist, async/ await. C # /. Net bietet bereits vollständige asynchrone Unterstützung wie node.js. Unabhängig vom Betriebssystem und der Plattform sollte eine sehr gute asynchrone Leistung erwartet werden. Und egal für welche Sprache Sie sich entscheiden, suchen Sie nach dem Schlüsselwort "asynchron". Die meisten modernen Sprachen werden unterstützt, auch wenn es sich um ein Add-On handelt.

Zu WebFarm?

Unabhängig von der Grenze für Ihre spezielle Situation ist eine Webfarm eine gute Lösung für die Skalierung. Es gibt viele Architekturen, um dies zu erreichen. Einer verwendet einen Load Balancer (Hosting-Anbieter können diese anbieten, aber selbst diese haben ein Limit, zusammen mit der Bandbreitenobergrenze), aber ich bevorzuge diese Option nicht. Für Einzelseitenanwendungen mit lang laufenden Verbindungen bevorzuge ich stattdessen eine offene Liste von Servern, aus denen die Clientanwendung beim Start zufällig auswählt und über die Lebensdauer der Anwendung wiederverwendet. Dies beseitigt den Single Point of Failure (Load Balancer) und ermöglicht die Skalierung durch mehrere Rechenzentren und damit viel mehr Bandbreite.

Einen Mythos zerstören - 64K-Ports

Dies ist ein Missverständnis, um die Fragekomponente bezüglich "64.000" anzusprechen. Ein Server kann eine Verbindung zu mehr als 65535 Clients herstellen. Siehe /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284

Übrigens erlaubt Http.sys unter Windows mehreren Anwendungen, denselben Serverport unter dem HTTP-URL-Schema gemeinsam zu nutzen. Sie registrieren jeweils eine separate Domänenbindung, aber letztendlich gibt es eine einzelne Serveranwendung, die die Anforderungen an die richtigen Anwendungen weiterleitet.

Update 2019-05-30

Hier ist ein aktueller Vergleich der schnellsten HTTP-Bibliotheken - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

  • Testdatum: 2018-06-06
  • Verwendete Hardware: Dell R440 Xeon Gold + 10 GbE
  • Der Leiter hat ~ 7 Millionen Klartextantworten pro Sekunde (Antworten keine Verbindungen)
  • Das zweite Fasthttp für Golang kündigt 1,5 Millionen gleichzeitige Verbindungen an - siehe https://github.com/valyala/fasthttp
  • Die führenden Sprachen sind Rust, Go, C ++, Java, C und sogar C # mit 11 (6,9 Millionen pro Sekunde). Scala und Clojure rangieren weiter unten. Python belegt mit 2,7 Millionen pro Sekunde den 29. Platz.
  • Am Ende der Liste stelle ich Laravel und Cakephp, Rails, Aspnet-Mono-Ngx, Symfony, Zend fest. Alles unter 10.000 pro Sekunde. Beachten Sie, dass die meisten dieser Frameworks für dynamische Seiten erstellt wurden und ziemlich alt sind. Möglicherweise gibt es neuere Varianten, die weiter oben in der Liste aufgeführt sind.
  • Denken Sie daran, dass dies HTTP-Klartext ist, nicht für die Websocket-Spezialität: Viele Leute, die hierher kommen, werden wahrscheinlich an gleichzeitigen Verbindungen für Websocket interessiert sein.
Todd
quelle
2
Vielen Dank, dass Sie Links zu Personen eingefügt haben, die darüber sprechen, wie sie es tun.
Rick Smith
Was passiert, wenn der einzelne Server, mit dem der Client verbunden ist, ausfällt? Und was ist, wenn alle Ihre SPAs zufällig mit einem Server verbunden und überlastet sind? Die Idee für die Verwendung von Loadbalancern ist nicht nur die Verwendung von 1, Sie können viele verwenden, wie Sie
möchten
3
Die Clients würden zufällig einen Server auswählen. Die Wahrscheinlichkeit, dass sich alle zufällig mit einem verbinden, ist praktisch unmöglich. Obwohl man die Anzahl der Clients nachverfolgen könnte und der Server einen Client auffordern könnte, auf einen anderen Server zu wechseln, wenn er zu überfüllt ist.
Todd
1
Betreff: Die 64K-Beschränkung - was Sie sagen, ist wahr, aber es ist ziemlich üblich, dass eine Server-App Anfragen an einige Backend-Dienste weiterleitet. In diesem Fall wird der "Server" jetzt zu einem "Client" und kann dies durchaus tun Sorgen um die Erschöpfung des kurzlebigen Hafens (z . B. nginx.com/blog/overcoming-ephemeral-port-exhaustion-nginx-plus ). Ich bin sicher, dass Sie das wissen, aber es für andere erwähnen (:
jwd
@jwd guter Punkt, kontextbezogen für nginx in einer Web-App, aber für eine einfache Website müsste ein solches Proxying nicht stattfinden. Das Gleiche gilt auch für die Verbindung zu einer Datenbank über TCP durch eine Webanwendung. Theoretisch wird dies gelöst, indem alle Adressen im Bereich 127. *. *. * Verwendet werden. In der Praxis weiß ich jedoch nicht, ob dies eine verfügbare Option ist.
Todd
54

Diese Frage ist ziemlich schwierig. Es gibt keine echte Softwarebeschränkung für die Anzahl der aktiven Verbindungen, die ein Computer haben kann, obwohl einige Betriebssysteme eingeschränkter sind als andere. Das Problem wird zu einer der Ressourcen. Angenommen, ein einzelner Computer möchte 64.000 gleichzeitige Verbindungen unterstützen. Wenn der Server 1 MB RAM pro Verbindung verwendet, werden 64 GB RAM benötigt. Wenn jeder Client eine Datei lesen muss, wird die Zugriffslast auf die Festplatte oder das Speicherarray viel größer, als diese Geräte verarbeiten können. Wenn ein Server einen Prozess pro Verbindung aufteilen muss, verbringt das Betriebssystem den größten Teil seiner Zeit damit, den Kontext zu wechseln oder Prozesse für die CPU-Zeit zu hungern.

Auf der C10K-Problemseite wird dieses Problem sehr gut diskutiert.

Codierer mit variabler Länge
quelle
3
Eine etwas gemischte Antwort. Das OP scheint sich auf ein Best-Case-Szenario zu beziehen und zu berücksichtigen, wie vorteilhaft es wäre, anstatt einen Worst-Case zu finden und sich dann auf einen Artikel zu beziehen, der möglicherweise die Lösung hat. Es ist nützlich, einen Festplattenengpass festzustellen. Mit Asynchronous IO kann eine sehr hohe Anzahl gleichzeitiger Clients erreicht werden.
Todd
Wie könnte man sagen, dass es keine echte Softwarebeschränkung gibt, da die Portgröße selbst 16 Bit beträgt, wodurch die maximale Anzahl von Ports zu keinem Zeitpunkt bei maximal 65,5 KB verfügbar ist. Ich glaube, deine Antwort ist falsch.
आनंद
Ihr Computer kann mehr als 1 IP haben, sodass mehr als 2 ^ 16 Ports verfügbar sind.
Arman Ordookhani
8

Um meine zwei Cent zur Konversation hinzuzufügen, kann ein Prozess gleichzeitig eine Anzahl von Sockets öffnen, die dieser Anzahl entsprechen (in Linux-Systemen) / proc / sys / net / core / somaxconn

cat / proc / sys / net / core / somaxconn

Diese Nummer kann im laufenden Betrieb geändert werden (natürlich nur vom Root-Benutzer).

echo 1024> / proc / sys / net / core / somaxconn

Dies hängt jedoch vollständig vom Serverprozess, der Hardware des Computers und des Netzwerks sowie der tatsächlichen Anzahl der Sockets ab, die vor dem Absturz des Systems verbunden werden können

Abraham Covelo
quelle
1
Während dies möglicherweise für Linux gilt, bezieht sich dies auf ein virtuelles Limit, nicht auf einen Benchmark von Möglichkeiten. Diese Antwort ist ein wenig spezifisch für meinen Geschmack und enthält keine Anzahl oder Angabe der Anzahl gleichzeitiger Verbindungen. Trotz Ihrer Bemühungen ist es nicht sehr nützlich. Vielleicht könnten Sie eine Frage selbst beantworten: "Warum kann ich nicht mehr als X gleichzeitige TCP-Verbindungen unter Linux bedienen"
Todd
2
Soweit ich das beurteilen kann, ist das falsch . somaxconn ist die maximale Anzahl von Verbindungen in der Warteschlange an einem offenen Socket (dh der maximale Wert des Backlog-Parameters von listen(int socket, int backlog). Es hängt nicht mit der Anzahl der Sockets zusammen, die ein Prozess geöffnet haben kann.
Timmmm
8

Es sieht so aus, als ob die Antwort mindestens 12 Millionen beträgt, wenn Sie einen leistungsfähigen Server haben, Ihre Serversoftware dafür optimiert ist und Sie genügend Clients haben. Wenn Sie von einem Client zu einem Server testen, ist die Anzahl der Portnummern auf dem Client eine der offensichtlichen Ressourcenbeschränkungen (jede TCP-Verbindung wird durch die eindeutige Kombination von IP und Portnummer an der Quelle und am Ziel definiert).

(Sie müssen mehrere Clients ausführen, da Sie sonst zuerst das 64-KB-Limit für Portnummern erreichen.)

Wenn es darauf ankommt, ist dies ein klassisches Beispiel für den Witz, dass "der Unterschied zwischen Theorie und Praxis in der Praxis viel größer ist als in der Theorie" - in der Praxis scheint das Erreichen der höheren Zahlen ein Zyklus von a zu sein. spezifische Konfigurations- / Architektur- / Codeänderungen vorschlagen, b. Testen Sie es, bis Sie ein Limit erreicht haben. c. Bin ich fertig Wenn nicht, dann d. herauszufinden, was der begrenzende Faktor war, z. Gehen Sie zurück zu Schritt a (spülen und wiederholen).

Hier ist ein Beispiel mit zwei Millionen TCP - Verbindungen auf eine bullige Box (128 GB RAM und 40 Kernen) laufen Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - sie endete Sie benötigen etwa 50 einigermaßen bedeutende Server, um die Client-Last bereitzustellen (ihre anfänglichen kleineren Clients wurden zu früh ausgelastet, z. B. "Maximierung unserer 4core / 15-GB-Box bei 450.000 Clients").

Hier ist eine weitere Referenz für dieses Mal bei 10 Millionen: http://goroutines.com/10m .

Dies scheint Java-basiert zu sein und 12 Millionen Verbindungen: https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/

iheggie
quelle
Tolle neue Links mit einem korrekten Verständnis der Frage. Ich mag die allgemeinen Ratschläge für Trefferbarriere -> Barriere reparieren. Jeder hat eine andere spezifische Situation, aber zumindest haben sie hier einen Hinweis darauf, was wirtschaftlich / praktisch erreichbar ist. Man sollte einem Kunden nicht bald 100 Millionen pro Server versprechen.
Todd
5

Beachten Sie, dass HTTP TCP-Verbindungen normalerweise nicht länger offen hält, als zum Übertragen der Seite an den Client erforderlich ist. und es dauert normalerweise viel länger, bis der Benutzer eine Webseite gelesen hat, als zum Herunterladen der Seite ... während der Benutzer die Seite anzeigt, fügt er dem Server überhaupt keine Last hinzu.

Die Anzahl der Personen, die Ihre Website gleichzeitig anzeigen können, ist also viel größer als die Anzahl der TCP-Verbindungen, die gleichzeitig bereitgestellt werden können.

Jeremy Friesner
quelle
12
Dies beantwortet die Frage überhaupt nicht. Unabhängig von der Genauigkeit Ihrer Angaben würde es zu einem bestimmten Zeitpunkt immer noch eine Reihe von gleichzeitigen TCP-Verbindungen geben. Was ist das Maximum? Dies ist der Kern der Frage.
Todd
3
Wenn Sie etwas Wertvolles beitragen können, Todd, machen Sie es auf jeden Fall.
Jeremy Friesner
8
Ich hatte bereits am 28. März eine Antwort, Sie müssen sie verpasst haben. In der modernen Welt der Einzelseitenanwendungen mit Long-Polling- und Web-Socket-Verbindungen ist HTTP nicht immer von kurzer Dauer. Aber selbst wenn es nur von kurzer Dauer ist, gibt es immer noch eine maximale Anzahl gleichzeitiger Verbindungen. Der Versuch, die Frage zu erklären, ist keine Antwort IMO. Diese Antwort wäre besser als Kommentar zu der Frage zu platzieren, sie ist sicherlich nützlich, aber die Frage bezieht sich auf "Socket-Verbindungen", nicht auf "Personen". Eine Frage zum Verhältnis (Benutzer: aktive Verbindungen) sollte auf Wunsch eine separate Frage sein.
Todd
1
Keep Alive on HTTP TCP-Verbindungen gibt es seit dem letzten Jahrtausend und werden von Browsern angefordert. Es ist Sache des Servers, ob die Verbindung am Leben bleibt und wie lange das Leerlaufzeitlimit sein wird. Durch das Zulassen von Keep Alive wird die Latenz einer Gruppe von Anforderungen (z. B. einer HTML-Seite und der zugehörigen Assets) verringert, die Ressourcennutzung auf dem Server jedoch erhöht.
Iheggie
1

Im Falle des IPv4-Protokolls kann der Server mit einer IP-Adresse, die nur einen Port überwacht, 2 ^ 32 IP-Adressen x 2 ^ 16 Ports verarbeiten, also 2 ^ 48 eindeutige Sockets. Wenn Sie von einem Server als physischem Computer sprechen und alle 2 ^ 16 Ports nutzen können, können maximal 2 ^ 48 x 2 ^ 16 = 2 ^ 64 eindeutige TCP / IP-Sockets für eine IP-Adresse vorhanden sein. Bitte beachten Sie, dass einige Ports für das Betriebssystem reserviert sind, sodass diese Anzahl niedriger ist. Um zusammenzufassen:

1 IP und 1 Port -> 2 ^ 48 Sockets

1 IP und alle Ports -> 2 ^ 64 Sockets

Alle eindeutigen IPv4-Sockets im Universum -> 2 ^ 96 Sockets

Lukasz Ochmanski
quelle
0

Hier gibt es zwei verschiedene Diskussionen: Eine ist, wie viele Personen eine Verbindung zu Ihrem Server herstellen können. Dieser wurde von anderen angemessen beantwortet, deshalb werde ich nicht darauf eingehen.

Andere ist, wie viele Ports Ihr Server abhören kann? Ich glaube, hier kam die 64K-Nummer her. Tatsächlich verwendet das TCP-Protokoll eine 16-Bit-Kennung für einen Port, die in 65536 (etwas mehr als 64 KB) übersetzt wird. Dies bedeutet, dass Sie pro IP-Adresse so viele verschiedene "Listener" auf dem Server haben können.

tunafish24
quelle
Zu Ihrem Vorteil habe ich meiner Antwort einen zusätzlichen Abschnitt hinzugefügt, der sich mit Ihrem Missverständnis befasst. Auch diese Frage bezieht sich auf "Socket-Verbindungen" und nicht auf "Personen", was im Zusammenhang mit dieser Frage eine wichtige Unterscheidung darstellt.
Todd
Wenn wir über einen einzelnen Server und einen einzelnen Router sprechen, denke ich, dass diese Antwort richtig ist. Bei @Todd handelt es sich jedoch um eine Farm von Server-Computern, mit denen der Benutzer über einen Load Balancer zufällig eine Verbindung zu einem beliebigen Computer herstellen kann.
Amr
@amr das ist falsch. Meine Antwort handelt von einer einzelnen Maschine. Die "Webfarm?" Der Abschnitt enthält Kontrastmittel und Ratschläge, um darüber hinauszugehen, und kommt zu dem Schluss, dass Load Balancer bei guter Architektur nicht erforderlich sind. Sie haben meine Antwort einfach noch nicht gründlich gelesen.
Todd
0

Ich denke, dass die Anzahl der gleichzeitigen Socket-Verbindungen, die ein Webserver verarbeiten kann, weitgehend von der Menge der Ressourcen abhängt, die jede Verbindung verbraucht, und von der Menge der auf dem Server verfügbaren Gesamtressource, sofern keine andere Konfiguration zur Einschränkung der Webserver-Ressourcen vorliegt.

Wenn jede Socket-Verbindung 1 MB Serverressource verbraucht und dem Server (theoretisch) 16 GB RAM zur Verfügung stehen, bedeutet dies, dass nur gleichzeitige Verbindungen (16 GB / 1 MB) verarbeitet werden können. Ich denke es ist so einfach ... WIRKLICH!

Unabhängig davon, wie der Webserver Verbindungen verarbeitet, verbraucht jede Verbindung letztendlich eine Ressource.

Oladipo Olasemo
quelle