Per Threads aufteilen oder verschiedene Prozesse

Sitze momentan vor einem großen Projekt und bin nun am durchdenken von allem und weiß bei folgendem nicht weiter. Entwickelt wird in Python unter Debian 6.0.

So sieht das ungefähr aus: ich werde 500-1000 Verbindungen dauerhaft per socket halten müssen. Es werden events empfangen, befehle geschickt und weitergeleitet und befehle empfangen. Also benötige ich generell 3 Threads pro Verbindung.

Nun komm ich auch schon zu meinem Problem:
sollte ich, bei einem so hohen Aufkommen:
a.) für jede Verbindung einen eigenen Prozess starten, ergo jedesmal ein Python-Skript starten oder
b.) einen Prozess starten und innerhalb dieses Prozesses alle Verbindungen mit Threads öffnen, so dass diese Threads wiederum 3 Threads öffnen (da wäre ich dann bei fast 1500-3000 Threads)

Wichtiger Punkt ist hierbei der Speicherbedarf. Ich bin mir nicht zu 100% sicher, denke aber, dass 500-1000 Prozesse mehr Speicher verbrauchen als ein Einziger, der alles in sich schließt.

Nun denn, ich würde gerne einmal eure Meinung hören.

Soweit ich das sagen kann sollten eigene Prozesse deutlich mehr Ressourcen brauchen, da sie jedesmal nen eigenen Interpreter brauchen, aber da ich mit Phyton kaum was gemacht hab kann ich es natürlich nicht 100% sagen, ist aber relativ logische Folge. Ist halt auch die Frage ob bei dem ganzen Phyton tatsächlich sein muss, imo hab ich das Gefühl das das nicht die Optimale Wahl ist.
Denk mal wenn du es auf eigene Processe aufsplittest wirst du dir etwas stärkere Stabilität mit Ressourcen erkaufen können.

Was spricht gegen [Only registered and activated users can see links. Click Here To Register...]?

@dready: Unter Linux sind Prozesse normal sehr leichtgewichtig - weswegen man zB das multiprocessing modul ([Only registered and activated users can see links. Click Here To Register...]) verwenden könnte.

Du solltest deine Anwendung aber mal etwas detailierter beschreiben, dann kann man natürlich auch konkrete Tipps geben.

Intressant, bin davon ausgegangen, das Python pro Prozes einen kompletten interpreter startet und dies beim Thread nicht so wäre und daher der Overhead massiv zunimmt.

Wieder was gelernt :)

Um den alten Thread nochmals rauszukramen:

ich habe nun alles mit Threads gelöst, doch bemerke ich erhebliche Leistungseinbuße bei jeder einzelnen Verbindung, die ich hinzufüge. Somit habe ich die vergangenen Tage mit multiprocessing herumprobiert, und ein paar Tests durchgeführt, doch springen bei mir die Kerne der CPU instant auf 100%, egal ob die Prozesse etwas zu tun haben, oder nicht und nun wollte ich einmal fragen, ob das normal ist? Wenn ich alles mit Threads abarbeite springt die Auslastung ja auch nicht sofort auf 100% (aber für die eigentlich geringe Anforderung der Aufgaben doch ziemlich hoch).

CPU ist ein Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz verbaut.

EDIT:
es reicht ja schon, wenn der Prozess nur ein
erledigen muss, um auf 100% zu springen. Leider besteht meine Anwendung aus viele solcher Absätze, da auf Verbindungen und Interaktion gewartet werden (müssen)! >_<

Nun schaue ich mich auch nach anderen Sprachen um, die unter Linux laufen und gut für Netzwerkarbeiten sind. Grundlegend eben ein Server, der Befehle annimmt und ein Client, der diese teilweise weiterleitet. Mir wurde node.js empfohlen, allerdings habe ich damit noch nichts zu tun gehabt und würde deshalb lieber erstmal fragen, ob ihr Erfahrung damit habt und ob es generell geeignet ist. Mein jetziges Skript hat eben receiveHandler, sendHandler und eventHandler; alles einzelne Threads und auf die schnelle konnte ich bei node.js nicht herauslesen, dass es dort überhaupt einen Threading/Multiprocessing Support oÄ. gibt. Vielleicht lässt sich dies ja mit node.js anders lösen.

