Macht es Sinn ? Multithreaded Server in Delphi ?

[alzaimar]

Zitat:

Zitat von negaH

Im PortScanner-Thread hier in der DP habe ich klar gezeigt das man viel mehr als 16 Threads benutzen kann, zb. auf Win2k über 2000 Threads ! Und das in Delphi.

Vermutlich stammt diese Zahl aus den Anfängen von Delphi, wo 486er noch gang und gäbe waren. Weiterhin dürften von 2000 Threads bei einem Portscanner 1999 warten, insofern sollte das nicht das Problem sein. Nur 2000 ständig laufende Threads zwingen nun jeden Computer in die Knie.

Zitat:

Zitat von negaH

Davon mal abgesehen ändert ein Thread-Pool nichts an der Limitation der verfügbaren Threads, sondern beschleunigt nur die Re-/Allokation der Threads.
Gruß Hagen

Na nee: Ich definier mir ein Array von Threads. Die werden niemals terminieren (außer bei Programmende). Ein Busyflag zeigt an, ob ein Thread gerade beschäftigt ist, oder nicht. Und wenn ein neuer Request von außen kommt, schau ich in der Liste nach, welcher denn frei ist. Der wird aktiviert und bearbeitet den Job. Wenn keiner frei ist, warte ich.

[smudo]

Zitat:

Zitat von HamsterTrainer

Ich hab mal ne "dumme" Frage Smile
Macht es Sinn einen Multithreaded Server in Delphi zu Programmieren ?

Das ist übrigens wirklich eine dumme Frage. :zwinker:
Weil eine Frage keinen Sinn machen kann. Sie kann Selbigen nur haben.
"Macht Sinn" kommt übrigens aus dem Englischen "Make sense".

Der manchmal klugscheißende :warn: René der gerade "Der Dativ ist dem Genitiv sein Tod" lesen tut.

[negaH]

Zitat:

a) Speicher-Fragmentierung
b) Java nutzt ein eigenes Thread-Management, und setzt nicht auf Betriebssystemthreads auf

a) muß zwangsläufig bei jedem Speichermanager auftreten. Speicherfragmentierungen sind auch garnicht das große Problem ansich.

b) ändert nichts an der Tatsache, verschlimmbessert es sogar nur noch. Denn Threads sind auf Windows DIE Alternative wenn man asynchrone Sockets benutzen will. Und asynchrone Sockets benutzt man unter Windows zur TCP/IP Kommunikation deshalb weil diese mit den vorhandenen Sempahoren/Events (Signaling) zusammenarbeiten und diese wiederum nur mit Threads einen Sinn ergeben. Möchte man also sauber eine asynchrone und nicht-gepollte Socket Kommunikation haben, die das Gesamtsystem nur minimal belastet, so benötigt man unter Windows eben Threads. Verzichtet man darauf wie zb. in JAVA so kann man auch nicht mehr diese Art der Kommunikation des Betriebssystemes benutzen und zwangsläufig erhöht sich die Gesamtlast des Systems.

Das Einzigste was mir als Alternative einfallen würde ist das man innerhalb eines Threads mehrere Client-Sockets abarbeitet. Das ist dann aber keine Frage des OS oder der Programmiersprache mehr sondern nur eine Frage der Bibliothek die man benutzt zur Kommunikation. Sprich INDY oder was anders. INDY benutzt halt soviel wie ich weiß für jeden Client einen eigenen Thread. Ich persönlich arbeite nur damit (in kommerziellen Projekten) und hatte damit noch nie Probleme mit der Serverlast. Allerdings ist eine handfeste Aussage in diesem Punkt sehr schwierig, egal mit welchen Tools/OS man arbeitet. Eine wirklich sichere Aussage wirst du nur bekommen wenn du selber dein System unter Last real testest.

Gruß Hagen

[SubData]

Randinfo: Eine saubere, neue Apache Installation verwendet standardmäßig 250 Worker Threads für die Abarbeitung der Anfragen...

[negaH]

Zitat:

Na nee: Ich definier mir ein Array von Threads. Die werden niemals terminieren (außer bei Programmende). Ein Busyflag zeigt an, ob ein Thread gerade beschäftigt ist, oder nicht. Und wenn ein neuer Request von außen kommt, schau ich in der Liste nach, welcher denn frei ist. Der wird aktiviert und bearbeitet den Job. Wenn keiner frei ist, warte ich.

