AW: Vb.162: avanti-w verbessert

[Thomas Berger]

Lieber Herr Hoeppner, liebe Liste,

> Hat überhaupt jemand schon mal einen Vergleich gestartet, um herauszufinden,
> welcher Teil eines Auftrages an avanti die meiste Zeit kostet? Ich meine
> damit das Verhältnis von Laufzeit der Daten über das Netz zu eigentlicher
> Abarbeitung des Jobs. Ein Bauchgefühl sagt mir, das Netz ist der
> Flaschenhals. Aber ich gebe selbstverständlich zu, dass ich das nicht
> untermauern kann.

Ich habe hier nie systematisch testen koennen, teile aber
gerne mein anekdotisches Wissen:

- HANS-Datenbanken, wo jedes Komma aus dem Index nachgeladen
  wird (kein Scherz), sind subjektiv auch nicht langsamer
  als andere, hier wirkt wohl auf allen Plattformen, dass
  die relevanten Indexausschnitte meist im Plattencache des
  Betriebssystems sind.

- Fuer eine Praesentation Anfang 1999, wo avanti grosse
  Datenmengen (4stellige Ergebnismenge) in XML exportierte,
  mussten wir kurzfristig von der urspruenglich eingeplanten
  Sun auf mein Pentium-233-Notebook umziehen, weil die
  Antwortzeiten besser waren (und das shared-Memory
  nicht ausreichte, das musste damals ja so ueppig 
  dimensioniert sein, dass das gesamte Ergebnis
  hineinpasste)

- Fuer einen RTF-Export aus avanti-x heraus musste das
  Job-Timeout bereits bei ca. 500 Ergebnissen auf einer 
  Sun von 60 auf 120 Sekunden erhoeht werden, HTML-
  Export derselben Menge kein Problem.

- Schiller-Raeuber-Suchen und solche, die Restriktionen
  benutzen sind sehr langsam (zumindest bei grossen
  Datenbanken, ich denke da an eine mit 800.000 Saetzen),
  bei Zwischenergebnissen im 5stelligen Bereich reichte
  hier auf einer Sun das Job-Timeout von 60 Sekunden
  nicht aus (Resultat ca. 10.000 Satznummern)

Ich habe oft den Verdacht gehabt, dass Performance und
auch Stabilitaet von avanti nicht unbedingt von der
Datenmenge abhaengen, sondern von der Anzahl der Zeilen
des Resultats. Also vermutlich von der Anzahl der
Operationen mit Shared Memory, nicht vom Volumen, das
dort durchgeschleust wird. Das ueberrascht mich auch
nicht besonders, weil Shared Memory ja nie dazu gedacht
gewesen ist, Daten von A nach B zu uebertragen und
(vor allem unter U**X) als ausserordentlich langsam
gilt. Ob es zusaetzlich im Socket-Kommunikationsteil
eine Strafe fuer Zeilen gibt (wegen gebuffert /
ungebufferter I/O, also etwa pro Zeile ein Packet) 
kann ich nicht beurteilen.

viele Gruesse
Thomas Berger