DE4108590C2 - Verfahren zum Benchmark-Testen der Arbeitsgeschwindigkeit eines Computersystem - Google Patents

Description

Die Erfindung bezieht sich auf ein Verfahren zum Benchmark- Testen der Arbeitsgeschwindigkeit eines Computersystems.

Der Ausdruck "Benchmark-Test" bzw. "benchmarking" dient zur Beschreibung einer an einem Computersystem durchgeführten Test­ folge, die verschiedene von einem Systemanwender durchführbare Operationen simuliert. Während der Ausführung der Tests werden verschiedene Messungen durchgeführt. Diese Tests werden an dem System mehrmals durchgeführt, und die Meßergebnisse werden mit Optimalwerten oder anderen Ergebnissen verglichen, die während der Benchmark-Tests ähnlicher Systeme aufgezeichnet wurden. Durch Benchmark-Tests stehen systematische Verfahren zur Verfü­ gung, mit denen die Arbeitsweise bzw. Leistung von Systemen auf kontrollierte Weise getestet und gemessen werden kann. Mit der Entwicklung von Systemen auf Window-Basis, wurde es notwendig, ein Mittel zum Testen der Leistungsfähigkeit derartiger Window­ systeme sowie der Computer-Software und -Hardware zum Implemen­ tieren der Window-Systeme zur Verfügung zu stellen. Ein Bei­ spiel früherer Benchmark-Tests für Window-Systeme ist bekannt aus Gaylin "How Are Windows Used? Some Notes on Creating An Em­ pirically Windowing Benchmark Task" in CHI Proceedincts, April 1986, SS 96-100.

Window-Systeme präsentieren zusätzliche Faktoren, die bei der Bewertung des Leistungsvermögens berücksichtigt werden müs­ sen. Beispielsweise besteht ein verteiltes Window-System aus Mehrfachprozessen, einschließlich der Anwendungs- oder Client- Prozesse, dem Window-Server und wahlweise einem Window-Manager. Die Anwendungsprozesse sind echte Client-Prozesse, welche durch das Window-System betrieben werden. Der Window-Server steuert das Display und vermittelt den Zugriff auf das Display durch den Client-Prozeß. Er sorgt auch für die Grundfunktionalität der Fenster und des Cursors und bestimmt, wie in diese Fenster gezeichnet wird und wie Vorgänge auf sie zu verteilen sind.

Beispiele für Window-Systeme beinhalten das unter X11 (Warenzeichen des Massachusetts Institute of Technology) ange­ botene System, welches das X11-Protokoll unterstützt (vgl. Sheifler, Gettys, "The X Windows System" ACM Transactions On Graphics, Vol. 5, Nr. 2, April 1986, S. 79-109) und das bei Sun Microsystems, Inc., Mountain View, Kalifornien, erhältliche X11/NeWS-System, welches sowohl das X11- als auch das NeWS-Win­ dow-Server-Protokoll unterstützt (NeWS ist ein Warenzeichen der Firma Sun Microsystems, Inc.) (siehe Shaufler, "X11/NeWS Design Overview", Proceedings of the Summer 1988 User Conference, 1988, SS 23-35).

Der Client-Prozeß ist typischerweise mit einem Toolkit ver­ knüpft, welches die Funktionalität der Benutzeroberfläche im­ plementiert und dem Client-Prozeß die Mittel dafür zur Verfü­ gung stellt, die Benutzeroberfläche auf den Client-Prozeß zuzu­ schneiden. Das Toolkit bestimmt, wie die Menüs des Window-Sy­ stems aussehen, wie die Benutzer bzw. Anwender mit Steuerberei­ chen zusammenwirken und wie Steuerbereiche organisiert sind. Außerdem stellt das Toolkit eine Programmierschnittstelle zur Verfügung, welche den Entwicklern von Anwendungsprogrammen das Implementieren hochentwickelter Window-Anwendungen ermöglicht. Ein Beispiel eines Toolkit ist das unter dem Warenzeichen XVIEW bekannte Toolkit der Firma Sun Microsystems Inc. für das X11 NeWS Window-System. Für weitere Informationen wird verwiesen auf Jacobs "The XView Toolkit, An Architectural Overview", 3. Annual Technical Conference, 1989.

Der Window-Manager kann wie im Falle des X11-Protokolls ein separater Prozeß oder Teil eines Window-Servers sein, wie im Falle des X11/NeWS-Window-Systems, bei dem der Window-Manager eine Sammlung von im Window-Server befindlichen Prozessen ist. Der Window-Manager steuert den Arbeitsraum, das Fenster, wel­ ches den gesamten Bildschirm einnimmt, und bestimmt das Ar­ beitsraum-Menüfenster und die Anordnung der Icons.

Bei einem Window-System auf Kernelbasis wird der Kernel so modifiziert, daß er einen Ereignismanager und ein Mittel zur Aufnahme von Window-Zustandsinformationen enthält. Dieser Teil des Systems erfüllt die Aufgabe der Eingabe/Ausgabe-Geräte und der Verteilung von Vorgängen bzw. Ereignissen auf Anwendungs­ prozesse. Das Window-System auf Kernelbasis besteht ebenfalls aus einem Benutzer-Interface-Toolkit, welches die Anwendungs­ menüs, Steuerbereiche und Zeichnungsfähigkeiten liefert. Ein Beispiel eines Window-Systems auf Kernelbasis ist das SunView- Window-System (Warenzeichen von Sun Microsystems Inc.; vgl. Sun Microsystems, Inc., SunView 1 Proqrammer's Guide, revidierte Ausgabe A, 9. Mai 1988, und Sun Microsystems, Inc., SunView 1 Systems Programmer's Guide, revidierte Ausgabe A, 9. Mai 1988). Um ein genaues Bewertungsergebnis bzw. Benchmark des Sy­ stems zu erzeugen, ist es erwünscht, eine Benutzersession so genau wie möglich zu simulieren, in der der Benutzer vielfäl­ tige Aufgaben (Tasks) an dem System ausführt. Eine Methode zur Erzeugung dieser Art von Benchmark-Tests wurde entwickelt, die als Journaling bezeichnet wird. Journaling ist eine Methode zur Aufzeichnung von Vorgängen bzw. Ereignissen, die eine Serie von Benutzeraktionen widerspiegeln, in einer Sessionsdatei, welche als "Journaldatei" bezeichnet wird. Die Datei wird nachfolgend gelesen und die Aktionen werden initiiert und ausgeführt in der Reihenfolge, in der sie in der Datei aufgezeichnet sind, wo­ durch ein automatisches Mittel zum Simulieren der Benutzerses­ sion geschaffen wird (vgl. z. B. CAPBAK/UNIX Terminal Session Capture and Playback for UNIX Systems, Software Research Incor­ porated, 1989).