Hm ;) und meine Aussagen beziehen sich immer auf das Gesamtsystem. In diesem Falle gehe ich davon aus das die Socket Funktionen clevererweise die asynchrone/signaling Schnittstelle benutzen. Das ist der Weg den auch INDY geht und der die geringste Last produziert wenn man zb. auf Sockets, COM, USB etc.pp Schnittstellen warten muß. Unter Windows wohl gemerkt.

Aus dieser Sicht ist ein Thread-Pool erstmal direkt vergleichbar mit einer direkten Limitierung der zur Verfügung stehenden Sockets. Ob ich also nur 16 Threads in einem Pool alloziere = 16 Client-Sockets oder direkt nur 16 Sockets zulasse ist somit gleich bedeutend. Der einzisgte Unterschied ist nur das

1.) diese 16 Threads beim OS prealloziert werden können, sprich Resourcen reserviert werden
2.) die Allokationen solcher Pool-Threads sich beschleunigt, wie bei einem Cache.

Von der Limitation der Anzahl der Verbindungen her gesehen ist es aber gleich. Nur diesen Modus unterstützt INDY meines Wissens nach in seinem Pool.

Zitat:

Vermutlich stammt diese Zahl aus den Anfängen von Delphi, wo 486er noch gang und gäbe waren. Weiterhin dürften von 2000 Threads bei einem Portscanner 1999 warten, insofern sollte das nicht das Problem sein. Nur 2000 ständig laufende Threads zwingen nun jeden Computer in die Knie.

Stammen aus Delphi 5 Zeiten. Und exakt darum gehts hier auch bei der Frage. Denn in einer Socket Kommunikation ist eben das Warten auf Daten die zeitlich gesehen häufigste Operation. Es geht also um Serverlast und wie man diese gleichmäßig unter Windows verteilt. Und das geht über Threads die die meiste Zeit schlafen und erst aufwachen wenn sie asynchron durch das Socket API per Events aufgeweckt werden.

Ob nun 2000 Clientthread-Sockets auf einem Windowssystem mit JAVA, Delphi oder C# alloziert werden ist dabei irrelevant. Entscheidend ist das API das das OS zur Verfügung stellt. Hier also das Socket API und dessen Signaling und eben Threads.

Der Hinweis von Sakura ist also absolut korrekt, bezogen auf INDY.

Entweder eine andere Blibliothek statt INDY benutzen die es ermöglicht asynchron auf viele Sockets innerhalb weniger Threads zuzugreifen, oder eben wie Sakura es sagte die Zeitspanne der Clientverbindungen so kurz wie möglich halten. Das bedeutet das an an seinem Kommunikationprotokoll arbeiten muß. Sprich Sessionorientierte Clientverbindungen die zum Datenaustausch eben keine permanente Clientconnection benutzen sondern diese immer dynamisch aufbauen, Daten übertragen und sofort wieder abbauen.

Dies ist sowieso eine sehr gute Idee, egal ob man Windows oder Linux benutzt. Ich selber benutze nur diese Art der Kommunikation in meinen Systemen und wir hatten damit noch nie Serverlast Probleme. Viel kritischer waren da schon die Verbindungen zum SQL Server, der hat wirklich Nerven gekostet.

Gruß Hagen

[Lemmy1]

Zitat:

Zitat von negaH

a) muß zwangsläufig bei jedem Speichermanager auftreten. Speicherfragmentierungen sind auch garnicht das große Problem ansich.

Naja in einem Managed Heap kann man ja auch mal Objekte im Speicher verschieben (sprich: Defragmentieren). Insofern sehe ich dort das Problem als gelöst bzw fast gelöst an. Ich sag ja auch nicht, dass man immer in Probleme läuft. Aber ich hab halt auch noch nie einen Delphi-Server für 2 Jahre laufen lassen...

Zitat:

Zitat von negaH

b) ändert nichts an der Tatsache, verschlimmbessert es sogar nur noch. Denn Threads sind auf Windows DIE Alternative wenn man asynchrone Sockets benutzen will. Und asynchrone Sockets benutzt man unter Windows zur TCP/IP Kommunikation deshalb weil diese mit den vorhandenen Sempahoren/Events (Signaling) zusammenarbeiten und diese wiederum nur mit Threads einen Sinn ergeben. Möchte man also sauber eine asynchrone und nicht-gepollte Socket Kommunikation haben, die das Gesamtsystem nur minimal belastet, so benötigt man unter Windows eben Threads. Verzichtet man darauf wie zb. in JAVA so kann man auch nicht mehr diese Art der Kommunikation des Betriebssystemes benutzen und zwangsläufig erhöht sich die Gesamtlast des Systems.

