Wie viele Socket-Verbindungen kann ein Webserver verarbeiten?

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?

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.

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.

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

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/

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.

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

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.

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.