Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

06.07.1979

Was leisten Benchmark-Tests?

Benchmarks sind das sinnvollste Mittel, um die Leistungsfähigkeit einer Anlage zu testen. Sie haben Jedoch ihre Grenzen .- auch müssen bestimmte Regeln beachtet werden. Man kann die folgende Unterteilung vornehmen: Standard-Benchmark: Nicht selbst angefertigte Programmauswahl, zum Beispiel die Auerbach Kernel-Sammlung.

Künstlicher Benchmark: Selbst angefertigter Benchmark (oder gewissenhafte Auswahl aus Standard-Benchmarks), der nicht der laufenden Produktion entnommen wurde. Echter Benchmark: Ausgewogene Auswahl von Programmen der eigenen, laufenden Produktion. (Anwendungsverschiebungen können so natürlich nicht berücksichtigt werden.)

Einige Regeln, die bei der Benchmarktest-Durchführung als sinnvoll gelten, sollen kurz erörtert werden:

- Die Testanlage muß möglichst genau der Angebotsfiguration entsprechen. Falls bei der Testkonfiguration eine Systemtrenneinheit zur Verfügung steht, muß der Tester die Konfiguration zum Zeitpunkt seines Tests selbst genau überwachen.

- Die Testanlage muß für die Testzeit nur für den Benchmark zur Verfügung stehen. Der Benchmarktest muß soviel Programme enthalten, daß verschiedene Grade von Multiprogramming getestet werden können. Hierzu muß ein Testplan vorliegen

- Zeiten müssen zur Sicherheit auch mit der Stoppuhr gemessen werden (Durchsatzzeiten).

- Es muß ein möglichst detaillierter Output der Accountig-Routine verlangt werden: Zum Beispiel CPU-Zeit, Kanalzeit, EXPCPs, Turnaround-Zeiten, praktisch die gesamten Accounting-Auswertungen.

- Aus den bisher genannten Regeln geht hervor, daß die den Test betreuenden Personen unbedingt Detailkenntnisse der Architektur, des Betriebssystems und des Accountigs der zu testenden Anlage vorher erworben haben müssen. Diese Vorgehensweise kann eventuell ziemlich kostspielig werden, so daß kleine Anwender oft nur den Test spezifizieren und alles andere dem Hersteller beziehungsweise dessen Testcenter überlassen.

- Während des Tests sollte man die Gelegenheit wahrnehmen, die Konfiguration der Testanlage systematisch zu variieren:

- Hauptspeicher zuschalten oder abschalten in den üblichen Inkrementen.

- Zweitprozessor zuschalten oder abschalten, falls das Systemkonzept dies auf einfache Art und Weise erlaubt.

- Peripheriezuordnung variieren.

- Betriebssystervariationen vornehmen lassen (zum Beispiel residenten Teil größer gestalten oder kleiner) oder

- Betriebsystem auswechseln. Zum Beispiel von OS/VS1 auf OS/MVS oder dergleichen.

- Zu - oder abschalten von Cache - Teilen.

- Zu oder abschalten von I/O-Prozessoren.

- Alle Variationen müssen genau registriert werden.

- Der Testaufenthalt sollte zu einer Erhebung genutzt werden.

Die Vorteile und Nachteile von Benchmarktest sollen nun kurz geschildert werden.

Vorteile

Relativ sichere und gängige Methode bei batchorientierten Anwendungen.

Die Zusammenstellung der Tests bereitet meist keine großen Schwierigkeiten und kann schnell erfolgen.

Man kann leicht I/O-intensive und oder CP17-intensive Tests oder Mischungen zusammenstellen. Fortran-, Cobol- oder Algol-Orientierung erleichtert das Testen auf verschiedenen Anlagen. Neben der Hardware werden auch Softwareeigenschaften integral beurteilt.

Nachteile:

Benchmarks sind batchorientiert ; und nicht TP-orientiert. Falls in Zukunft hochgradig auf -IP-Anwendungen umgestellt werden soll, können Benchmarktests mit existierenden Batch-Programmen nur begrenzte Aussagen liefern. In diesem Falle helfen Detailkenntnisse der Systemarchitektur einer Anlage (ob sie favorisiert ist für TP- und Online-Anwendungen oder nicht), ferner Erhebungen und Anwenderbefragungen sowie Simulationen der Terminalanwendungen.

Ebenso können Benchmarks nur schwer für Spezialanwendungen zusammengestellt werden:

Echte Realtime-Anwendungen sind so kaum zu testen, zum Beispiel Flugüberwachung, Reservierungssysteme, Prozeßlenkungssysteme. Auch Datenbankanwendungen sind per Benchmark schwer, das heißt kostenaufwendig, vorab zu testen. Grund: Fehlende Normierung auf diesem Gebiet als einheitliche Grundlage. Assemblerprogramme können nicht in Benchmarks einbezogen werden, falls nichtkompatible Anlagen verglichen werden sollen.

Benchmarks können Verzerrungen liefern, falls sie - absichtlich oder unbedacht - nicht entsprechend dem augenblicklichen oder erwarten Anforderungsprofil zusammengestellt werden. Beispiel: Bevorzugung von Programmen, die Dezimal-Arithmetik wünschen, wenn reine Binärrechner und Binär-/Dezimalrechner in der Auswahl stehen, aber ein gemischt wissenschaftlich/kommerzielle Arbeitslast vorliegt.

Hieraus resultiert die Gefahr der Manipulation.

Sehr empfehlenswert sind umfangreiche Befragungsaktionen bei Anwendern mit einem gleichen oder ähnlichen Aufgabenspektrum zum Beispiel anläßlich von Tests. Die Erhebungen müssen gut protokolliert werden, ein präziser Plan der Befragung muß vorliegen:

- Welche Bedingungen führten bei Ihnen zum Computerwechsel von ABC zu XYZ?

- Wie war die Unterstützung bei der Umstellung?

- Wie schätzen Sie den Servicegrad und Ausbildungstand der Wartungstechniker ein?

- Welche Reaktion erfolgt bei Field Reports?

- Welche Schwierigkeiten machte die letzte Release-Umstellung?

Benchmarktests sind eine zwar wichtige Auswahkomponente, die jedoch nur einen TeiI der zu beachtenden Komponenten darstellt. Weiter müssen beachtet werden:

1. Die Kostenseite (zum Beispiel global oder als DM/ Einheit)

2. Vetragsbedingungen und -gestaltungsmöglichkeiten

3. Umstellungsaufwand und -hilfe durch den Anbieter

4. Spektrum der angebotenen System- und Anwendersoftware, die nicht im Benchmarktest erfaßt werden kann.

5. Ausbaufähigkeit des Systems

6. Wartungsbedigungen und Servicegüte

7. Schulungsangelegenheiten

8. Ausfallsicherung und Back - up - Systeme

9. Die generelle Marktsituation des Anbieters

10. Kompatibilitätszwänge

11. Oftmals: Firmenpolitische oder öffentliche politische Gegebenheiten

12. Benchmarkergebnise.

Manche der Gründe: 1 bis 11 können so bestimmend sein, daß Benchmarktests sich erübrigen oder sich nach der Durchführung als sinnlos erweisen, da an und für sich keine Auswahl zu treffen ist. Falls eine echte Auswahl ansteht, werden die bestimmenden Faktoren 1, 3, 4 und 12 als wichtig angesehen werden.

Insbesondere der Faktor 11 kann ein dominierendes Gewicht erhalten.

Dieser Beitrag ist ein Vorabdruk aus dem Kapitel "Test, Auswahl und Bewertung von DB-Systemen" des Fachbuches "Datenbanksysteme - Aufbau und Einsatz" das der Autor demnächst in Physika-Verlag veröffentlichen wird.