it-swarm.com.de

Wie viele Socketverbindungen kann ein Webserver verarbeiten?

Wenn ich gemeinsam genutztes, virtuelles oder dediziertes Hosting erhalten würde, habe ich irgendwo gelesen, dass ein Server/Computer nur 64.000 TCP -Verbindungen gleichzeitig verarbeiten kann. Stimmt das? Wie viele Hosting-Typen können unabhängig von der Bandbreite verarbeitet werden? Ich gehe davon aus, dass HTTP über TCP funktioniert.

Bedeutet dies, dass nur 64.000 Benutzer eine Verbindung zur Website herstellen könnten, und wenn ich mehr Dienste anbieten wollte, müsste ich zu einer Webfarm wechseln?

89
David

Kurz: Sie sollten in der Lage sein, in der Größenordnung von Millionen gleichzeitig aktiven TCP Verbindungen und durch Erweiterung HTTP zu erreichen Anfrage (n): Hier sehen Sie die maximale Leistung, die Sie mit der richtigen Plattform und der richtigen Konfiguration erwarten können.

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

Bester 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 stromabwärts möglich sind.

Stellen Sie sich also das folgende Szenario für meine Antwort vor:

  1. Kein Datenverkehr in den TCP Sitzungen, außer Keep-Alive-Paketen (andernfalls würden Sie offensichtlich eine entsprechende Menge an Netzwerkbandbreite und anderen Computerressourcen benötigen)
  2. Software für asynchrone Sockets und Programmierung anstelle eines Hardwarethreads pro Anforderung aus einem Pool. (dh IIS, Node.js, Nginx ... Webserver [aber nicht Apache] mit asynchroner Anwendungssoftware)
  3. Gute Leistung/Dollar CPU/Ram. Heute sagen wir willkürlich i7 (4-Kern) mit 8 GB RAM.
  4. Eine passende Firewall/Router.
  5. Kein virtuelles Limit/Regler - 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 Netzwerk-E/A.

Detaillierte Antwort

Synchrone threadgebundene Entwürfe weisen im Vergleich zu asynchronen IO Implementierungen die schlechteste Leistung auf.

WhatsApp erzielt 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 dieser http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , geht auf viele Details ein und untersucht, wie selbst 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 Universal-CPU.

Gute Auswahl an Software-Designs

Das asynchrone Design von IO unterscheidet sich zwischen Betriebssystemen und Programmierplattformen. Node.js wurde unter Berücksichtigung von 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 von Betriebssystem und Plattform ist zu erwarten, dass die asynchrone Ausführung sehr gut ist. 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 eine Art Add-On handelt.

Zum WebFarm?

Was auch immer die Grenze für Ihre spezielle Situation ist, eine Webfarm ist 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 auch diese haben ein Limit zusammen mit der Bandbreitenobergrenze), aber ich bevorzuge diese Option nicht. Bei Anwendungen mit nur einer Seite und langen Verbindungen bevorzuge ich eine offene Liste von Servern, aus denen die Clientanwendung beim Start nach dem Zufallsprinzip auswählen und über die Lebensdauer der Anwendung wiederverwenden wird. Dies beseitigt den Single Point of Failure (Load Balancer) und ermöglicht die Skalierung durch mehrere Rechenzentren und damit eine viel größere Bandbreite.

Busting eines Mythos - 64K Ports

Um die Fragekomponente in Bezug auf "64.000" anzusprechen, ist dies ein Irrtum. Ein Server kann eine Verbindung zu mehr als 65535 Clients herstellen. Siehe https://networkengineering.stackexchange.com/questions/48283/is-a-tcp-server-limited-to-65535-clients/48284

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

Update 30.05.2019

Hier finden Sie einen aktuellen Vergleich der schnellsten HTTP-Bibliotheken - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

  • Testdatum: 06.06.2018
  • Verwendete Hardware: Dell R440 Xeon Gold + 10 GbE
  • Der Anführer hat ~ 7 Millionen Klartext-Antworten pro Sekunde (Antworten, keine Verbindungen).
  • Das zweite Fasthttp für Golang bewirbt 1,5 Millionen gleichzeitige Verbindungen - 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 rangiert bei 2,7 Millionen pro Sekunde auf dem 29. Platz.
  • Am Ende der Liste notiere ich laravel und cakephp, Rails, aspnet-mono-ngx, symfony, zend. Alle unter 10k pro Sekunde. Beachten Sie, dass die meisten dieser Frameworks für dynamische Anwendungen erstellt wurden Seiten und ziemlich alt, kann es neuere Varianten geben, die oben in der Liste stehen.
  • 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.