Systeme auf Window-Basis führen zusätzliche Aktionen ein, die bei der Entwicklung eines Benchmark-Tests für das System zu berücksichtigen sind. Ein System auf Windowbasis besteht aus einer Anzahl von Eingabegeräten, die gleichzeitig benutzt wer­ den, und einer Anzahl von Prozessen, welche in einer vorgegebe­ nen Folge in Wechselwirkung miteinander treten, um den ge­ wünschten Effekt, beispielsweise die Auswahl eines Client- oder Anwendungsprozesses aus einem Menü oder die Bewegung des Cur­ sors aus einem Fenster in ein anderes, hervorzurufen. In einem Versuch, die richtige Ausführungsfolge aufrechtzuerhalten, wird eine Zeitverzögerung zwischen verschiedenen Aktionen in der Journaldatei zusätzlich zu anderen aufgezeichneten Informatio­ nen aufgezeichnet, die eine Benutzersession simulieren. Durch richtige Bemessung der Zeit zwischen den Ereignissen ist es möglich, die Ereignisse beim Playback rascher im System ablau­ fen zu lassen als beim Aufzeichnen. Jedoch kann die Wiedergabe von Ereignissen bei einer höheren Geschwindigkeit als dieje­ nige, bei der sie ursprünglich aufgezeichnet wurden, zu uner­ wartetem Verhalten führen. Dieses unerwartete Verhalten ent­ steht wegen der Ablaufbedingungen, die durch einen Prozeß her­ vorgerufen werden, der vor der unbeendeten Ausführung eines an­ deren Prozesses in die Ausführung geht, wenn der Endzustand des anderen Prozesses durch den nachfolgenden Prozeß benutzt wird.

