soft tricks

20.05.1983

Eine "Schnecke im Getriebe" beseitigten die Mitarbeiter der GEI GmbH aus Aachen in einem Warenbewirtschaftungssystem. Die Response-Zeit einer Tandem-Pathway-Anwendung wurde durch die Bearbeitung vieler Dateien für einen Arbeitsgang überproportinal erhöht. Da eine Aufstockung der Hardware aus Kostengründen ausschied, hieß es, die Software zu tunen. Wie das System zum Laufen kam-und die gewünschten Antwortzeiten erreicht wurden-, beschreiben die Aachener Tüftler in ihrem Beitrag.

Ein typischer Fall: Im Pflichtenheft für ein großes Warenbewirtschaftungssystem waren die Response-Zeiten für die Bildschirme auf durchschnittlich ein bis zwei Sekunden für einen Rechnungseintrag festgelegt worden. Durchaus realistisch, sogar drei Zehntel Sicherheit sind drin, errechnete man in der Angebotsphase. Die Realisierung begann und für den Kunden ergaben sich täglich neue Perspektiven und Erweiterungsmöglichkeiten, die er sich offenhalten wollte. Die jetzt geforderte Flexibilität bei allen Belegen für die Ein-und Ausgabe erforderte eine Datenbasis, die auch bei Ausbau und Erweiterung nicht berührt zu werden brauchte. Daraus resultierte, daß für die Bearbeitung eines Vorganges viele Dateien angepackt werden mußten- und das erhöhte die Response-Zeiten an den Bildschirmen. Eine Aufstockung der Hardware schied aus Kostengründen aus.

Die einzige Möglichkeit lag im Tuning der Software. Man maß die Abarbeitung der Bildschirmeingaben aus und stieß bald auf eine Schnecke im Getriebe. Immer dann, wenn Aufgaben gemeinsam von den Zugriffsroutinen und dem Terminal-Interface erledigt wurden, stiegen die Response-Zeiten drastisch. Offenbar wurden die Übergänge hier vom

System unverhältnismäßig langsam bearbeitet. Es stellte sich heraus, daß vor und nach jedem Aufruf einer Zugriffsroutine (Server) durch das Terminal-Interface (Requestor) zusätzliche Plattentransfers durchgeführt werden, die die Non-Stop-Eigenschaften des Systems sicherstellen. Im ungünstigsten Fall ergibt sich hierbei eine Verfünffachung für die Plattenzugriffe. Außerdem fand man heraus, daß Base-Screens mit Overlays viel Zeit kosteten, es ging sogar schneller, eine neue Base-Screen herauszugeben, als nur einige Zeilen auszuwechseln.

Folgende Tuningmaßnahmen machten die Tandem-"Pathway"-Anwendung wesentlich schneller:

1. Bildschirmmasken wurden nur durch Base-Screens realisiert, Overlays sind zu langsam. Dafür ist allerdings eine umfangreichere Datenhaltung im Requestor notwendig.

2. Entscheidungen und Berechnungen zum Zweck von Bildschirmausgaben werden nur dann in den Requestor gelegt, wenn die dafür notwendigen Daten und Informationen schon im Requestor vorhanden sind oder durch einen Dateizugriff (Server-Aufruf) zu beschaffen sind.

3. Entscheidungen und Berechnungen, die eventuell eine Veränderu(...)

der Datenbasis zur Folge haben oder auf Informationen aus mehreren Dateien und Datensätzen beruhen, wurden soweit wie möglich in die Server-Programme verlegt, um den Meldungsverkehr Requestor - Server klein zu halten.

Beispiel:

a) Updates von Datensätzen wurden an den Server übergeben. Den eigentlichen Update (Lesen, Ändern, Schreiben) führt der Server durch.

b) Bildschirmausgaben mit Informationen aus mehreren Datensätzen werden über Sammelabfragen vom Server an den Requestor gegeben.

4. Die Pathway-Konfiguration wurde den realen Bedingungen entsprechend modifiziert.

Diese ziemlich rasch durchgeführten Software-Tunings reduzierten die durchschnittliche Response-Zeit auf die Hälfte und waren schon daf(...) verantwortlich, daß die Anforderungen des Pflichtenheftes wieder eingehalten wurden.