Laden...

TCP Verbindung max Anzahl

Erstellt von Derok vor 13 Jahren Letzter Beitrag vor 13 Jahren 3.941 Views
D
Derok Themenstarter:in
19 Beiträge seit 2011
vor 13 Jahren
TCP Verbindung max Anzahl

Hey,

hab mal einen Test zwischen Server und client gemacht, dazu folgende punkte.

Multithreading-Server
Client, der mehrere verbdinungen aufbauen kann (gleiche ip, gleicher port).

Sobald eine Verbindung aufgebaut wird, bleibt diese bestehen und schickt dauerhaft daten hin und her.

Nun passiert bei ca 1200 verbindungen auf den Server folgendes, die einzelne Threads für jeden client, werfen mir nach und nach IOExeptions raus. Mit der Begründung:
Von der Übertragungsverbindung können keine Daten gelesen werden.

Dies passiert immer ca ab der zahl 1200+-50.

Diesen Test hab ich auch mit einem Kollegen zusammen gemacht, beide haben immer mehr verbindungen aufgebaut und ab 1200+-50 sind uns die ersten verbindungen abgekackt.
Gibt es beim Thread eine maximale anzahl oder nimmt ein TCP-Server nicht mehr als eine bestimmte anzahl an verbindungen an?

Server von mir ist ein root server der an einer 100mbit leitung anliegt.
CPU auslastung war beim test bei 35%.
Hoffe jemand weiß den Grund und was man dagegen tun kann.

Warum ich diesen Test mache, weil ich demnächst eine Server-Architektur aufbauen muss, die sehr viele verbindungen aufeinmal bearbeiten kann.

D
Derok Themenstarter:in
19 Beiträge seit 2011
vor 13 Jahren

ok sry hat sich geklärt.

Nach vielen rum probieren hab ich das Problem entdeckt.

Es liegt nicht an der tcp verbindung daher gehört es nicht hier rein.
Grund dafür sind die Threads.
Jeder Thread zum client hat die gleiche Priorität.
Es sind nur sooo viele, das ein Thread auf dem Server so selten dran kommt, da der wohl immer bisl braucht vom Thread zu Thread um zu schalten, ist nur ehn 4corer, dadurch können auch nur 4 threads gleichzeitig vom cpu bearbeitet werden.

Fazit ab 1200 verbindungen ca, kommt der thread sooo selten dran, das er aufgrund des Standart Timeouts abbricht.
Und vermutlich wegen dem often wechsel zwischen den Threads, geht die cpu auch nie auf 100%

C
2.122 Beiträge seit 2010
vor 13 Jahren

Dann mach doch einfach nur ein paar Threads und lass die dann eine (synchronisierte) Liste der Anfragen abarbeiten.

D
Derok Themenstarter:in
19 Beiträge seit 2011
vor 13 Jahren

geht schlecht, jeder Thread soll einen Client abarbeiten, zu simulierenden zwecken, hab ich halt vom meinem pc aus mehrere clients simuliert.
Und wenn ein Thread mehrere Clients betreut, muss immer ein Client warten, daher im Prinzip dann das gleiche Problem.

1.130 Beiträge seit 2007
vor 13 Jahren

Eigendlich ist es besser, die asynchronen funktionen mit callbacks zu nutzen. Das ist dann allerdings ne nummer schwerer. In C#5 wird das einfacher zu benutzen werden.

Projekte:Jade, HttpSaver
Zum Rechtschreiben gibts doch schon die Politiker. Aber die bauen auch nur mist!

C
2.122 Beiträge seit 2010
vor 13 Jahren

Ok aber wenns halt nicht geht 😉
Wie lang dauert so eine Bearbeitung eines Clients?
Die Threads können das doch auch nacheinander machen, wirkliche Gleichzeitigkeit geht ja schon wegen der Netzwerkverbindung nicht, über die muss ja auch alles seriell.

D
Derok Themenstarter:in
19 Beiträge seit 2011
vor 13 Jahren

bei der anzahl an verbindungen, ca 1-2sec ping, was intollarant für mein vorhaben wär. ^^

C
2.122 Beiträge seit 2010
vor 13 Jahren

Ok das leuchtet bei der Zeit natürlich ein.
Es gibt allerdings eine Ping Klasse, die asynchrone Pings macht. Damit kann auch ein einzelner Thread mehrere Pings rausschicken und erhält die Antworten in einem separaten Event. Taugt das nichts?
Bzw. wie machst du die Pings bisher?

D
Derok Themenstarter:in
19 Beiträge seit 2011
vor 13 Jahren

naja ganz 100% ist es kein ping 😉 hab das so gemacht, von der einen Antwort bis zur nächsten antwort die Zeit ausgelesen. Am anfang ist die extrem niedrig. Aber bei so vielen verbindungen auf einmal wird die zeispanne zwischen beiden Antworten extrem groß.

C
2.122 Beiträge seit 2010
vor 13 Jahren

Ok aber selbst das können ja auch wenige Threads hintereinander machen.
Pack dir Infos pro Verbindung in ein Objekt und die Objekte in eine Liste. Dann kannst du in den Threads alles schicken und empfangen und immer richtig zuordnen. Du darfst halt nichts blockierendes verwenden, sondern immer asynchrone Methoden.
Wobei das Senden (wie ich mal gehört habe) schnell genug ist um es synchron zu machen, der Empfang sollte aber eventgesteuert sein und nicht durch Warten.

PS: nachdem die Clientverbindungen ja auch irgendwo verwaltet werden müssen, könnts schon auch sein dass 1000+ offene Verbindungen an sich ein Problem sind und das alles verlangsamen.

D
Derok Themenstarter:in
19 Beiträge seit 2011
vor 13 Jahren

die clientverbindungen verwalten sich mitlerweile im prinzip von selber, vor beginn der socketübernahme bekommt noch der server gesagt, hier ist eine verbindung am aufbauen usw. Passieren IOExeptions, oder Socket Exeptions, so schalten sich die Verbindungen selber ab und sagen es dem Server, genauso kann der Server aber über events, sagen das alle bzw nur eine bestimmte Verbindung aufhören soll.

Dein genannter ansatz, werd ich mir mal genauer überlegen.

3.170 Beiträge seit 2006
vor 13 Jahren

Hallo,

Eigendlich ist es besser, die asynchronen funktionen mit callbacks zu nutzen. Das ist dann allerdings ne nummer schwerer.

Das kann ich nur unterstützen, und viel schwerer ist es nun wirklich nicht.

Und wenn ein Thread mehrere Clients betreut, muss immer ein Client warten, daher im Prinzip dann das gleiche Problem.

Ab einer bestimmten Anzahl von Threads wirst Du da keine Performance mehr gewinnen, eher verlieren aufgrund der häufig nötigen Threadwechsel - aber das hast Du ja schon festgestellt - so kann es Dir passieren, daß die Clients mit Deiner angestrebten Methode noch länger warten.

Dann mach doch einfach nur ein paar Threads und lass die dann eine (synchronisierte) Liste der Anfragen abarbeiten.

wäre daher IMO durchaus auch sinnvoll.

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca