Horst-Joachim Hoffmann ist freier DV-Fachjournalist in München

MÜNCHEN - "Meist beginnt Tuning dann, wenn der Patient schon im Bett liegt", so die Aussage eines Spezialisten in diesem Bereich der Millisekunden und Performance-Checks. Aber oft wird gerade dann nur bruchstückhaft verbessert, der Programmcode verdorben oder falsche Hardware zugekauft. Resultat: "Die Maschine wartet halt schneller".

"Viele Leute meinen, es sei Tuning, wenn man den letzten Rest Power noch aus der Maschine rausquetscht", meint Corina Retzbach, Marketingmitarbeiterin von VM Computer in Frankfurt zum Thema Tuning. Aber oft bringt auch eine größere Maschine, halbherzig eingesetzt, nicht die gewünschte Leistungssteigerung.

Tuning indes spielt sich in einem viel größeren Umfeld ab, in das nicht nur sämtliche Maschinenkomponenten, sondern auch der Mensch in der Organisation mit einbezogen werden müsse. Die generelle Frage sei, welche Ressourcen wann wo gebraucht würden.

So sei es eine Erfahrung, daß vormittags zwischen 11 und 12 Uhr und nachmittags zwischen 14 und 15 Uhr eine Spitzenbelastung auftrete. Hier könne vor allem im Online-Betrieb durch eine temporäre Umverteilung der Belastung viel Luft aus der Anwendung gelassen werden.

Auch Dr. Herbert Neumaier, Geschäftsführer der Interface Concilium GmbH, München, sieht das Anwendungsdesign im Softwarebereich als wichtigen Aspekt geplanter Tuningmaßnahmen an. So könne man mit der gleichen Hardware, aber einer Umstellung von beispielsweise fünf auf drei Operationen innerhalb einer Anwendungssequenz schon eine enorme Leistungssteigerung erzielen.

Hardwarebezogen könne hier eine Monitoranalyse erste Anhaltspunkte für eine Tuningmaßnahme unter Zeitaspekten liefern, aber in vielen Fällen sei auch eine entsprechende Accountinganalyse sinnvoll. Sie zeigt auf, wo reale Kosten in bezug auf den Ressourcenverbrauch allgemein entstehen, meint Frau Retzbach. Mit einem Monitor allein sei es allerdings häufig nicht getan. Dennoch bietet eine solche Hilfe erste Ansätze, um Engpässe aufzuspüren - allerdings, der quicken Elektronik stehen in vielen Fällen auch rein mechanische Hindernisse im Wege.

Aber, erläutert Neumaier, im Normalfall kaufe man sich den Monitor leider sowieso zu spät. Auch bei kleineren Systemen oder einem noch guten Grad der Zufriedenheit bietet ein solches Hilfsmittel Ansatzpunkte für laufende, nicht zu einschneidende Verbesserungen.

Es darf aber nicht vergessen werden, daß Softwaremonitore selbst einige Prozent Performancekraft verbrauchen. Dies ist besonders dann tragisch, wenn die Auslastung sich sowieso schon in Bereichen über 90 Prozent bewegt. Engpässe, meist physikalischer Art, tauchen am häufigsten in Netzwerken auf. Zu ihnen zählt in professionellen Netzwerken der Fileserver neben der Verkabelung an sich, erläutert Stefan Mutschler, Produktmanager von Adcomp, Unterhaching.

Ein Flaschenhals ist die Platten-Zugriffszeit

Einer der schwerwiegendsten Bottlenecks liegt in der mechanischen Zugriffszeit auf die zentrale Festplatte. Aber auch die Netzwerkkarte selbst bremst das System manchmal aus. Hier ist es insbesondere bei dem kollisionsbehafteten Ethernet-Protokoll wichtig, daß die Netzwerkkarte einen eigenen Speicher auf dem Board besitzt und der Prozessor mit eigener Intelligenz ausgestattet ist.

