[Allegro] a99-Tempo im Netz

[Thomas Berger]

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

Lieber Herr Allers,

> Der Zustand ist durch Messung belegbar: die Flexdatei, die wir seit 
> Jahren für die Messung der Geschwindigkeit der a99-Prozesse 
> benutzen (siehe meine andere kürzlich an die Liste gesandte 
> Nachricht), gibt als für die Erledigung der Prozesse der 
> Mess-Flexdatei erforderliche Zeit 3 1/2 Minuten an. Der gleiche 
> Ablauf dauert auf einem Einzelplatz-PC 2 Sekunden, auf dem Netz der 
> Zentrale des Goethe-Instituts in München ca. 15 Sekunden, auf 
> einigen wenigen Goethe-Netzen im Ausland, wo ich das messen konnte, 
> ungefähr anderthalb Minuten.

Ich habe mit Ihrem Test-Flex einmal in verschiedenen Konstellationen
herumgespielt, und folgende Beobachtungen gemacht:

(a99-Problem): Die "disp"-Statements werden erst dann zuverlaessig
ausgefuehrt, wenn man nach Starten von a99 und vor Aufruf des Flex
mindestens einmal im Index war. Ansonsten werden nur wenige Datensaetze
angezeigt und auch nicht das ganze a99-Fenster aktualisiert, was im
Zeitverhalten der Ausfuehrung je nach Konstellation einen Faktor 2-4
ausmachen kann.

[Problem mit Ihrem Test-Flex: Es wird 100 mal der identische
Datensatz gespeichert, warum Sie ihn ueberhaupt modifizieren, ist
unklar: Schreiboperationen in den Index sollten bei Ihrem Test nicht
vorkommen, es wird eigentlich nur die Lesegeschwindigkeit, das Tempo
beim Anhaengen an die Logdatei sowie die Performanz beim Sperren der
Satztabelle getestet. Letztere ist vermutlich einer der wichtigsten
Faktoren ueberhaupt, sollte aber vielleicht besser mit separaten Tests
ermittelt werden, die das spezialisierte "set tbl loc" nutzen]

Deaktiviere ich die put-Statements, muss ich keycheck-Anweisungen
einbauen, damit (auch wenn der Index bereits geoeffnet worden war)
die Anzeige konsistent aktiviert wird.

Ich habe Ihren Test so umgestrickt, dass 500 verschiedene Saetze
mit aufeinanderfolgenden Satznummern jeweils die #24 bekommen und
unmittelbar darauf wiederhergestellt werden: Das scheint mir etwas
realistischer und reduziert wohl auch den Einfluss von Netzwerk-Caches.
Halbwegs realistisch (fuer *Bearbeitungen*) ist, dass nur wenige
Schluessel geaendert werden. Halbwegs unrealistisch ist, dass die
zu aendernden Saetze in der Datenbank (und daher meist auch in der
zugrundeliegenden .cLD-Datei) aufeinander folgen. Sehr unrealistisch
ist, dass stets dieselbe Aenderung gemacht wird.

Der Test muss mindestens zwei mal durchgefuehrt werden, beim ersten
Mal kann es durch die Verlaengerung der Datensaetze zu
Umspeichervorgaengen kommen, die u.U. sehr zeitaufwendig sind.
Solche Umspeichervorgaenge gehoeren zwar in ein realisitisches
Szenario, sind aber in Tests sehr schwer zu kontrollieren.

Der Test als solcher ermoeglicht zwar den Vergleich von ~irgendwas~
in verschiedenen Konstellationen, hilft aber nicht bei der Diagnose.

Variation von "display" bzw. "put"-Anweisungen ermoeglicht vorsichtige
Aussagen zur Lesegeschwindigkeit in der Datenbank (Nachladungen!)
und evtl. zur Schreibgeschwindigkeit (hier wuerde ich aber einen Test
mit Update und GM-Parametern vorziehen): Fuer ein "disp" muessen
v14-Ersetzungen mindestens einmal durchgefuehrt werden (jedoch auch
fuer evtl. explizit nachgeladene Saetze), fuer ein "put" stets genau
zweimal (Indexschluessel werden fuer die Varianten "vorher" bzw.
"nachher" des Datensatzes errechnet). Die eigentliche Verarbeitungszeit
fuer die Parameterdateien (mit Ausnahme von Nachladungen) halte ich fuer
vernachlaessigbar, die Systemzeit fuer die Anzeige des Satzes im Fenster
und die Aktualisierung aller a99-Anzeigen koennte hingegen einen
Einfluss haben.