Meine Aussage bezog sich ja nur darauf, dass es prinzipiell Unterschiede geben KANN. Da Du Dich offensichtlich mehr mit der Materie beschäftigt hast will ich Dir in diesem Fall ja auch gar nicht wiedersprechen :)

Zitat:

Zitat von negaH

Gruß Hagen

Grüße zurück

[sakura]

Zitat:

Zitat von Lemmy1

Aber ich hab halt auch noch nie einen Delphi-Server für 2 Jahre laufen lassen...

Keiner mit Verstand wird es tun, da ein Delphi-Server wohl immer auf Windows laufen wird und MS für Windows i.A. einmal im Monat den Patch'n-Reboot-Day veranstaltet :mrgreen: Aber zwei Monate (Email-Server auf Indybasis) ist meiner Erfahrung nach auch kein Problem.

...:cat:...

[Lemmy1]

Zitat:

Zitat von sakura

Zitat:

Zitat von Lemmy1

Aber ich hab halt auch noch nie einen Delphi-Server für 2 Jahre laufen lassen...

Keiner mit Verstand wird es tun, da ein Delphi-Server wohl immer auf Windows laufen wird und MS für Windows i.A. einmal im Monat den Patch'n-Reboot-Day veranstaltet :mrgreen: Aber zwei Monate (Email-Server auf Indybasis) ist meiner Erfahrung nach auch kein Problem.

...:cat:...

stimmt wohl.. :)

[negaH]

Zitat:

Meine Aussage bezog sich ja nur darauf, dass es prinzipiell Unterschiede geben KANN.

Ich weis und will dich und deine Meinung auch garnicht angreifen. Es geht darum WO die wirklich relevanten Unterschiede bei dem Problem eigentlich liegen, und das tuen sie

1.) beim Betriebsystem
2.) bei der Bibliothek die man zur Kommunikation benutzt -> INDY, Apache, Tomcat etc.pp.
3.) bei der Art und Weise wie man sein Protokoll aufbaut

Meiner Ansicht nach ist der 3. Punkt der entscheidende, egal welches OS, welche Programmiersprache oder Bibliothek man benutzt.

Zb. der Punkt das ein Server immer überlastet sein kann und wie dann das Protokoll darauf reagiert. Ist dieser Zustand in der Protokoll-FSM vorgesehen ? Wird der Client im Protokoll darüber informiert ? Bekommt der Client dann Informationen über seine Zeitscheiben um gezielt zu einem späteren Zeitpunkt seine Verbindung erneut aufbauen zu können ? Ist das Protokoll Sessionorientiert ? Verteilt der Server die zur Verfügung stehenden Resourcen geichmäßig auf die zu erwartenden Clients ?

Eines steht fest: egal was man benutzt technisch gesehen geht jeder Server in die Knie wenn er sehr viele Anfragen und Daten zur gleichen Zeit bekommt, ist ja zb. auch der Sinn einer DoS Attacke ! Ergo muß das benutzte Protokoll in jedem Falle auch darauf reagieren (bei wirklich großen Servern). Die einzigste Lösung in diesem Moment wäre eine Skalierung auf viele Servern um diese Last handeln zu können, denn die Grundlast exisitiert egal was man für Computer/Betriebsysteme/Bibliotheken und finally Programmiersprachen benutzt. Die Frage ist also nur ob die Bibliothek zur Kommnikation einem dabei unterstützt oder nicht.

Und INDY geht als Socket-Lib in diesem Punkt nicht weit genug, meiner Meinung nach :( Allerdings ist es auch nicht die Aufgabe einer Lib wie INDY solche Protokollspezifischen Sachen abzuhandeln. Somit ist ein Vergleich zwichen INDY und zb. Apache/Tomcat wiederum unfair, denn diese handeln eben solche Protokollsachen.

Gruß Hagen

[Elvis]

Zitat:

Zitat von negaH

Zitat:

a) Speicher-Fragmentierung
b) Java nutzt ein eigenes Thread-Management, und setzt nicht auf Betriebssystemthreads auf

a) muß zwangsläufig bei jedem Speichermanager auftreten. Speicherfragmentierungen sind auch garnicht das große Problem ansich.

Es muss nur in System auftreten, die keine Relokalisierung des Speichers ermöglichen. Java und .Net können das, da dort eine Referenz ein indirekter Zeiger ist. (Der nach der Relokalisierung auf eine neue Adresse weiterverweisen kann)