93
Todd

Diese Frage ist ziemlich schwierig. Es gibt keine wirkliche Softwarebeschränkung für die Anzahl der aktiven Verbindungen, die eine Maschine haben kann, obwohl einige Betriebssysteme eingeschränkter sind als andere. Das Problem wird zu einer Ressource. Angenommen, ein einzelner Computer möchte 64.000 gleichzeitige Verbindungen unterstützen. Wenn der Server 1 MB RAM pro Verbindung verwendet, würde er 64 GB RAM benötigen. Wenn jeder Client eine Datei lesen muss, wird die Zugriffslast auf das Festplatten- oder Speicher-Array viel größer, als diese Geräte verarbeiten können. Wenn ein Server pro Verbindung einen Prozess forcieren muss, verwendet das Betriebssystem den Großteil seiner Zeit für Kontextwechsel oder für Prozesse, die für die CPU-Zeit hungern.

Die C10K-Problem -Seite hat eine sehr gute Diskussion dieses Problems.

52

Es sieht so aus, als wäre die Antwort mindestens 12 Millionen, wenn Sie einen starken Server haben, Ihre Serversoftware dafür optimiert ist und Sie über genügend Clients verfügen. Wenn Sie von einem Client auf 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 Quelle und Ziel definiert.) ). 

(Sie müssen mehrere Clients ausführen, da Sie ansonsten die 64-KB-Grenze für die Portnummern zuerst erreicht haben.)

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 erreichen, c. Bin ich fertig? Wenn nicht, dann d. herauszufinden, was der limitierende Faktor war, e. Gehe zurück zu Schritt a (spülen und wiederholen).

Hier ist ein Beispiel mit 2 Millionen TCP -Verbindungen auf einer bulligen Box (128 GB RAM und 40 Kerne), auf denen Phoenix http://www.phoenixframework.org/blog/the-road-to- ausgeführt wird. 2 Millionen Web-Socket-Verbindungen - Sie benötigten 50 oder weniger vernünftige Server, nur um die Client-Last bereitzustellen (ihre anfänglichen kleineren Clients waren zu früh ausgelastet, z. B. "unsere 4core/15gb Box @ 450k Clients").

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

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

6
iheggie

Um meine zwei Cents zur Konversation hinzuzufügen, kann ein Prozess gleichzeitig eine Anzahl von Sockets haben, die dieser Anzahl (in Linux-Typ sytems)/proc/sys/net/core/somaxconn entspricht

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

Es hängt jedoch vollständig vom Serverprozess, der Hardware der Maschine und dem Netzwerk ab, von der tatsächlichen Anzahl der Sockets, die angeschlossen werden können, bevor das System abstürzt

6
Abraham Covelo

Beachten Sie, dass HTTP TCP -Verbindungen normalerweise nicht länger geöffnet hält, als die Übertragung der Seite an den Client dauert. Normalerweise dauert es für den Benutzer viel länger, eine Webseite zu lesen, als zum Herunterladen der Seite. Während der Benutzer die Seite betrachtet, fügt er dem Server keinerlei Belastung hinzu.

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

4
Jeremy Friesner

im Falle des IPv4-Protokolls kann der Server mit einer IP-Adresse, die nur an einem Port überwacht wird, 2 ^ 32 IP-Adressen x 2 ^ 16 Ports verarbeiten, sodass 2 ^ 48 eindeutige Sockets möglich sind. Wenn Sie von einem Server als physischer Computer sprechen und alle 2 ^ 16-Ports verwenden 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, so dass diese Anzahl niedriger ist. Um zusammenzufassen:

1 IP- und 1 Port -> 2 ^ 48-Buchsen

1 IP und alle Ports -> 2 ^ 64 Sockets

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

1

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 der Gesamtmenge der auf dem Server verfügbaren Ressourcen, die jede andere Konfiguration zur Einschränkung der Webserver-Ressourcen zulassen. 

Wenn zum Beispiel jede Socket-Verbindung 1 MB Server-Ressource verbraucht und der Server 16 GB RAM zur Verfügung hat (theoretisch), bedeutet dies, dass er nur (16 GB/1 MB) gleichzeitige Verbindungen verarbeiten kann. Ich denke es ist so einfach ... WIRKLICH! 

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

0
Oladipo Olasemo

Hier gibt es zwei verschiedene Diskussionen: Eine ist, wie viele Personen sich mit Ihrem Server verbinden können. Dieses wurde von anderen ausreichend beantwortet, daher werde ich nicht darauf eingehen.

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

0
tunafish24