Abhilfe können hier teils die Betriebssysteme schaffen, die verschiedene Mechanismen eingebaut haben, um die Perfomance zu erhöhen - anders ausgedruckt, also um die mechanischen Engpässe zu umgehen. Hier ist zum einen das "Elevator Seeking" zu nennen. Im Normalfall erfolgen die Plattenzugriffe relativ chaotisch. Das Elevator Seeking sammelt einige kurz aufeinanderfolgende Zugriffswünsche und arbeitet sie sortiert und gebündelt von außen nach innen ab, um auf dem Rückweg einen zweiten gebündelten Lauf zu starten.

Zu den weiteren Mechanismen, die sehr speicherintensiv sind, zählt das "Directory Caching". Hier wird sofort beim Booten des File Servers das Inhaltsverzeichnis in den RAM-Speicher des Fileservers geladen. Da eine Operation grundsätzlich in der Art erfolgt, daß der Teilnehmer zuerst auf das Inhaltsverzeichnis zugreift, sich dort die Adresse besorgt und das System dann erst den eigentlichen Satz aufruft, ist einleuchtend, daß unter diesem Aspekt ein Zugriff gespart wird - eine Halbierung der benötigten Zeit wird erreicht. Ähnliches läuft bei dem sogenannten "File Caching" ab, bei dem das Betriebssystem selbst eine sogenannte dynamische RAM-Disk im Speicher anlegt, auf der die Bereiche geladen sind, die

oft angesprochen werden.

Unter "Directory Haching" wird der Suchalgorithmus im Inhaltsverzeichnis selbst optimiert. Im Normalfall wird der Name einer Datei im Inhaltsverzeichnis sequentiell abgesucht - eine Adresse an Stelle 100 bedingt also 99 Fehlgriffe. Mit dem intelligenten Suchalgorithmus des Directory Haching ist es möglich, diese Zahl der Fehlgriffe auf vier zu reduzieren - Nummer fünf trifft mit Sicherheit, so Stefan Mutschier. Ein entscheidendes Mittel, um die dahinsiechende Performance eines Netzes wieder auf Schwung zu bringen, ist aus diesen Gründen die Bestückung mit RAM-Speicher.

Aber auch Parallel Processing in intelligenten Netzen eignet sich zur Geschwindigkeitssteigerung. Hier werden Tasks an freie Rechner weitergeleitet und auch nach - prioritätsbedingter - teilweiser Erledigung weitergegeben. In gewissem Umfang lohnt sich aber auch die Anschaffung von netzorientierten Hardwarezusatzkomponenten wie zum Beispiel einem Disk-Koprozessor-Board. Diese Karte nimmt, der Zentraleinheit der Fileserver-CPU sämtliche Plattenzugriffe ab und bietet zudem die Möglichkeit, weitere Platten anzuschließen.

Haarig wird die ganze Tuningangelegenheit, wenn die Spezialisten feststellen, daß schlichtweg das physikalische Leitungsnetz an der oberen Kapazitätsgrenze ist. Die Kosten für eine Neuverkabelung, die oftmals notwendig wird, gehen enorm ins Geld. Auch hier ist die sinnvolle Abstimmung das A und O einer Kosten/Nutzen-Frage. Eine Glasfaserverkabelung kombiniert mit einem Netzwerkadapter, der nur eine Übertragungsrate von einem Megabyte pro Sekunde aufweist, käme wohl einem Goggo mit Breitreifen nahe.

Vor der Hardware die Software tunen

Bevor man sich aber der Problematik der Hardware zuwendet, sollten die Möglichkeiten eruiert werden, die Software zu tunen. In vier Ebenen teilt Dr. Herbert Neumaier, Geschäftsführer der Interface Concilium, München, die Software ein, die für eine Tuningmaßnahme in Betracht kommt. Dazu zählen die reine Systemsoftware bis hin zum Betriebssystem, dann die Applikationsbasis, zu der Neumaier Datenbanken oder auch Spreadsheets subsumiert, ferner die reine Anwendersoftware und letztlich das oben bereits erwähnte Anwendungsdesign.