Wenn du mit einer Schleife auf etwas wartest musst du immer kurz warten, ansonsten passiert exakt das was du hier schilderst. Er macht eben genau das was du ihm hier sagst, er durchläuft die Schleife und fängt wieder von vorne an, und das macht er soschnell wie es ihm möglich ist -> 100% Auslastung. Sofern du nicht in Sync Probleme rennst versuchs erstmal damit den Thread zu in sleep zu setzen. Selbst sehr kleine Zeiten die gewartet wird sollten die Last deutlich verringern.

Du hattest meine Frage oben immernoch nicht beantwortet: Was spricht gegen twisted?
Für jede Verbindung einen oder gar mehrere(!) Threads geht meistens nicht gut.

Quote:

Originally Posted by dready Wenn du mit einer Schleife auf etwas wartest musst du immer kurz warten, ansonsten passiert exakt das was du hier schilderst. Er macht eben genau das was du ihm hier sagst, er durchläuft die Schleife und fängt wieder von vorne an, und das macht er soschnell wie es ihm möglich ist -> 100% Auslastung. Sofern du nicht in Sync Probleme rennst versuchs erstmal damit den Thread zu in sleep zu setzen. Selbst sehr kleine Zeiten die gewartet wird sollten die Last deutlich verringern.

Alles klar, vielen dank, werde ich gleich mal ausprobieren :)

Quote:

Originally Posted by Schlüsselbein Du hattest meine Frage oben immernoch nicht beantwortet: Was spricht gegen twisted? Für jede Verbindung einen oder gar mehrere(!) Threads geht meistens nicht gut.

Hm, twisted werde ich mir mal ansehen.
Aber folgender Satz

Quote:

Twisted also supports many common network protocols, including SMTP, POP3, IMAP, SSHv2, and DNS.

sagt doch aus, dass er nur bestimmte Protokolle benutzt und verwenden kann, oder verstehe ich da etwas falsch?
Was wäre denn deine Idee? Für mehrere Server einen send-, event- und receiveHandler?

Nö, du kannst auch lowlevel gehen und dein eigenes Protokoll benutzen.

Quote:

Was wäre denn deine Idee? Für mehrere Server einen send-, event- und receiveHandler?

Du musst dir klar machen, wie twisted funktioniert.

Du hast im Prinzip erstmal nur einen Thread, welcher sich um die Clients kümmert. Damit sollte dein Problem dann auch erledigt sein. Das bringt dir hier _nur_ Vorteile (bis auf die Einarbeitungszeit vielleicht): Dein Programm wird höchstwahrscheinlich viel performanter sein und du musst dich nicht um Synchronisation kümmern.

@dready's Lösung: Naja, in einer sehr netzwerklastigen Anwendung ein Sleep o.ä. einzubauen ist eher kontraproduktiv. Glaube nicht, dass dich das zum gewünschten Ergebnis führen wird, Denn die Zeit, die dein Thread wartet und nichts tut, könnte sinnvoller genutzt werden (deswegen twisted).


Edit: Hier mal eine kleine Einleitung: [Only registered and activated users can see links. Click Here To Register...] (sollte sich der TS für besseres Verständnis auf jedenfall durchlesen!).

Das das nicht die richtige Variante ist von vorneherein klar ;) , bin nur davon ausgegangen das er nicht sein Gesammtes Design ändern wird und da fallen mir nicht viele andere Lösungen ein.

Normalerweise kann man auch sleep(0) verwenden, um nicht wirklich zu schlafen, aber dem Scheduler mal die Möglichkeit zu geben, einen anderen Thread laufen zu lassen. Senkt die Last durch deinen Prozess auch schon erheblich.

Zu beachten ist, dass Python Threads nie zur selben Zeit ausgeführt werden (außer du nimmst was anderes als CPython): [Only registered and activated users can see links. Click Here To Register...]

Also solltest du mehrere Prozesse verwenden, anstatt (zuviele) Threads in Python ;)

Aber kommt halt drauf an, mehrere Threads in Python werden mehr CPU-Leistung verbrauchen, aber mehrere Prozesse von einem Python-Interpreter werden mehr RAM verbrauchen.

Achtung bro: 1 thread = ~1MB im Stack. Das heißt mit 3k threads hättest schon mal knapp 3GB Ram verheizt^^

Plus: Ich denke nicht dass du überhaupt einen Thread pro Connection brauchst (geschweige denn 3). So intensiv kann es ja gar nicht sein. und wenn doch, dann nimm nen Thread Pool her, implementiert ist der schnell über ne Queue. Somit sind immer nur so viele threads aktiv wie auch unbedingt sein muss. Deine architektur ist noch ausbaufähig^^