[Allegro] acon/avanti : Performance unter Linux

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

>> Fuer mich heisst das allerdings, dass man den bestehenden avanti
>> trotz all seiner Maengel gruendlich flicken und am Leben erhalten
>> sollte, ...
>>
> Irgendwie passt das nicht recht zusammen, oder Sie haben mit "unrettbar"
> wieder mal Ihr Stilmittel der grotesken Übertreibung bemüht. (Was
> den nicht ganz so tief in der Materie steckenden Leser unrettbar in
> Verwirrung stürzt, und das können auch Sie nicht wollen. Wäre das hier
> eine Entwicklerliste, würde ich nix sagen.)
> 
> Mit "prefork" hatten Sie aber recht, es ist momentan auf 10 gesetzt
> (über die Konstante MAXFORK). Ändere ich das auf 1, bemerke ich aber
> hier keine Änderung des Reaktionsverhaltens.
> Aber wer rafft sich auf und versucht sich dran, eine geradere Gurke
> zu machen?

Unter Windows benutzen Sie "Sleep(1)", das ist eine Millisekunde
(oder Mikrosekunde: Das waere sehr knapp), unter Linux "sleep(1)"
das ist eine Sekunde und damit deutlich zu lang.

Wenn Sie da zu einheitlich gesunden Werten (ich wuerde vorschlagen:
irgendwo zwischen 1 und 10 Millisekunden) gelangen, ist das
Problem beim Antwortverhalten (fundamtental immer noch dasselbe)
praktisch nicht mehr sichtbar.

Auch koennten Sie das Setzen von "idle = 0" nicht davon abhaengig
machen, dass erfolgreich Daten verschoben wurden, sondern dass
es I/O-Conditions gab.



>> Prioritaet sollte m.E. haben, dass acon (zu gegebenem Aufrufpfad und
>> Datenbank etc.) in der Lage ist, mehrere Jobs nacheinander zu
>> verarbeiten: Dann koennte avanti einen Pool von acons am Leben
>> erhalten und jeweils die benoetigten einer spezifischen
>> Client-Verbindung zuteilen: Das waere effizient.
> Sicher, haben wir auch vor langer Zeit alles mal durchdacht. Scheiterte
> dann aber doch an Komplexität, und es wurde acon als separates und
> relativ schlankes Jobverarbeitungsprogramm geschaffen (zunächst

Das Starten eines Prozesses ist teuer genug und auf meinem Linux-
System finde ich wenige Binaries, die noch groesser sind als acon:
Soviel zu "schlank". Das ~Oeffnen~ einer Datenbank mit dem dazu
erforderlichen Oeffnen einer Vielzahl von Dateien wird allerdings
wesentlich teurer sein als das reine Aufstarten von acon.

Hier fuehrt dann einerseits das bisherige Avanti-Protokoll
nicht weiter, das erst ganz zum Schluss klaert, welche Datenbank
gemeint ist und daher auf uninitialisierte acons angewiesen ist,
andererseits lohnen sich aber Optimierungen mit Prefork und
anderen Ansaetzen auf avanti-Ebene erst, wenn durch mehrfach
nutzbare acons das Potential hierfuer gegeben ist. Innerhalb
der Klassenbibliothek muesste sich eigentlich die Stelle
ausfindig machen, wo die grundlegende Initialisierung (.CFG
Lesen, .api Lesen, Datenbankdateien oeffnen) in die eher
als dynamisch aufzufassende (Anzeige/Export/Druck-Parameter laden,
Arbeitsspeicher initialisieren, Flexe und Jobs ausfuehren)
uebergeht...

viele Gruesse
Thomas Berger



> avanti-cl genannt). Und avanti selbst hat dann ein anderer neu
> geschrieben, wobei auch das Ziel war, daß avanti unberührt bleibt von
> eventuellem Absturz oder Hängenbleiben eines Jobs. Genau deshalb wird
> avanti mit -slave dann neu gestartet, übernimmt die Verbindung zum

... nach dem fork() ist es bereits ein neuer Prozess, der sich dann
allerdings damit vergnuegt, sein eigenes Image per execv erneut
einzulesen und zu initialisieren...

> Auftraggeber, nabelt sich ab vom avanti-Server und startet acon, dem

eine Shell, die acon startet, an die

> es den Job übergibt usw.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk1JLooACgkQYhMlmJ6W47PerAP/fj4vAhG0NcYdqgT0rVKcCsBT
PFaKi6ZqiI+Y8JV2ZfeMOQlIx7gqnS5cZbBGJZEmsjXF0itoLRtZ3mCtu1jnzihz
9lojhbq+uHpSzzEZUhCtKbO3R9CZka6AEznzvli9D1uEL/2rn7CorVAZiUEh6uoy
g3O7+8iiZVBicaluCWI=
=H3/Z
-----END PGP SIGNATURE-----