Und hier beginnt nicht nur für den Münchner Experten die Gratwanderung, auf die man sich beim Tuning begibt. Abschätzungsprobleme wirtschaftlicher Natur sieht Günther Tolkmit, Marketing Manager der Software AG, Darmstadt. Bei vielen gängigen Befehlen sei es schlicht nicht möglich, ihre wirtschaftlichen Auswirkungen auf die Kosten einer Anwendung zu quantifizieren. Darüber hinaus verlangten viele Anwendungen exakt eine spezifische Vorgehensweise und seien schon deshalb nur schwer für leistungssteigernde Maßnahmen zugänglich. Bieten sich aber diese Möglichkeiten, so unterscheidet Neumaier bei nachträglichen Leistungssteigerungen zwischen "code-verschmutzendem" und "code-versäuberndem" Tuning. Bei der letzteren Art heißt es, bessere Algorithmen zu finden oder eine geschicktere Art, Schleifen zu durchlaufen. Man werde dadurch nicht nur schneller, meint Neumaier, sondern der Code auch sauberer.

Zu codeverschmutzendem Aufbohren der Software zählt Neumaier Datenredundanz, oder die Kopierung von Unterprogrammen zur Vermeidung von Callzeit. Der Effekt dieser Maßnahmen ist, daß sie dazu tendieren Riesenprogramme zu erzeugen, die letztendlich auf Kosten der Laufzeit und der Wartbarkeit gehen.

Das System flutscht wie Seife aus der Hand

Interessanterweise tritt bei unsauberem Tuning ein Rückkopplungseffekt ein, der weitere Maßnahmen zunehmend undurchführbar macht, denn je schmutziger ein Code ist, desto schwieriger ist er zu ändern oder zu beherrschen. "Das System flutscht auf einmal wie ein Stück Seife aus der Hand", veranschaulicht Neumaier. Das bewußte Mißachten grundsätzlicher Regeln des Softwareengineering wie starke Modularisierung, Beschränkung der Programmstatements auf maximal 50 je Prozedur, Schachtelungen bis maximal fünf Ebenen ist Anzeichen für verschmutzende Tuningmaßnahmen, die Crux des Vorgehens - vordergründig dennoch Zeitgewinne bringen.

Codeverbessernde Maßnahmen hingegen führen zu einem Punkt, an dem keine Veränderung in positivem Sinne mehr möglich ist. Zu den echten verbessernden Maßnahmen zählt auch, keine globalen Variablen, sondern nur "übergebene" zu benutzen, oder bei Routinen, die mehrmals durchlaufen werden müssen, Unterprogramme zu schreiben und sie nicht auszucodieren. Dies kostet zwar anfangs Zeit, aber die Mißachtung dieser Regeln ist enorm fehlerträchtig.

Tuningkatastrophe durch Code-Kopie verhindern

Ein Beispiel: Bei der Verwendung globaler Variablen arbeitet man mit impliziten Vereinbarungen, die in einem vordefinierten Speicherbereich abgelegt sind. Rückfragen werden deshalb bei der Entwicklung nicht mehr getätigt, so daß (unentdeckte) Fehler sich mit großer Geschwindigkeit fortpflanzen können.

"Tuning an sich ist aber nicht automatisch verschmutzend", meint Neumaier. Schon für die Softwareentwicklung hält er zwei Ratschläge parat. Er empfiehlt, beim ersten implementieren auch bei hoch zeitkritischen Systemen nicht auf die Performance, sondern mehr auf die Struktur zu achten. Erst im zweiten Schritt wird die gute Struktur zum Tunen herangezogen.

Sollte der Fall einer Tuningkatastrophe eintreten, so empfiehlt der Münchner, schon vorher eine Kopie des Ausgangs-Codes sicher abzulegen, um so eine Chance zu haben, auf dein unbearbeiteten, sauberen Originalprogramm neu aufzusetzen.