AW: avanti-cl: Programmdatei erneuert

[Thomas Berger]

Volker Bachschneider wrote:

> Andere Konstruktionen, wie FIFO´s (Named Pipes) oder Sockets haben diese
> Einschränkung (halbduplex) nicht, sie unterscheiden aber bekanntlich
> zwischen einem Blocking und einem Nonblocking (asynchronen) Mode.

Nein. Nonblocking ist nicht asynchron. Das ist FUD von $Bill.
Man kann mit select() durchaus Daten lesen, ohne sich dabei
permanent aufzuhaengen. Das ist auch das Prinzip hinter Medusa.
Asynchron braucht man, wenn man nebenher im gleichen Thread
noch andere Dinge erledigen will, dann kann es unter Umstaenden
in einem asynchronen Modell auch eine logische Vereinfachung
geben.

> Herr Höppner schlägt nun weiterhin ein Verfahren vor, das sich Message Queue
> nennt, mithin eine verkettete Liste die message-Typ, message-Länge und
> Message-String mit sich trägt.

Message-Queues sind in der Windows-Welt das, womit man asynchrone
Mechanismen nutzen kann (soweit ich das verstanden habe): 
Ein asynchroner Lesevorgang ist logisch gesehen ausserhalb
jeden Threads und muss die Daten, die er empfaengt, wiederum
in eine Message-Queue einhaengen, damit sie nicht verloren 
gehen. Falls irgendein Zwischenstand erreicht ist, arbeitet
der eigentliche Thread dann die Daten aus dieser Queue
sukzessive ab.

 
> Es wird unschädlich sein, das alles zu überlegen, aber schon beim normalen
> Avanti habe ich festgestellt, daß Blockgrößen um 2048 - 4096 optimal sind
> und der Overhead für andere Strategien zu teuer ist, zumal wir ja mit TCP/IP

Typische Blockgroesse in LAN's ist mindestens 8192, aber es wird sowieso
alles doppelt und dreifach zwischengespeichert, durchs System, durch
den Skriptinterpreter etc. Man sollte die Blockgroesse nicht zu klein
waehlen, weil sonst noch ein paar unnoetige Umspeichervorgaenge
(und Wartevorgaenge) provoziert werden, andererseits auch nicht zu
gross,
weil man sonst nach laengerem Warten viele Daten bekommt, die man selbst
erst wieder laenglich verarbeiten muss.


> Avanti-cl anders arbeiten und das Verhältnis zwischen Up- und Downstream in
> Balance sein.. Bei find beispielsweise verbraucht das Einlesen des Index
> gewiß die längste Zeit. Also: kleinere / geteilte Indices == schneller. Und
> / oder zwei Threads einer liest und der andere sucht und schreibt schon mal.
> Wenn man sich aber daran gewöhnt hat ist qrix eh der bessere Zugriff.
> Apropos Thread´s. Ich habe Avanti-cl mal threaded unter Win98 betrieben. Bis
> zu 10 Thread´s (Avanti-cl-Prozeße) ist man immer auf sicheren Seite, ab 40
> Thread stirbt mein System. Langlaufende Prozesse  sollte man daher immer

Windows'9x hat m.E. da gewisse Limits...


> Die meisten Vorteile verspreche ich mir von Client - AppServer - DBServer -
> Konstruktionen (Three Thier Model), wo gewisse Zustände auf dem AppServer
> zwischengelagert werden. Also Caching oder vorausschauendes Laden.
> Beispielsweise holt man gleich 3 Seiten Registerauszug überträgt aber nur
> eine. Das schont Bandbreite etwa bei schmalbandigen Zugängen wie dem
> Internet. Überhaupt ist der Bereich von Anwendungen auf der Ebene der
> Middleware (AppServer) mit Webservern + PHP o.ä. überhaupt nicht ausgereizt.

Nadeloehr ist meistens das Prozess-Starten. Ich koennte mir vorstellen, 
dass ein avanti-cl, das sich nicht beendet, sondern nur
neuinitialisiert,
bis es tatsaechlich ein EndOfFile oder ein "Geh Sterben"-Kommando
bekommt, sogar schneller waere als avanti-w.
Besonders gut koennte ich mir vorstellen, dass ein procav/avanti-cl, das
die .CFG und .API etc. nur einmal einliest, gewaltige Vorteile bringt
(und der Nachteil ist nur, dass man eine zweite Verbindung zu
avanti braucht, wenn man in der selben Sitzung eine zweite 
Datenbank abfragt).


> eigenständiger Socketserver auf Medusabasis fällt vielleicht mal im Urlaub
> ab. Man sollte auch mal auf die Fortschritte von Twisted schauen. (habe ich
> schon länger nicht mehr beobachtet)

Mein Eindruck ist, dass Medusa eine etwas von Eigenlob strotzende
Neuerfindung des bekannten inetd ist und nur dann Sinn macht, 
wenn die dahinter liegenden diversen Server alle staendig leben. Hier
jedoch geht es immer um einen einzigen Server, der immer nur
als Einweg-Loesung benutzbar ist, bevor er neu gestartet werden
muss. Aber vielleicht habe ich da etwas falsch verstanden.
Ich habe aber beim Lesen der Dokumentation nicht unbedingt den
Eindruck gewonnen, dass es ein Werkzeug zur Serverifizierung
von Nicht-Servern ist, obwohl man evtl. mit Medusa etwas
bauen kann, was mehrere avanti-cl quasi auf Vorrat schon
einmal aufstartet und einkommende Anfragen dann auf einen
der Prozesse verteilt.


> PS: Herr Berger, was sagen Sie denn?

Ooops. S.o.

viele Gruesse
Thomas Berger