Jobs beschleunigen

[holgerscherer]

Wegen der nicht zufriedenstellenden Performance hatten wir etlich Berater im Haus. Und hätten wir diese Ratschläge befolgt, dann hätte es nur eine Lösung gegeben: Kauf einer neuen Hardware.
...
Erst informieren bzw. testen, nicht nur schimpfen.

Also, ich schliesse mich dem mal an. Immerhin gibt es zwei Grundsätze (nicht nur in unserer Branche), die gerne mal aufeinander prallen:
- viel hilft viel, oder: Hubraum ist durch nichts zu ersetzen
- a fool with a tool is stil a fool.

Man kann einerseits GiAPA nicht einfach installieren, laufen lassen und mit Knopfdruck sind alle Probleme behoben, andererseits kann man auch nicht immer nur ein paar Bricketts nachschieben und hoffen, dass es im Winter warm wird. Es braucht immer einen gesunden Verstand und die Nutzung des passenden Mittelwerts.

Man *kann* durch manuelle Analyse viel rausfinden, was auch GiAPA rausfindet, es ist eben ein gewisser Aufwand. Und man muss wirklich wissen, wo man schaut. Dieses Wissen ist in GiAPA eingebaut. Andererseits (um auf Fuerchau zurückzugreifen) kann das Ergebnis einer Analyse sein, dass man mal diverse hundert Programme redesignen und umwürfeln muss, damit das Ergebnis passt. Dann kann man auch einem Hardware-Broker ein paar Tausender in den Rachen werfen.
Und manchmal kann man durch relativ einfache Massnahmen den Anwendern auf die Finger klopfen, die beispielsweise exzessiv mit STRSQL und STRQRY arbeiten ;-)

Also vergessen wir lieber Wunderheiler und Wundertools und betreiben seriöse Arbeit.

So, nun genug zu dem Thema.

-h

[Fuerchau]

Es ist ja sehr schön, dass man Tools manchmal erst bei Erfolg bezahlen muss, das ist auch sehr lobenswert.
Allerdings sind die verfügbaren Hilfsmittel der AS/400 schon in (meiner Meinung) über 95% aller Fälle mehr als ausreichend.

Aber bei der heutigen Gigantomanie kommt man wohl ohne solche Tools nicht mehr aus da sich ja kaum noch einer mit den Details einer Anwendung auseinandersetzt.
Es gibt ja so schöne Entwicklerwerkzeuge (früher Case-Tools, bei meinem früheren Chef auch Käse-Tools), die einem ja bei der Programmierung so viel Arbeit abnehmen.

Aber auch hier gilt die Regel, ohne vernünftiges Design wird die Anwendung kaum performant laufen.

Performance-Tools zäumen das Pferd von hinten auf, da erst im Nachhinein eine Analyse durchgeführt wird.
Wie oft habe ich schon erlebt, dass das Softwarehaus keine Performanceengpässe bei der Entwicklung feststellt, da häufig nur mit wenigen Daten getestet wird.
Spätestens beim echten Einsatz zeigt sich dann gutes Design.

Aus meiner eigenen Erfahrung:
Wir wollten eine neuen Anwendung mit dem damaligen Signon entwickeln. Es hörte sich auch ganz gut an. Doch nach den ersten 3 Monaten zeigte sich das gewaltige Problem.
Die Programme unterschritten selten die 500KB-Marke, die Dateien enthielten reduntante Informationen ohne Ende.
Da das Ziel der Einsatz von 65 F02-Modellen mit 5 Terminals, 988MB-Platte und 1MB Hauptspeicher zum Preis von damals ca. 5Mio DM war, hätte hier tatsächlich nur eine Hardwareerweiterung um den Faktor 5! ausgereicht. Schlichtweg unbezahlbar.
Ein Performace-Tool hätte da überhaupt nichts gebracht, da das Design bzw. die Methode schon falsch war.
Nach einem neuen nativen Ansatz nach klassischen Methoden konnten wir das Ziel jedoch absolut ohne Probleme und Hardwareerweiterung lösen. Wir hatten sogar noch Platz auf den Kisten.

Die Anwendungen, die ich bis heute so kennengelernt habe, stehen genau vor dem gleichen Problem.
Massendaten verarbeiten mit Programmen, die eigentlich nur Dialogoptimiert sind.
Einsatz von SQL ohne tatsächlich mal die Zugriffe zu analysieren, usw. usw. usw.

Aber das ist ja meine ganz persönliche Meinung:
Mit den Methoden der vorhanden Leistungsüberwachung konnte ich bisher noch alle Probleme diesbezüglich lösen.