Hat jemand eine Idee, wie viele TCP-Socket-Verbindungen auf einem modernen Standard-Root-Server möglich sind? (Es gibt im Allgemeinen weniger Verkehr auf jeder Verbindung, aber alle Verbindungen müssen ständig aktiv sein.)
EDIT: Wir werden einen Linux Server verwenden.
Antworten:
Ich habe 1600k gleichzeitige Leerlauf-Socket-Verbindungen und gleichzeitig 57k Anforderungen auf einem Linux-Desktop (16G RAM, I7 2600 CPU) erreicht. Es ist ein einzelner Thread-HTTP-Server, der in C mit epoll geschrieben wurde. Der Quellcode ist auf Github , einem Blog hier .
Bearbeiten:
Ich habe mit JAVA / Clojure 600.000 gleichzeitige HTTP-Verbindungen (Client und Server) auf demselben Computer hergestellt. Detailinfo- Beitrag , HN-Diskussion: http://news.ycombinator.com/item?id=5127251
Die Kosten für eine Verbindung (mit Epoll):
Jeder registrierte Dateideskriptor kostet ungefähr 90 Bytes auf einem 32-Bit-Kernel und ungefähr 160 Bytes auf einem 64-Bit-Kernel.
Dies hängt nicht nur vom jeweiligen Betriebssystem ab, sondern auch von der Konfiguration, möglicherweise in Echtzeit.
Für Linux:
cat /proc/sys/fs/file-max
zeigt die aktuelle maximale Anzahl von Dateideskriptoren an, die insgesamt gleichzeitig geöffnet werden dürfen. Überprüfen Sie http://www.cs.uwaterloo.ca/~brecht/servers/openfiles.html
10.000? 70.000? ist das alles :)
FreeBSD ist wahrscheinlich der Server, den Sie möchten. Hier ist ein kleiner Blog-Beitrag über die Optimierung für 100.000 Verbindungen. Es enthält seit einiger Zeit einige interessante Funktionen wie Zero-Copy-Sockets sowie Kqueue als Abschluss-Port-Mechanismus.
Solaris kann im letzten Jahrhundert 100.000 Verbindungen verarbeiten !. Sie sagen, Linux wäre besser
Die beste Beschreibung, auf die ich gestoßen bin, ist diese Präsentation / dieses Papier zum Schreiben eines skalierbaren Webservers. Er hat keine Angst, es so zu sagen, wie es ist :)
Gleiches gilt für Software: Die Cretins auf der Anwendungsschicht erzwangen große Innovationen auf der Betriebssystemschicht. Da Lotus Notes eine TCP-Verbindung pro Client offen hält, hat IBM wichtige Optimierungen für den Fall "Ein Prozess, 100.000 offene Verbindungen" für Linux vorgenommen
Der O (1) -Planer wurde ursprünglich entwickelt, um bei irrelevanten Java-Benchmarks gute Ergebnisse zu erzielen. Das Fazit ist, dass dieses Aufblähen uns allen zugute kommt.
Im Dateisystem / proc kann die Anzahl der offenen Sockets begrenzt werden
cat /proc/sys/fs/file-max
Max für eingehende Verbindungen im Betriebssystem, definiert durch ganzzahlige Grenzwerte.
Linux selbst erlaubt Milliarden offener Sockets.
Um die Sockets verwenden zu können, muss eine Anwendung lauschen, z. B. ein Webserver. Dabei wird eine bestimmte Menge RAM pro Socket benötigt.
RAM und CPU werden die wirklichen Grenzen einführen. (modernes 2017, denke Millionen nicht Milliarden)
1 Million ist möglich, nicht einfach. Erwarten Sie X Gigabyte RAM für die Verwaltung von 1 Million Sockets.
Ausgehende TCP-Verbindungen sind durch Portnummern ~ 65000 pro IP begrenzt. Sie können mehrere IP-Adressen haben, jedoch nicht unbegrenzte IP-Adressen. Dies ist eine Grenze in TCP, nicht in Linux.
Unter Linux sollten Sie epoll für asynchrone E / A verwenden. Es könnte sich auch lohnen, Socket-Puffer zu optimieren, um nicht zu viel Kernel-Speicherplatz pro Verbindung zu verschwenden.
Ich würde vermuten, dass Sie in der Lage sein sollten, 100.000 Verbindungen auf einem vernünftigen Computer zu erreichen.
hängt von der Anwendung ab. Wenn es nur wenige Pakete von jedem Client gibt, ist 100K für Linux sehr einfach. Ein Ingenieur meines Teams hatte vor Jahren einen Test durchgeführt. Das Ergebnis zeigt: Wenn nach dem Herstellen der Verbindung kein Paket vom Client vorhanden ist, kann Linux Epoll 400.000 fd auf Lesbarkeit bei einer CPU-Auslastung von weniger als 50% überwachen.
Welches Betriebssystem?
Wenn Sie auf Windows-Computern einen Server schreiben, der gut skaliert werden kann und daher E / A-Abschlussports und asynchrone E / A verwendet, besteht die Hauptbeschränkung in der Menge des nicht ausgelagerten Pools, den Sie für jede aktive Verbindung verwenden . Dies führt direkt zu einer Begrenzung, die auf der von Ihrem Computer installierten Speichermenge basiert (nicht ausgelagerter Pool ist eine endliche Menge mit fester Größe, die auf dem installierten Gesamtspeicher basiert).
Für Verbindungen, die nicht viel Verkehr sehen, können Sie sie effizienter gestalten, indem Sie "Null-Byte-Lesevorgänge" veröffentlichen, die keinen nicht ausgelagerten Pool verwenden und das Limit für gesperrte Seiten nicht beeinflussen (eine weitere potenziell begrenzte Ressource, die Sie möglicherweise verhindert viele Steckdosen offen haben).
Abgesehen davon müssen Sie ein Profil erstellen, aber ich habe es geschafft, mehr als 70.000 gleichzeitige Verbindungen auf einem bescheiden spezifizierten Server (760 MB Speicher) herzustellen. Weitere Informationen finden Sie hier http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html .
Wenn Sie eine weniger effiziente Architektur wie "Thread pro Verbindung" oder "Auswahl" verwenden, sollten Sie natürlich weniger beeindruckende Zahlen erwarten. Aber meiner Meinung nach gibt es einfach keinen Grund, solche Architekturen für Windows-Socket-Server auszuwählen.
Edit: siehe hierhttp://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx ; Die Art und Weise, wie die Menge des nicht ausgelagerten Pools berechnet wird, hat sich in Vista und Server 2008 geändert, und es ist jetzt viel mehr verfügbar.
Realistisch gesehen werden für eine Anwendung mehr als 4000-5000 offene Sockel auf einer einzelnen Maschine unpraktisch. Das bloße Überprüfen und Verwalten aller Sockets auf Aktivitäten wird zu einem Leistungsproblem - insbesondere in Echtzeitumgebungen.