Als Anzeigeparameter sollte man moeglichst einmal die Internanzeige
waehlen und dann die realen Anzeigeparamter, um die Effekte von
expliziten Nachladungen messen zu koennen.

Variation der Datensaetze (stets derselbe vs. viele verschiedene)
hilft evtl. dabei, Caching-Effekte beim Lesen zu minimieren.

Die Server- und Netzwerklast ausserhalb von allegro mag gerade in
Ihrer Situation einen ziemlichen Einfluss haben, dies kann man
vermutlich nur durch Tests zu unterschiedlichen Tages- und
Nachtzeiten dokumentieren.

Vor dem Durchfuehren sinnvoller Tests muss man (mit Mitteln des
Betriebssystems und weiterer Tools, z.B. filemon) sicherstellen,
dass man weiss, welche Aktivitaeten gerade die Dateien zur Datenbank
im Zugriff haben (ein "haengengebliebenes" Backup kann so ziemlich
jede Maschine in den Keller ziehen).



> Der Dialog mit den Netzadministratoren ist mal wieder minimal, 
> beschränkt sich auf deren Feststellung "... es liegt nicht am Netz, 
> nicht an den Leitungen, sondern an Allegro." Die wissen also 

Aussagen ueber Leitungen koenn ueblicherweise nur Spezialfirmen
mit entsprechender Testhardware machen: Ein Knick in einem Kabel
reicht, und alle koennen scheinbar unbeeintraechtigt mit Word arbeiten,
Datenbanken hingegen sind ploetzlich 10mal langsamer oder werden
instabil.


> beneidenswerterweise Bescheid, und ich bin vollkommen hilflos, kann 
> der Behauptung, daß der Umstand, daß das, was auf einem 
> Einzelplatz-PC 2 Sekunden dauert, in einem bestimmten Netz 3 1/2 
> Minuten braucht, allein in Allegro seine Ursache hat, wenig 
> entgegensetzen, weil ich vom Netzgeschehen verflixt wenig, in 
> Anbetracht der Umstände zu wenig, weiß.

Hier mal ein paar Messungen zum Vergleich
(jeweils 500 Saetze jeweils 2x gespeichert, nach jedem Speichern
"display", d.h. 1000 Schreib- und Anzeigevorgaenge: Die "kleine
Datenbank" ist die Demo-Datenbank, die "grosse Datenbank" ist
wirklich gross insbesondere mit 1,5GB grosser .cDX-Datei und
hat v.a. viele v14-Verknuepfungen. In der "kleinen" Datenbank
bewirkt die Modifikation an #24 die Aenderung eines Schluessels,
in der "grossen" von zweien)

			     klein	      gross
lokal 500 mal derselbe Satz ohne Modifikation zweifach gespeichert:
ln01	disp ohne put		  3		  3	
ln10	put ohne disp		  5		 11
ln11	put und disp		  6		 14

netz 500 mal derselbe Satz ohne Modifikation zweifach gespeichert,
Datenbank exklusiv:
nn01	disp ohne put		  2		  3
nn10	put ohne disp		 17		 73
nn11	put und disp		 19		 79

netz 500 mal derselbe Satz ohne Modifikation zweifach gespeichert,
Datenbank von anderem Rechner mit PRESTO geoeffnet:
sn01	disp ohne put		 42		 60
sn10	put ohne disp		 39		537
sn11	put und disp		 90		606	


lokal 500 mal derselbe Satz mit und ohne Modifikation gespeichert:
ls01	disp ohne put		  2		  4
ls10	put ohne disp		  5		 12
ls11	put und disp		  7		 16

netz 500 mal derselbe Satz mit und ohne Modifikation gespeichert,
Datenbank exklusiv:
ns01	disp ohne put		  2		  4
ns10	put ohne disp		 19		 80
ns11	put und disp		 20		 83

netz 500 mal derselbe Satz mit und ohne Modifikation gespeichert,
Datenbank von anderem Rechner mit PRESTO geoeffnet:
ss01	disp ohne put		 42		 59
ss10	put ohne disp		 57		559
ss11	put und disp		100		637


lokal 500 verschiedene Saetze mit und ohne Modifikation gespeichert:
lv01	disp ohne put		  3		  4
lv10	put ohne disp		  8		 11
lv11	put und disp		 10		 13

netz 500 verschiedene Saetze mit und ohne Modifikation gespeichert,
Datenbank exklusiv:
nv01	disp ohne put		  4		  4
nv10	put ohne disp		 23		 72
nv11	put und disp		 26		 76

netz 500 verschiedene Saetze mit und ohne Modifikation gespeichert,
Datenbank von anderem Rechner mit PRESTO geoeffnet:
sv01	disp ohne put		 39		 35
sv10	put ohne disp		 68		534
sv11	put und disp		107		558