Bekannt ist ein Verfahren, bei dem spezielle Ereignisse zum Markieren der Stellen in der Journaldatei verwendet werden, an denen eine zuvor initiierte Verarbeitung zunächst abgeschlossen werden muß, bevor ein nachfolgender Prozeß initiiert wird. Diese speziellen Ereignisse werden als Synchronisationsereig­ nisse bezeichnet und sind typischerweise an Orten definiert, wo Mehrfachprozesse einen Zustandsaustausch vornehmen. Diese Syn­ chronisationsereignisse werden während der Aufzeichnungsphase in die Journalsessionen eingesetzt. Bei Wiedergabe wartet der Journaling-Mechanismus auf jedes dieser Synchronisationsereig­ nisse, bevor er in der Journaldatei weiterrückt und nachfol­ gende Ereignisse im Window-System auslöst (vgl. Islam, Ingo­ glia, "Testing Window Systems", Interfaces, Systems and People Working Together", 28th Annual Technical Symposium, ACM, Washington, D. C. (1989), SS 95-103).

Es gibt verschiedene Parameter oder Maßsysteme zur Bestim­ mung des Leistungsvermögens eines Computersystems, beispiels­ weise der Ausführungsgeschwindigkeit eines Prozesses und der während der Ausführung eines Prozesses erzeugten Ausgabemengen. Eine andere Größe zur Bestimmung der Leistungsfähigkeit eines Computersystems ist die Messung der Größe des Arbeitssatzes ei­ nes Prozesses. Der Arbeitssatz ist die Anzahl von während der Ausführung eines Prozesses betroffenen Speicherseiten (Arbeitsspeicherseiten). Die Arbeitssatzgröße kennzeichnet die Verarbeitungsgeschwindigkeit; denn der Seitenwechsel tritt umso häufiger auf, je größer die Zahl der während der Ausführung ei­ nes Prozesses einbezogenen Seiten ist. Der Seitenwechsel ist ein zeitaufwendiger Prozeß, bei dem eine Informationsseite in einen Schnellspeicher eingelagert und/oder aus letzterem ausge­ lagert wird.

Der Arbeitssatz wird zu vorgegebenen Zeitintervallen gemes­ sen, und die Arbeitssatzgröße wird mit Messungen verglichen, die zu früheren Intervallen durchgeführt wurden, um die Lei­ stungsfähigkeit des Systems zu bestimmen. Zeitabhängige Messun­ gen (d. h. während vorgegebener Zeitintervalle durchgeführte Messungen) arbeiten adäquat in traditionellen Systemen ohne Window-Basis, da die Ausführungsfolge in erster Linie vom Sy­ stem gesteuert wird, wobei ein vorhersehbares Zeitsystem gebil­ det wird, in welchem Messungen auf Zeitbasis zur Bestimmung des Systemleistungsvermögens während verschiedener Teile der Pro­ zeßausführung eingestellt werden können.

In Systemen auf Window-Basis ist das System jedoch benut­ zerinteraktiv und ereignisgesteuert. Daher ist der Systemablauf nicht mehr zeitlich vorhersehbar, und Messungen auf Zeitbasis finden nicht immer in vorhersehbaren Abschnitten des Prozeßab­ laufs statt. Außerdem enthalten einige Window-Systeme, wie X11/NeWS, gemeinsam genutzte Bibliotheken, auf die von Viel­ fachprozessen gemeinsam Bezug genommen wird. In Fenstersyste­ men, die Bibliotheken gemeinsam benutzen, wird vorzugsweise die Leistungsfähigkeit des Systems in bezug auf die Benutzung der gemeinsamen Bibliotheken gemessen.

Der Erfindung liegt die Aufgabe zugrunde, einen verbesserten Benchmark-Mechanismus für Systeme auf Window-Basis, insbe­ sondere zum Betreiben eines ereignisgesteuerten Systems zur Verfügung zu stellen. Die Erfindung soll dabei eine Messung der Leistungsfähigkeit von Systemen auf Windowbasis ermöglichen, die unter Client-Prozessen gemeinsam genutzte Bibliotheken ver­ wenden. Außerdem soll das Benchmark-System für Window-Systeme geeignet sein, welche in einer verteilten Umgebung arbeiten.

Zur Lösung dieser Aufgabe sieht die Erfindung ein Verfahren mit den Merkmalen des Patentanspruchs 1 vor.

Die Erfindung befaßt sich mit der Messung der Leistungsfä­ higkeit von ereignisgesteuerten Systemen, insbesondere von ver­ teilten Window-Systemen mit gemeinsam genutzten Bibliotheken. Synchronisationsereignisse werden in einer Journaldatei vorein­ gestellt und triggern während einer Wiedergabe ein Seitenanaly­ sentool zum Lesen der Seitentabelle der aktuellen Anwendungs­ prozesse. Sobald ein Playback abgeschlossen ist, werden die während des Playbacks aufgenommenen Seitentabellenmessungen durchgesehen, und Informationen werden herausgezogen, die zur Bestimmung des Arbeitssatzes für Privatspeicher und gemeinsam genutzte Bibliotheken dienen. Bei der Benutzung des Arbeits­ satzes können die Zahl der Bezugnahmeseiten und die Bezugnahme­ geschwindigkeit zur Verbesserung des Leistungsvermögens und der Vorhersage des Leistungsverhaltens eines Systems benutzt wer­ den.

Weiterbildungen der Erfindung sind in den Unteransprüchen gekennzeichnet.

Im folgenden wird die Erfindung anhand der Zeichnung näher erläutert. In der Zeichnung zeigen:

Fig. 1 ein typisches Computersystem zum Implementieren der erfindungsgemäßen Meßeinrichtung auf Window- Basis;

Fig. 2 eine Funktionsdarstellung des erfindungsgemäßen Systems in Blockdiagrammform;

Fig. 3 ein Ablaufdiagramm des Benchmark-Prozesses;

Fig. 4 ein illustratives Skript einer Benutzersitzung;

Fig. 5 ein illustratives Skript einer Benutzersitzung, die Synchronisationsereignisse und zum Kopieren und Löschen der Seitentabellen benutzte Ereig­ nisse enthält;

Fig. 6 eine ASCII-Textversion einer Journaldatei mit Synchronisationsereignissen und Ereignissen zum Kopieren und Löschen der Seitentabellen; und

Fig. 7 gelesene und in einer Datei gespeicherte Seiten­ tabellen.

Generelle Systemkonfiguration

Fig. 1 zeigt ein typisches System auf Computerbasis zur Durchführung von Benchmark-Tests von Systemen auf Window-Basis nach der Erfindung. Gezeigt ist ein Computer 101 mit drei Hauptkomponenten. Die erste dieser Hauptkomponenten ist die Eingabe/Ausgabe(I/O)-Schaltung 102, die zur Informationsüber­ tragung in geeignet strukturierter Form zu und aus den anderen Teilen des Computers 101 verwendet wird. Ebenfalls als Teil des Computers 101 ist die Zentraleinheit (CPU) 103 und der Speicher 104 gezeigt. Die beiden zuletzt genannten Komponenten sind die­ jenigen, die typischerweise bei den meisten Universalcomputern und beinahe allen Spezialcomputern vorhanden sind. Tatsächlich sind einige der im Computer 101 vorhandenen Elemente repräsen­ tativ für diese breite Kategorie von Datenverarbeitungsmaschi­ nen vorgesehen. Besondere Beispiele für geeignete Datenverar­ beitungsmaschinen, welche die Rolle des Computers 101 erfüllen können, sind die von der Firma Sun Microsystems, Inc., Mountain View, Kalifornien hergestellten Maschinen. Andere Computer mit ähnlichen Eigenschaften sind natürlich ebenfalls geeignet, um die weiter unten beschriebenen Funktionen in direktem Ablauf durchzuführen.

Ebenfalls in Fig. 1 ist eine Eingabevorrichtung 105 in ei­ ner Ausführungsform als Tastatur gezeigt. Es ist jedoch klar, daß als Eingabevorrichtung auch ein Kartenleser, ein Magnet- oder Papierbandleser oder andere bekannte Eingabevorrichtungen (ebenso wie ein anderer Computer) vorgesehen sein können. Ein Massenspeicher 106 ist mit der I/O-Schaltung 102 gekoppelt und liefert zusätzliche Speicherkapazität für den Computer 101. Der Massenspeicher kann andere Programme u. dgl. enthalten und die Form eines Magnet- oder Papierbandlesers oder eines anderen be­ kannten Geräts annehmen. Es ist klar, daß die im Massenspeicher 106 enthaltenen Daten in geeigneten Fällen auch in herkömmli­ cher Weise in den Computer 101 als Teil des Speichers 104 ein­ bezogen werden können.

Zusätzlich ist ein Displaymonitor 107 dargestellt, der zur Anzeige von Nachrichten oder anderen Benutzerkommunikationen verwendet werden kann. Ein solcher Displaymonitor kann die Form eines üblichen Kathodenstrahlbildschirms annehmen. Ein Cursor­ steuergerät 108 dient zur Auswahl von Befehlsmoden und zum Initiieren der Eingabedaten und bildet generell ein zweckmäßi­ ges Mittel zur Informationseingabe in das System.

Prozeßbeschreibung

Das erfindungsgemäße System mißt den Arbeitssatz des Systems zur Bestimmung des Leistungsvermögens des verteilten Window-Sy­ stems nach Ereignissen, die während der Ausführung von Prozes­ sen mittels des Systems auftreten. Ein synchronisierter Jour­ nalmechanismus wird in Verbindung mit einem Seitenwechsel-Ana­ lysetool zur Durchführung einer Seitenwechselanalyse an vorge­ gebenen Stellen während der Ausführung einer Folge von für Be­ nutzeraktionen repräsentativen Ereignissen verwendet, welche eine Benutzersitzung in einem System auf Window-Basis simulie­ ren.

Der Arbeitssatz ist der Satz aller Speicherseiten, auf die während der Ausführung eines Prozesses Bezug genommen wird. Der Umfang der während der Ausführung des Prozesses durchgeführten Seitenwechsel ist ein die Systemleistung maßgeblich beeinflus­ sender Faktor, da der Seitenwechsel ein zeitraubender Prozeß ist, bei dem Informationsseiten in den Speicher eingelagert und aus dem Speicher ausgelagert werden. Je mehr Seitenwechsel durchgeführt werden, umso länger ist die Ausführungszeit des Prozesses.

Es wurde gefunden, daß die gemeinsame Benutzung von Biblio­ theken durch Mehrfachprozesse die Systemleistungsfähigkeit er­ höht. Prozesse, welche Bibliotheken gemeinsam benutzen, teilen diejenigen Seiten, welche zu den Bibliotheken gehören, und ver­ mindern dadurch den Umfang des während der Prozeßausführung er­ forderlichen Seitenwechsels. Eine erhöhte Leistungsfähigkeit ergab sich dann, wenn gemeinsam genutzte Bibliotheken in Win­ dow-Systeme implementiert wurden. In Systemen auf Window-Basis können die das Window-System-Toolkit bildenden Bibliotheken so strukturiert werden, daß sie bei gleicher Struktur wie im X11/NeWS-Window-System gemeinsam genutzt werden. Um die Lei­ stungsfähigkeit des Systems weiter zu erhöhen, ist es er­ wünscht, den Seitenwechsel zu messen, der mit Bezug auf gemein­ sam genutzte Bibliotheken auftritt.

Ein ereignisgesteuerter synchronisierter Journaling-Mecha­ nismus wird beim Ausführen von Benchmark-Tests benutzt. Syn­ chronisationsereignisse werden in die Journaldatei an vorgege­ benen Stellen installiert, wo die Verarbeitung für ein zweites Ereignis von der Beendigung der Ausführung der Verarbeitung für ein erstes Ereignis abhängig ist. Der synchronisierte Journa­ ling-Mechanismus steuert das Weiterrücken in der Journaldatei durch Anhalten der Auslösung von Ereignissen, die aufeinander­ folgend in der Journaldatei aufgeführt sind, und Warten bis zum Auftreten gewisser spezifizierter Synchronisationsereignisse vor dem Weiterrücken zur nächsten zu initiierenden und auszu­ führenden Aktion. Daher kann die Ausführungsgeschwindigkeit des Tests während des Playbacks erhöht, die richtigen Zustände kön­ nen zwischen miteinander in Wechselwirkung tretenden und ihren Zustand austauschenden Mehrfachprozessen aufrechterhalten und die aufgrund von Ablaufbedingungen entstehenden Fehler können vermieden werden. Der synchronisierte Journaling-Mechanismus ist beschrieben in Islam, Ingoglia, "Testing Window Systems", Interfaces; Systems and People Working Together, 28. Annual Technical Symposium, ACM, Washington D. C., SS 95-103 (1989).

Ein Seitenwechsel-Analysetool ist in den synchronisierten Journaling-Mechanismus integriert, um ein ereignisgesteuertes Journaling-System zu schaffen, welches den Arbeitsraum des Sy­ stems an vorgegebenen Stellen während der Ausführung der Benchmark-Tests mißt. Das Seitenwechsel-Analysetool greift auf die Speichermanagementeinheit des Computersystems zu, sieht die den Adreßraum des Systems enthaltenden Seitentabellen durch und bestimmt diejenigen Seiten, auf die während der Systemoperation Bezug genommen worden ist. Bei einem bevorzugt verwendeten Sei­ tenwechsel-Analysetool wird ein Duplikat oder eine Sicherungs­ kopie (back copy) der Seitentabelle jedes überwachten Prozesses aufrechterhalten. Immer wenn die Seitentabellen entsprechend Lese-, Schreib- oder Seitenwechseloperationen geändert werden, werden die Änderungen nachfolgend in den Sicherungskopien auf­ gezeichnet. Die Sicherungskopien sind über den Benchmark-Test durch das Seitenwechsel-Analysetool zugreifbar und steuerbar. Wenn auch die nachfolgende Beschreibung des bevorzugten Ausfüh­ rungsbeispiels Operationen beschreibt, in denen die Sicherungs­ kopien der Seitentabellen gelesen werden, ist es für den Fach­ mann klar, daß das erfindungsgemäße System in gleicher Weise auf Seitenwechsel-Analysetools anwendbar ist, in denen die Sei­ tentabellen gelesen und gelöscht werden.

Der Journaling-Mechanismus steuert die Operation des Sei­ tenwechsel-Analysetools, um anzuzeigen, wann der Adreßraum zum Berechnen des Arbeitssatzes für einen speziellen Abschnitt des Benchmark-Tests geprüft werden soll. Dies ist in Fig. 2 darge­ stellt. Der synchronisierte Journaling-Mechanismus 200 liest die Journaldatei und initiiert die Ereignisse in der aufgeli­ steten Reihenfolge. In dem beschriebenen Beispiel umfassen die Ereignisse das Ausführen der Prozesse 205, 210, 215 als Teile des Benchmark-Tests. Außerdem kommuniziert der synchronisierte Journaling-Mechanismus mit dem Seitenwechsel-Analysetool 220, um die Seitentabellen (in dem bevorzugten Ausführungsbeispiel eine Sicherungskopie der Seitentabellen) an vorgegebenen Punk­ ten während der Initiierung von in der Journaldatei aufgeführ­ ten Ereignissen zu lesen und Kopien der Seitentabellen in einer Datei 225 zu speichern.

Vorzugsweise ist eine getrennte Verbindung zur Herstellung von Kommunikationen zwischen einem synchronisierten Journaling- Mechanismus und dem Seitenwechsel-Analysetool vorgesehen. Bei­ spielsweise kann in UNIX®-Betriebssystem eine "socket-connec­ tion" zwischen Prozessen geöffnet werden, welche einen Kanal zur Übertragung von Informationsbits zwischen den Prozessen aufbaut. Weitere Information bezüglich socket-connections ist dem Handbuch von J. Bach, The Design of the UNIX Operating Sy­ stem, Prentice-Hall, 1986, SS 283-388 zu entnehmen. Daher öff­ net bei dem bevorzugten Ausführungsbeispiel der synchronisierte Journaling-Mechanismus eine socket-connection zum Seitenanylse­ tool, um Befehle zum Seitenanalysetool zu übertragen und Si­ gnale aus dem Seitenwechsel-Analysetool zu empfangen.

Zwei Ereignisse sind in dem synchronisierten Journaling-Me­ chanismus vorgesehen, die bei Ausführung Befehle zum Seiten­ wechsel-Analysetool übertragen. Das erste, als Seitentabellen­ lösch- oder "Hut-ab"-Befehl bezeichnete Ereignis löscht die für jeden Prozeß in der Speichermanagementeinheit des Computersy­ stems aufrechterhaltenen Sicherungskopien der Seitentabellen. Das als Seitentabellenlese- oder "Schnappschuß"-Befehl bezeich­ nete zweite Ereignis liest die Sicherungskopien der Seitenta­ bellen aus der Speichermanagementeinheit und kopiert die Tabel­ len in eine Datei zur nachfolgenden Durchsicht und Analyse. Diese Befehle umfassen Synchronisationsereignisse derart, daß ein Weiterrücken in der Journaldatei unterbrochen und nachfol­ gende Ereignisse in der Journaldatei solange nicht ausgelöst werden, bis die Befehlsausführung abgeschlossen ist, wodurch gewährleistet wird, daß abgenommene Messungen den Zustand der Seitentabellen an der Stelle in der Journaldatei genauer be­ rücksichtigt werden, wo sich der Befehl befindet.

Sobald die Ausführung des in der Journaldatei aufgeführten letzten Prozesses beendet ist, ist die Wiedergabesequenz abge­ schlossen, und der synchronisierte Journaling-Mechanismus lei­ tet einen Prozeß zum Analysieren der gelesenen und in den Spei­ cher kopierten Seitentabellen ein, um den Arbeitssatz für jede Seitentabelle zu berechnen, wodurch die Seitenwechselinforma­ tion bezüglich sowohl privater als auch gemeinsam genutzter Da­ teien erzeugt wird, die für die Leistungsfähigkeit des Systems während des Benchmark-Tests kennzeichnend ist.

Das Seitenwechsel-Analysetool ist zur Aufnahme und Ausfüh­ rung der von dem synchronisierten Journaling-Mechanismus ausge­ gebenen Befehle modifiziert. Außerdem ist das Seitenwechsel- Analysetool derart modifiziert, daß es ein Signal an den syn­ chronisierten Journaling-Mechanismus ausgibt. Dieses ausgege­ bene Signal zeigt an, daß die Ausführung des Befehls abge­ schlossen ist und der Journaling-Mechanismus in der Initiierung der in der Journaldatei aufgelisteten Aktionen fortfahren kann.

Der Prozeß der Berechnung des Arbeitssatzes für Bibliothe­ ken gemeinsam nutzende Systeme ist durch das Ablaufdiagramm ge­ mäß Fig. 3 dargestellt. Am Block 250 wird eine Journaldatei er­ zeugt. Die Journaldatei kann durch "Einfangen" einer aktuellen Benutzersitzung erzeugt werden, während der ein Benutzer ver­ schiedene Tasks durchgeführt hat. Vorzugsweise wird die Jour­ naldatei durch Erfassen einer Benutzersitzung gebildet, welche einem Skript von Benutzeraktionen unter Berücksichtigung einer typischen Benutzersitzung an dem Computersystem folgt. Ein Bei­ spiel für eine Skriptdatei, welche Befehle bezüglich der als Teil des Benchmark-Tests durchgeführten Benutzeraktionen lie­ fert, ist in Fig. 4 dargestellt. Diese Skriptdatei zeigt eine einfache Benutzersitzung in einem System auf Window-Basis, in welchem der Benutzer eine Vielzahl von Anwendungen oder Client- Prozessen, einschließlich "console", "cmdtool", "textedit" und "mailtool" beginnt und eine Vielzahl von Tasks einschließlich Öffnen und Schließen von Fenstern, Bewegen zwischen Fenstern und Ändern des Fokus' von einem Fenster zu einem anderen sowie Ausführen verschiedener Tasks innerhalb der eingeleiteten Cli­ ent-Prozesse, durchführt.

Die bei ergriffenen Aktionen erzeugten Ereigniscodes, die für vom Benutzer zur Durchführung einer Task ausgeführte Aktio­ nen repräsentativ sind, beispielsweise das Bewegen des Cursors auf ein Fenster, das Anklicken einer Maustaste zur Änderung des Fokus' im Window-System auf das aktuelle Fenster und das An­ klicken eines im aktuellen Fenster residenten Icon zur Durch­ führung einer bestimmten Task werden erfaßt, sobald der Ereig­ niscode zu den die Aktion ausführenden Computerkomponenten übertragen wird. Daher können die Aktionen leicht dadurch neu initiiert werden, daß derselbe Ereigniscode während der Wieder­ gabe aus der Journaldatei ausgegeben wird. Alternativ kann die Journaldatei einfach dadurch erzeugt werden, daß die für auszu­ führende Aktionen zur Durchführung bestimmter Tasks repräsenta­ tiven Ereigniscodes manuell eingegeben werden. Der synchroni­ sierte Journaling-Mechanismus läßt nachfolgend die für die in der Journaldatei enthaltenen Benutzeraktionen repräsentativen Ereignisse "neu ablaufen", wobei jede aufgelistete Aktion der Reihe nach initiiert und dadurch unter Simulation der Benutzer­ sitzung ausgeführt wird.

Vorzugsweise sind die für auszuführende Aktionen repräsen­ tativen Ereignisse, welche in der Journaldatei erfaßt und ge­ speichert sind, im XDR-Format, das ist ein in vielen Computer­ architekturen verwendeter Binärformatstandard. (Informationen betreffend das XDR-Format können aus Sun Microsystems, Inc., Network Programming, Revisionsausgabe A vom 9. Mai 1988 entnom­ men werden). Alternativ kann die Journaldatei im ASCII-Textfor­ mat derart gespeichert werden, daß die Journaldatei auf ver­ schiedene Computersysteme übertragbar ist und der Benutzer die Journaldatei einfach durchsehen und zur Kundenanpassung modifizieren oder auf die ausgeführten Aktionen feinabstimmen kann, um einen besseren Einblick in die Leistungsfähigkeit der Com­ putersysteme zu ermöglichen, auf denen der Benchmark-Test durchgeführt wird. Beispielsweise kann das Format jedes Ereig­ nisses in der Journaldatei sein:

Zeitstempel xy Tastenbetätigung Ereignisname

Hierbei zeichnet der Zeitstempel die Auftrittszeit des Er­ eignisses, die x-, y-Felder zeichnen die Koordinaten des Zei­ gers zum Zeitpunkt des Ereignisses auf, das Tastenanschlagfeld stellt den Zustand der Tasten oder Tastenanschläge dar (es ist Null für Mausereignisse), und das Ereignisnamensfeld speichert den Namen oder die Klasse des Ereignisses. Das System ist je­ doch nicht als solches beschränkt, und die in der Journaldatei gespeicherten Codes können in irgendeinem für den Journaling- Mechanismus verständlichen Format derart vorliegen, daß die in der Journaldatei aufgeführten und für Benutzeraktionen reprä­ sentativen Ereignisse während der Wiedergabe initiiert und aus­ geführt werden.

Im folgenden wird erneut auf Fig. 3 Bezug genommen. Um eine genaue Wiedergabe der aufgezeichneten und in der Journaldatei gespeicherten Benutzersitzung zu gewährleisten, werden im Block 260 Synchronisationsereignisse in die Journaldatei eingegeben. Die Zahl und der Ort der eingegebenen Synchronisationsereig­ nisse hängt von den während der aufgezeichneten Benutzersitzung durchgeführten Ereignissen und Aufgaben ab. Die Synchronisati­ onsereignisse werden in der Journaldatei hinter einem solchen Ereignis installiert, das repräsentativ für eine Benutzeraktion ist, deren Bearbeitung abgeschlossen sein muß, bevor ein nach­ folgendes Ereignis initiiert wird, da die Bearbeitung des nach­ folgenden Ereignisses abhängig von dem Prozeßzustand der Been­ digung des vorhergehenden Ereignisses ist. Das Synchronisati­ onsereignis zeigt das (oder die) Ereignis(se) an, welches (oder welche) vor der Initiierung weiterer Ereignisse abgeschlossen werden muß (oder müssen). Der Journaling-Mechanismus hält eine weitere Initiierung von Ereignissen während der Wiedergabe (replay) an, bis er ein Signal erhält, welches anzeigt, daß die Verarbeitung des im Synchronisationsereignis bezeichneten Er­ eignisses vollständig ausgeführt worden ist.

Vorzugsweise werden Synchronisationsereignisse an Stellen im Skript zwischen solchen Ereignissen eingegeben, welche wäh­ rend der Verarbeitung den Zustand austauschen. Diese Synchroni­ sationsereignisse können vom Benutzer nach der Herstellung der Journaldatei manuell eingegeben oder durch einen automatischen Prozeß eingegeben werden, welcher die Ereignisse in der Jour­ naldatei durchsieht und diejenigen Ereignisse bestimmt, welche eine vollständige Ausführung vor der Initiierung weiterer Ak­ tionen erforderlich machen. Vorzugsweise werden die Synchroni­ sationsereignisse automatisch nach den für die ergriffenen Be­ nutzeraktionen repräsentativen Ereignissen in die Journaldatei eingegeben. Das Toolkit, welches die Schnittstelle der Client- Prozesse zum Window-System bildet, wird ebenso wie der Window- Server und Window-Manager modifiziert, um ein Synchronisations­ ereignis auszugeben, welches von dem synchronisierten Journa­ ling-Mechanismus erfaßt und in die Journaldatei eingegeben wird. Das Toolkit, das Window-System, der Window-Server und Window-Manager werden weiter modifiziert, um ein Signal an den synchronisierten Journaling-Mechanismus während der Journalda­ teiwiedergabe anzulegen, wenn er die Verarbeitung von durch das Synchronisationsereignis identifizierten Ereignissen beendet, so daß der synchronisierte Journaling-Mechanismus weiß, wann die Verarbeitung von Ereignissen abgeschlossen ist und nachfol­ gende Ereignisse initiiert werden können.

Im Block 270, Fig. 3 werden die in der Journaldatei aufge­ listeten Ereignisse in Abschnitte unterteilt. Die Abschnitte werden entsprechend denjenigen Synchronisationspunkten in der Benutzersitzung unterteilt, an denen die Seitentabellen durchgesehen werden sollen, um den Arbeitsraum und die Leistungsfä­ higkeit des Systems zu messen. Die Abschnitte können vom Benut­ zer nach der Herstellung der Journaldatei manuell oder durch einen automatischen Prozeß gebildet werden, der die Abschnitte nach einem vorgegebenen Kriterium erzeugt. Vorzugsweise werden die Synchronisationspunkte entsprechend der Leistungsfähig­ keitsmeßwertaufnahme angeordnet und dementsprechend die Ab­ schnitte erzeugt. Beispielsweise können die Abschnitte erzeugt werden, um jedes Ereignis in einzelne Abschnitte derart zu un­ terteilen, daß sich die Wirkung jedes Ereignisses auf den Ar­ beitsraum des Systems messen läßt. Alternativ kann jeder Ab­ schnitt die für eine spezielle Task relevanten durchzuführenden Ereignisse enthalten, oder diejenigen Ereignisse, welche inner­ halb eines speziellen Fensters auftreten.

An den Ereignisplätzen in der Journaldatei, welche den Be­ ginn eines Abschnitts anzeigen, wird dasjenige Ereignis einge­ setzt, das bei Ausführung während einer Wiedergabe einen an das Seitenwechsel-Analsysetool zu sendenden Befehl hervorruft, um die Kopien der Seitentabellen in der Speichermanagementeinheit eines Computersystems zu löschen (Block 280, Fig. 3).

In ähnlicher Weise wird an denjenigen Plätzen in der Jour­ naldatei, welche das Ende eines Abschnitts anzeigen, dasjenige Ereignis eingesetzt, welches bei Ausführung während einer Wie­ dergabe einen an das Seitenwechsel-Analysetool zu sendenden Be­ fehl hervorruft, um die Kopien der Seitentabellen in der Spei­ chermanagementeinheit des Computersystems zu lesen und sie in einer Datei zu speichern (Block 290, Fig. 3).

Diese Ereignisse beinhalten Synchronisationsereignisse der­ art, daß während der Wiedergabe (replay) der Journaling-Mecha­ nismus solange keine weiteren Ereignisse aus der Journaldatei initiiert, bis ein Signal aus dem Seitenwechsel-Analysetool empfangen wird, welches die Beendigung der Ausführung der in­ itiierten Befehle anzeigt. Dies gewährleistet, daß die Meß­ wertaufnahmen die Messungen für den Abschnitt genauer berücksichtigen und keine Seitenwechselinformationen für einen nach­ folgenden Abschnitt beinhalten.

Sobald diese Schritte ausgeführt worden sind, ist die Jour­ naldatei vollständig und bereit, um zur Durchführung von Benchmark-Test-Messungen wiedergegeben zu werden. Ein Beispiel eines Skripts zur Erzeugung einer Journaldatei einschließlich Synchronisationsereignissen und Aktionen zur Durchführung von Messungen des für das Skript gemäß Fig. 4 erzeugten Arbeits­ raums ist in Fig. 5 dargestellt. Eine ASCII-Textversion der entsprechenden Journaldatei ist in Fig. 6 gezeigt. In Fig. 6 sind die Synchronisationsereignisse in den mit "s" beginnenden Zeilen angegeben. Beispielsweise ist in Zeile 410 ein Synchro­ nisationsereignis installiert, um mit "/GetKeyState" zu syn­ chronisieren. Daher wartet während der Wiedergabe ("replay") der synchronisierte Journaling-Mechanismus solange, bis die Verarbeitung bezüglich /GetKeyState abgeschlossen ist, bevor er mit der Initiierung von Ereignissen fortfährt, die mit Zeile 415 beginnen. In ähnlicher Weise bewirkt das Synchronisations­ ereignis in der Zeile 420, daß der Journaling-Mechanismus war­ tet, bis die Aktionen "SubUnviewableNotify/UnviewableNotify /UnmapNotify/DoItEvent/DoItEvent" abgeschlossen sind, bevor er die Aktion in Zeile 425 einleitet.

Die Ereignisse zur Steuerung des Seitenwechsel-Analysetools sind an denjenigen Zeilen angegeben, welche mit "w" beginnen. In der vorliegenden Darstellung ist der Befehl "/F3-done" das Ereignis, welches den "Hut-ab"-Befehl darstellt, um das Seiten­ wechsel-Analysetool zum Löschen der Sicherungskopien der Sei­ tentabellen zu veranlassen, damit eine genaue Messung des Ar­ beitssatzes für den Abschnitt der Journaldatei erreicht werden kann. Der Befehl in Zeile 430 "/F4-done" ist hinter der letzten vorzunehmenden Aktion angeordnet und ist dasjenige Ereignis, welches den vom Seitenwechsel-Analysetool ausgegebenen "Schnappschuß"-Befehl darstellt, um die Kopien der Seitentabel­ len lesen und in einer Datei speichern zu lassen.

Im Block 300 der Fig. 3 wird die Journaldatei von dem syn­ chronisierten Journaling-Mechanismus wiedergegeben, um das Com­ putersystem einem Benchmark-Test zu unterwerfen. Die in der Da­ tei aufgeführten Ereignisse werden in der angegebenen Sequenz initiiert. Wenn ein Synchronisationsereignis erreicht ist, hält der synchronisierte Journaling-Mechanismus die Auslösung nach­ folgender Ereignisse solange an, bis ein Signal eingeht, wel­ ches anzeigt, daß die Prozeßausführung des vom Synchronisati­ onsereignis bezeichneten Ereignisses abgeschlossen ist. Wenn ein Ereignis zum Löschen der Kopien der Seitentabellen in der Datei erreicht ist, wird die Initiierung nachfolgender Ereig­ nisse in der Datei angehalten, und der Befehl wird an das Sei­ tenwechsel-Analysetool. gesandt, welches die Kopien der Seiten­ tabellen löscht und ein Signal an den synchronisierten Journa­ ling-Mechanismus sendet, das anzeigt, daß die Ausführung des Befehls abgeschlossen ist. In ähnlicher Weise wird dann, wenn das Ereignis zum Lesen und Kopieren der zurückliegenden Ereig­ nisse in der Datei angehalten wird, der Befehl an das Seiten­ wechsel-Analysetool gesendet, welches die Seitentabellen liest, sie in eine Datei kopiert und ein Signal an den synchronisier­ ten Journaling-Mechanismus zurücksendet, welches anzeigt, daß die Ausführung des Befehls abgeschlossen ist.

Am Ende des Wiedergabe(replay-)Prozesses, Block 310, wird die die Kopien oder Schnappschüsse der Seitentabellen enthal­ tende Datei durchgesehen und analysiert, um die Arbeitssätze für die verschiedenen Abschnitte der Benutzersitzung zu bestim­ men. Fig. 7 ist illustrativ für Seitentabellen, welche für einen Abschnitt in einer Datei entsprechend von dem synchroni­ sierten Journaling-Mechanismus ausgegebenen Befehl kopiert wer­ den. Die Seitentabellen für vier Prozesse, testedit, mailtool, cmdtool und cmdtool, sind jeweils durch Prozeßidentifikations­ nummern 2244, 2246, 2238 und 2241 identifiziert. Der Buchstabe "R" zeigt an, daß auf eine gemeinsam genutzte Seite Bezug ge­ nommen wurde, und der Buchstabe "X" zeigt an, daß auf eine private Seite Bezug genommen wurde. Die Buchstaben "a", "w" und "r" identifizieren gemeinsam genutzte Seiten ohne Bezug und "x" identifiziert private Seiten ohne Bezugnahme. Die Seitentabel­ len für jeden Abschnitt werden durchgesehen und ein Zählwert der Anzahl von gemeinsam genutzten und privaten Seiten herge­ stellt, auf die während eines Abschnitts Bezug genommen wurde. Aus dieser Information kann im Block 320 der Arbeitssatz für jeden Abschnitt bestimmt werden.

Es wurde festgestellt, daß für Benchmark-Tests bei ver­ schiedenen Systemen eine genaue Darstellung des Arbeitssatzes eines Computersystems als Mittelwert des Arbeitssatzes derjeni­ gen Anwedungsprozesse definiert werden kann, welche Bestandteil des Benchmark-Tests sind. Der mittlere Arbeitssatz für den Benchmark-Test eines Systems, das aus gemeinsam genutzten und privaten Seiten besteht, läßt sich wie folgt definieren:

ws = (mittlere gemeinsam genutzte Seiten) + (np). (mittlere private Seiten pro Prozeß); oder

wobei np die Anzahl von während des Benchmark-Tests ablau­ fenden Prozessen, ns die Anzahl von Schnappschußpunkten, x_i die Anzahl von gemeinsam genutzten Seiten im Schnappschuß i, y_ij = die Anzahl von privaten Seiten im Schnappschuß i für einen Pro­ zeß j und ws der Arbeitssatz eines Benchmark-Tests in Seiten ist. In ähnlicher Weise läßt sich der Arbeitssatz für ein nur aus privaten Seiten bestehendes System für den Benchmark-Test wie folgt definieren:

Durch die Analyse des Arbeitssatzes des privaten und ge­ meinsam genutzten Speichers, einschließlich gemeinsam genutzter Bibliotheken können Benchmark-Tests von Systemen für eine Viel­ zahl von Systemen und Architekturen implementiert werden.

Claims (4)

1. Verfahren zum Benchmark-Testen der Arbeitsgeschwindig­ keit eines Computersystems bei der Ausführung einer Mehrzahl von für eine Benutzersitzung repräsentativen Benutzeraktionen unter Verwendung eines Computersystems mit einer CPU, einem in Seiten unterteilten Speicher, der durch seinen Adreßraum iden­ tifiziert wird und dessen Zustand durch wenigstens eine Seiten­ tabelle definiert wird, wobei die Seitentabelle anzeigt, ob auf eine Seite Bezug genommen worden ist, ferner mit Eingabe/Aus­ gabe-Geräten, zu denen eine Tastatur und/oder eine Maus und ein Display gehören, wobei die CPU wenigstens einen auf den Spei­ cher zugreifenden Anwendungsprozeß ausführt, wobei
Informationen über die Eingabe/Ausgabe-Geräte in das Compu­ tersystem eingegeben werden, welche Benutzeraktionen repräsen­ tieren, wobei von dem Computersystem in Abhängigkeit von den eingegebenen Informationen Prozesse ausgeführt werden können;
in einer Journaldatei für die die Benutzeraktionen darstel­ lenden eingegebenen Informationen repräsentative Ereignisse gespeichert werden, die während einer späteren Wiedergabe der Journaldatei derart ausgeführt werden, daß die für Benutzer­ aktionen repräsentative Informationseingabe simuliert wird und das Computersystem Prozesse in Abhängigkeit von den Ereignissen ausführt;
Synchronisationsereignisse derart in die Journaldatei ein­ gegeben werden, daß sie zwischen ersten und zweiten Ereignissen angeordnet sind, wobei das zweite Ereignis ein Ereignis ist, das von der Beendigung der Ausführung des ersten Ereignisses abhängig ist, wobei das Synchronisationsereignis das erste Ereignis als beendet identifizieren muß, bevor das zweite Ereignis ausgeführt wird;
die in der Journaldatei aufgelisteten Ereignisse in Abschnitte aufgeteilt werden;
jeweils am Beginn eines Abschnittes ein Ereignis in die Journaldatei eingegeben wird, das bei seiner Ausführung die Seitentabelle derart löscht, daß die Seitentabelle keine Bezug­ nahmen auf Seiten anzeigt;
jeweils am Ende eines Abschnitts ein Ereignis in die Jour­ naldatei eingegeben wird, das bei seiner Ausführung das Lesen der Seitentabelle und die Speicherung einer Kopie der Seiten­ tabelle in eine Datei bewirkt;
die Journaldatei derart wiedergegeben wird, daß
die in der Journaldatei aufgelisteten Ereignisse in der Reihenfolge ihrer Auflistung ausgeführt werden,
nach Initiierung eines Synchronisationsereignisses die Ausführung von in der Journaldatei nachfolgend aufgelisteten Ereignissen solange angehalten wird, bis das von dem initiier­ ten Synchronisationsereignis identifizierte Ereignis vollstän­ dig ausgeführt wurde,
nach Initiierung eines Ereignisses zum Löschen der Sei­ tentabelle die Ausführung nachfolgender Ereignisse in der Jour­ naldatei angehalten wird, die Seitentabelle gelöscht und nach dem Löschen der Seitentabelle die Ausführung von nachfolgenden Ereignissen in der Journaldatei fortgesetzt wird; und
nach Initiierung eines die Seitentabelle lesenden Ereignisses die Ausführung nachfolgender Aktionen angehalten, die Seitentabelle gelesen und eine Kopie der Seitentabelle in einer Datei gespeichert und schließlich nach der Speicherung der Kopie der Seitentabelle die Ausführung der in der Jour­ naldatei aufgeführten Ereignisse fortgesetzt wird; und
nach Wiedergabe der Journaldatei und vollständiger Ausfüh­ rung aller Ereignisse die die gespeicherten Kopien der Seiten­ tabellen enthaltende Datei gelesen, die Zahl der Bezugnahmen auf Seiten in jeder gespeicherten Seitentabelle für jeden Abschnitt summiert und der Arbeitssatz für jeden Abschnitt aus der Zahl von Seiten, auf die Bezug genommen worden ist, bestimmt wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Arbeitssatz bestimmt wird nach der Gleichung:
wobei np die Zahl der während des Benchmark-Tests ausge­ führten Prozesse, ns die Zahl der Abschnitte, y_ij = die Zahl von Seiten im Abschnitt i für einen Prozeß j und ws der Arbeitssatz des Benchmark-Tests in Seiten ist.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß ein Speicher mit gemeinsam genutzten und privaten Seiten ver­ wendet und der Arbeitssatz bestimmt wird durch die Gleichung:
wobei np die Zahl von während des Benchmark-Tests ausge­ führten Prozessen, ns die Zahl von Abschnitten, x_i die Anzahl von gemeinsam genutzten Seiten im Abschnitt i, y_ij = die Zahl von privaten Seiten im Abschnitt i für einen Prozeß j und ws der Arbeitssatz eines Benchmark-Tests in Seiten ist.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß ein Computersystem mit einem Window-System verwendet wird, durch welches mehrere Fenster geöffnet und Ereignisse in unterschiedlichen Fenstern ausgeführt werden kön­ nen, und daß die in der Journaldatei aufgelisteten Ereignisse entsprechend demjenigen Fenster, in dem sie auszuführen sind, in Abschnitte unterteilt werden.