[Allegro] acon/avanti : Performance unter Linux

[Thomas Berger]

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

Lieber Herr Eversberg,

> Es wäre nun aber eine reizvolle und überschaubare Aufgabe, ein neues
> avanti zu schreiben. Das müßte nicht in C, es könnte durchaus in Java
> oder Perl geschehen, weil ja avanti selbst mit der Datenbank nicht
> direkt etwas zu tun hat, sondern dafür acon bemüht, an welchem man
> nichts ändern müßte. Das ist mit ein Grund, warum wir avanti als
> ersten Quellcode freigegeben haben. (Das jetzige avanti hat seinerzeit

D.h. Sie haben den avanti-Quellcode veroeffentlicht, weil er
ueberfluessig ist?

Nachdem ich gestern eine Stunde in den knapp 4000 Sourcezeilen von
avanti gewuehlt habe, teile ich Ihre Einschaetzung: Es ist eine
Standard-Fingeruebung nach Lehrbuch, die dennoch unrettbar vergurkt
ist und daher eine Neukonzeption erforderlich macht.

Der Vergleich mit dem YAZ-basierenden ZTarget zeigt einiges, wie
man es besser machen kann: In der Log-Datei landen zusammenfassende
*Zeilen* (Messages), das kann auch durch mehrere Prozesse simultan
erfolgen. Ausfuehrliches Mitschreiben der Kommunikation etc. ist
separat anschaltbar und erfolgt in prozess-spezifischen Einzeldateien,
da ist dann (zumindest bei weniger als 64.000 Jobs pro Sekunde)
ebenfalls kein Konfliktpotezial mehr.

Unscharf ist, wie avanti und/oder acon mit den Meta-Zeilen
& Virtueller Aufrufpfad
@ Datenbank und virtueller Benutzer
sowie der conf-Datei umgehen: Das sollte sauber getrennt werden
in dem Sinn, dass nur avanti dafuer zustaendig ist und acon
ueberhaupt nicht. Derzeit kommen die wichtigsten dieser Meta-
Informationen jedoch am Ende des Jobs, so dass avanti (als
avanti -slave) gar nichts anderes uebrig bleibt als alles mitzulesen.

Avanti haelt derzeit die Socket-Verbindung zum Client, auch wenn
mehrere Jobs abgewickelt werden, das ist schon einmal gut. Es muss
aber fuer jeden Job einen eigenen acon-Prozess starten, der sich
datenbankspezifisch initalisiert: Das ist sehr aufwendig.
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.

Wo Aenderungen im "Avanti-Protokoll" unumgaenglich sind, lohnt
es sich darueber nachzudenken, ob man nicht auf HTTP (mit DAV?)
umstellt: Beispielserver-Code sollte genuegend verfuegbar sein
und man haette den Vorteil fuer hochperformante Webservices
ganz auf Middleware verzichten zu koennen.

Fuer mich heisst das allerdings, dass man den bestehenden avanti
trotz all seiner Maengel gruendlich flicken und am Leben erhalten
sollte, denn der Nachfolger sollte eben nicht aus Neuprogrammierung
sondern aus einer Neukonzeption der ganzen Angelegenheit erwachsen.

viele Gruesse
Thomas Berger

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

iJwEAQECAAYFAk1JHy0ACgkQYhMlmJ6W47NF/wQAuuZIUm8b/ehuZXNt1dCcThQj
ly0YlJbvL/aj77qNLvgBgpO7u/0vUO+R0lSlk1k2MWlk5puiF+OYoiNHD1wBx+h0
CywvMC3l5r1PByGPkxh0qgIVAtqzD6QBk4iPQwc9ILQEAx3qLEJ3RWdJDmGOG+KC
Hstte+FEIQadK2abb4A=
=evWA
-----END PGP SIGNATURE-----