Alle Zeitangaben in Sekunden. Es wurden jeweils zwei
Testlaeufe unmittelbar hintereinander ausgefuehrt, die
Zeiten des zweiten notiert: Umspeichereffekte sind daher
ausgeschlossen, Caching-Effekte maximiert.

Erste Schlussfolgerungen:
* Die Tests .s.. und .v.. sind nicht gut miteinander vergleichbar:
  Theoretisch sollte .s.. etwas schneller sein, der Einfluss der
  Tatsache, dass voellig unterschiedliche Datensaetze mit einer
  stark abweichenden durchschnittlichen Anzahl von v14-Ersetzungen
  stoert insbesondere die Zahlen fuer die "grosse" Datenbank.

* Vergleich n... und s... zeigt, dass auch Leseoperationen
  sehr stark beeintraechtigt sind, sobald die Datenbank von
  einem anderen Prozess auch nur (zum Schreiben) geoeffnet ist.

* Vergleich .n.. und .s.. zeigt, dass Schreibzugriffe auf den
  Index einen messbaren Unterschied machen. In realen Bearbeitungs-
  situationen wird dieser Einfluss staerker sein, letztendlich
  sogar ueberwiegen, vor allem bei Neusaetzen.

* Uebergang von "Lokal" auf "Netz" *sowie* von "Netz" auf "Netz
  mit anderen Datenbankzugriffen" bedeutet je nach Datenbankgroesse
  und Art der Daten *jeweils* eine Verlangsamung um den Faktor
  3 - 8, zusammengenommen also ca. 10 - 65, der sich bei realistischeren
  Schreiboperationen wegen der hoeheren Zahl von schreibenden
  Indexzugriffen sogar noch verschlechtern wird.

  Dies wohlgemerkt in einem Netzwerksetting, wo Client, Server und
  Leitungen mit nichts anderem als der Abwicklung dieser Tests
  beschaeftigt waren. In realen Netzwerken mag es daher noch weitere
  Verschlechterungen geben, die aber vermutlich nicht mehr besonders
  gravierend sind: Erreicht der Netzwerkverkehr eine Saettigung,
  ist zu erwarten, dass die Performance fuer alles drastisch einbricht,
  vom Server ist auch davon auszugehen, dass er bezueglich
  Arbeitsspeicher ausreichend dimensioniert ist um Lesezugriffe schnell
  bedienen zu koennen und dass Schreiboperationen nicht ueberwiegen
  (Kopiere ich auf dem Server nebenbei ein paar Gigabyte durch die
  Gegend, bricht die Performance des Serverdienstes recht dramatisch
  ein). Aus dem Bauch heraus wuerde ich maximal einen Faktor 5
  fuer die zusaetzliche Verlangsamung unter realistischer Last
  annehmen, alles dareuber fiele nach meiner Meinung dann bereits
  unter "Probleme" mit Netzwerk oder Server.

Die von Ihnen angegebenen 15 Sekunden im Goethe-Netz vs. 90 Sekunden
bei anderen Instituten (jeweils fuer die 100 Operationen in Ihren Tests,
nicht fuer 1000 in meinen Tests .n..) lassen sich moeglicherweise auf
den Unterschied zwischen "exklusiv" bzw. "geoeffnet von anderen
Plaetzen" in Kombination mit unterschiedlicher Server- und Netzbelastung
zurueckfuehren (Die 79 bei Test nn11 fuer die "grosse" Datenbank und die
90 bei Test sn11 fuer die "kleine" Datenbank sind zu nahe beeinander:
Man kann aufgrund des Testergebnisses nicht auf die Testsituation
zurueckschliessen). Dass jedoch in einer weiteren Installation noch
einmal mehr als doppelt so lange braucht, hat entweder seinen Grund in
einer bestimmten Auspraegung des Testes 26 (evtl. eine hoehere Zahl
expliziter Nachladungen, die sich beim "disp" stark auswirken) oder aber
es hat Gruende ausserhalb von allegro. Letztendlich muessen Sie aber
mit identischen Kopien einer Referenzdatenbank testen, um vergleichbare
Ergebnisse zu bekommen, das zeigen die Spalten "klein" und "gross"
meiner Messungen eigentlich recht eindrucksvoll.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDALRvENVh3bB0lwMRAgouAJ9glUfWfo1zJ18QayHk12vyPeSp4ACdEoCc
GLtqIAac3sDCZDFV6BkPLcM=
=peGn
-----END PGP SIGNATURE-----