[Allegro] acon/avanti : Performance unter Linux

[Thomas Berger]

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

Lieber Herr Eversberg,

> Steht der Server etwas unter Last, faellt die Sache nicht so ins
> Gewicht, fuer die beobachteten mindestens 2 Sekunden Verarbeitungszeit
> gibt es mindestens noch eine weitere Ursache, der ich spaeter
> nachgehen werde.

Nein, es ist dieselbe Ursache:

Zunaechst eine Korrektur: ein listen() koennte einen Timeout-Parameter
bekommen (nicht das accept, da war ich vorhin unpraezise), avanti arbeitet
aber ohne listen()...

Jedenfalls, wenn eine Verbindung zum avanti-Server initiiert wird,
werden drei Pipes eroeffnet, avanti forkt() und ... startet sich dann
extern (!) neu als "avanti -slave", was dann nichts weiteres tut als
einige Pipes zu eroeffnen und dazu dann jeweils eine Shell (!) und
indirekt durch diese je ein zugehoeriges acon aufzustarten.

Waehrenddessen versucht der Serverprozess (!) von avanti, Daten
der einkommenden Verbindung per Pipe zum Slave-Avanti zu schaufeln
(das die dann an eines der Shell/acon-Tandems weiterleiten wird, deren
Ergebnisse landen allerdings direkt beim Server-Avanti und werden von
dort an den Client weitergereicht). Liegt hier entweder noch nichts an
(normalerweise wird ja erst das erfolgreiche connect() abgewartet und
dann erst Daten geschickt) oder der avanti-Slave ist noch nicht bereit,
gilt das noch nicht als "Arbeit" und der Server-Prozess legt sich erst
einmal wieder fuer eine Sekunde schlafen.

Und je nachdem, wie schnell die 100 Leerversuche nach dem Uebertragen
des Jobs durchlaufen sind (und ich vermute: sehr schnell), muss auch
erst wieder eine Sekunde vergehen, bevor das Ergebnis von acon
eingesammelt und weitergereicht wird.

Die Sache ist ziemlich verfahren, weil avanti nicht nur ein
schulbuchmaessiger forkender Socket-Server sein soll, sondern
gleichzeitig auch noch ein allgemeiner a(?)synchroner I/O-Multiplexer
(was v.a. damit zu tun hat, dass bereits im Ur-Avanti eine Windows-
spezifische Loesung mit asynchroner IO und Threads nach Unix zurueck-
portiert wurde). NATUERLICH ist es eigentlich nicht die Aufgabe
von Serverprozessen, nach erfolgter Aufgabenverteilung die gesamte
I/O aller Kindprozesse in beide Richtungen (plus STDERR) zentral
an sich zu ziehen, zumal in der Logdatei im Fall von Parallelitaet
ja doch nur eine unentwirrbare Mischung landet.

Nach POSIX allerdings sollte ein select() auch ueber einen Mix
von Socket- und Pipe-Deskriptoren moeglich sein, wie das in
Windows und Solaris etc. aussieht, weiss ich allerdings nicht.


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

iJwEAQECAAYFAk1IfQAACgkQYhMlmJ6W47PbGwP+JHOQnq0Kopro5oIAsTGkAo3S
WJRtbq7mqLAZXwohewv0g74boPdK/mroXmY+U6JYEucmxgZHbGsHyI8FDkxdyvRZ
hY2Od3U0pYc6g+9EwiulVpO9oxxUR6UCGpdcs34vKpidhAVgqms0pyXbAqT+G71q
fv7f7cjEaCjmVMj8uzE=
=WPng
-----END PGP SIGNATURE-----