DE112010004420T5

DE112010004420T5 - Verfahren und System zur Verbesserung der Ausführungszeit von Software durch Optimierung elnes Leistungsmodells

Info

Publication number: DE112010004420T5
Application number: DE112010004420T
Authority: DE
Inventors: Massimo Villani; Vincenzo Sciacca; Rosario Gangemi
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2009-10-21
Filing date: 2010-08-31
Publication date: 2012-12-27
Also published as: CN102576311B; CN102576311A; US20120203536A1; GB201121785D0; GB2486965B; GB2486965A; WO2011047918A1

Abstract

Ein Leistungs- oder Zuverlässigkeitsmodell wird bereitgestellt, das das Verhalten einer Anwendung unter verschiedenen Bedingungen von System-Ressourcen darstellt. Dieses Modell kann die Form einer oder mehrerer dünn besetzter Matrizen haben, die Zuverlässigkeits- oder Leistungswerte für verschiedene Kombinationen von Bedingungen bereitstellen. Dieses Modell wird an einen Benutzer der Anwendung vertrieben und wird während der Ausführung der Anwendung mit Bezug auf Daten zu System-Ressourcen, die durch das Betriebssystem oder eine andere Überwachungs-Software bereitgestellt werden, abgefragt, um eine Angabe über die erwartete Leistung der Anwendung unter den bestehenden Betriebsbedingungen bereitzustellen. Diese Angabe kann einem Benutzer mitgeteilt werden, beispielsweise in einem Fall, in dem die Angabe außerhalb der Grenzen eines zufriedenstellenden Betriebs fällt. Das System kann außerdem versuchen, die zugewiesenen System-Ressourcen neu auszuhandeln, um die Leistung zu verbessern.

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf ein Verfahren und ein System zum Verwalten des Verhaltens einer Software-Einheit als Funktion der für diese Software-Einheit verfügbaren Ressourcen.
Hintergrund der Erfindung
Die Vorhersage des genauen Verhaltens einer Anwendung in Produktionsumgebungen von Kunden auf der Grundlage der Ergebnisse von Funktionsüberprüfungs-Testfällen (functional verification test, FVT), die in der Entwicklungsphase ermittelt wurden, stellt eine besondere Herausforderung dar, selbst wenn diese in zusätzliche Tests (Kapazitätsplanung, Systemtest) eingebunden werden, die üblicherweise in Software-Entwicklungslabors durchgeführt werden. Sehr wahrscheinlich werden durch solche Testfälle aus funktionaler Sicht aussagekräftige Tests ermittelt, sie werden jedoch unter Betriebsbedingungen durchgeführt, die wahrscheinlich nicht genau der Ausführungsumgebung des Kunden in der Produktionsphase entsprechen. Ein verbreiteter Ansatz für große Anwendungen zur Lösung dieses Problems sind sogenannte „Kapazitätsplanungs-„ oder „Leistungsauslastungstests”, bei denen einige spezifische (zum Beispiel die genauen Anforderungen an Hardware-Ressourcen) und maßgebliche (zum Beispiel die Zuverlässigkeit) Aspekte der Anwendungen in verschiedenen Szenarien getestet werden. In solchen Szenarien unterscheidet sich die Betriebsumgebung von „idealen” Testfällen aufgrund der unvorhersehbaren Menge an Rechen-Ressourcen, die der Software-Anwendung während der Produktion am Kundenstandort verfügbar gemacht wird: Unter realen Bedingungen wird die Anwendung häufig in großen Verbundrechenzentren eingesetzt, und ihre Planung findet zusammen mit derjenigen für andere parallele Anwendungen statt, sodass erhebliche Schwankungen der verfügbaren Ressourcen auftreten können. Dies sind einige der Gründe, warum die Rechen-Ressourcen, die für die Anwendung zur Verfügung stehen, von idealen Einzelcomputertests oder simulierten Tests abweichen können. Für die „Kapazitätsplanung” ist es wünschenswert, genauere Vorhersagen als derzeit zu ermöglichen: Bei der zurzeit am besten bewährten Methode gilt das Ergebnis der Kapazitätsplanungsphase als Definition der Hardware-Anforderungen, die erforderlich sind, damit die Anwendung unter den ungünstigsten Bedingungen korrekt funktioniert. Mit anderen Worten, Werkzeuge für „Leistungsauslastung” oder „Kapazitätsplanung” stellen üblicherweise ein Maß der Betriebs-Ressourcen bereit, die für eine ordnungsgemäße Ausführung erforderlich sind, d. h. aus funktionaler Sicht im „ungünstigsten Fall”.
In US 5 655 074 wird ein Software-Werkzeug für die Systementwicklung großer Software-Systeme beschrieben. Der Prozess beginnt mit dem Schritt der Erfassung von Daten zu Beobachtungen einer großen Zahl von Merkmalen eines Software-Systems (zum Beispiel in der Vergangenheit erfolgte und geplante Systemanpassungen) für jede eindeutig identifizierbare Software-Komponente. Außerdem werden Vergangenheitsdaten zu Fehlern oder Problemen bei jeder Software-Komponente erfasst. Die Fehlerdaten werden gemessenen Merkmalen der Software statistisch zugeordnet, um einen Risikoindex zu erstellen. Der Risikoindex kann als Prognoseinstrument verwendet werden, das ermittelt, welche Merkmale der Software die Leistung der Software vorhersagen, oder alternativ kann der Risikoindex dazu verwendet werden, eine Rangfolge der Komponenten zu erstellen, um zu ermitteln, für welche Komponenten weniger Tests benötigt werden, um Ressourcen zu sparen.
Übersicht über die Erfindung
Wie erörtert, sind Testtechniken nach dem Stand der Technik darauf ausgerichtet, die minimalen Systemanforderungen statisch zu ermitteln. Ein Ziel der vorliegenden Erfindung ist, Daten über die erwartete Leistung einer Anwendung dynamisch bereitzustellen, wenn die Anwendung in der Umgebung des Kunden ausgeführt wird.
Gemäß der vorliegenden Erfindung werden ein Verfahren zum Optimieren einer Software-Ausführung gemäß dem beigefügten Hauptanspruch 1, eine Vorrichtung gemäß dem beigefügten Anspruch 12, ein Computerprogramm gemäß dem beigefügten Anspruch 13, ein Leistungsmodell gemäß dem beigefügten Anspruch 14 und ein computerlesbares Medium gemäß dem beigefügten Anspruch 15 bereitgestellt. Weitere bevorzugte Ausführungsformen werden in den Unteransprüchen definiert.
Vorteile der vorliegenden Erfindung werden dem Fachmann bei Durchsicht der Zeichnungen und der genauen Beschreibung ersichtlich. Alle zusätzlichen Vorteile sollen hierin eingeschlossen sein.
Kurze Beschreibung der Zeichnungen
Ausführungsformen der vorliegenden Erfindung werden nun beispielhaft mit Bezug auf die beigefügten Zeichnungen beschrieben, in denen gleiche Bezugszeichen gleichartige Elemente kennzeichnen und für die gilt:
1 stellt die Schritte einer ersten Ausführungsform der vorliegenden Erfindung dar;
2 zeigt ein Beispiel eines Leistungsmodells in Form eines mehrdimensionalen Raums 200;
3 zeigt ein weiteres Beispiel eines Leistungsmodells in Form eines mehrdimensionalen Raums 300;
4 stellt die Schritte einer zweiten Ausführungsform der vorliegenden Erfindung dar;
5 stellt die Schritte einer dritten Ausführungsform der vorliegenden Erfindung dar; und
6 stellt eine Computerumgebung dar, die zum Umsetzen bestimmter Ausführungsformen geeignet ist.
Genaue Beschreibung der bevorzugten Ausführungsform
Es wird vorgeschlagen, eine Anwendung im Zusammenhang mit einem Leistungsmodell zu erstellen (Entwicklung, Realisierung und Zusammenstellung) und für eine Betriebsumgebung einzusetzen. Das Leistungsmodell kann realisiert werden, indem Anwendungstestverfahren mit zusätzlichen Messgrößen, die den Schwerpunkt auf die Ressourcen legen, die durch die Ausführungsumgebung verfügbar gemacht werden, in einer Weise genutzt werden, die in Bezug auf einen bestimmten Umfang der Anwendung bevorzugt nicht bindend ist, sodass das Modell auf die größtmögliche Zahl von Anwendungen angewendet werden kann.
1 stellt die Schritte einer ersten Ausführungsform der vorliegenden Erfindung dar. Wie dargestellt, beginnt der Prozess in Schritt 100 und geht zu Schritt 110 über, in dem ein Leistungsmodell, wie es beispielsweise im Folgenden genauer beschrieben wird, bereitgestellt wird. In Schritt 120 wird die Anwendung, auf die sich das Leistungsmodell bezieht, ausgeführt, und in Schritt 130 werden Messwerte der System-Ressourcen, die zum Definieren des Modell verwendet werden, beispielsweise von dem Betriebssystem oder einer anderen Überwachungs-Software oder -Hardware empfangen. In Schritt 140 werden die Messwerte verwendet, um einen Leistungswert den Messwerten entsprechend aus dem Leistungsmodell zu beziehen. In Schritt 150 wird ermittelt, ob die Anwendung beendet worden ist, wobei der Prozess in diesem Fall in Schritt 160 endet, oder andernfalls kehrt der Prozess zu Schritt 130 zurück, sodass der Prozess fortfährt, das Leistungsniveau der Software als Funktion der überwachten Verfügbarkeit von System-Ressourcen zu überwachen, solange die Anwendung ausgeführt wird. Dementsprechend wird ein Verfahren zum Optimieren einer Software-Ausführung in einem System bereitgestellt, in dem die Software ausgeführt wird, wobei das Verfahren die Schritte des Bereitstellens eines Leistungsmodells, das die Leistung der Software unter verschiedenen Systembedingungen darstellt, wie im Hinblick auf eine oder mehrere vorgegebene System-Ressourcen beschrieben, des Empfangen eines Messwerts jeder der vorgegebenen System-Ressourcen für einen bestimmten Zeitpunkt und des Beziehens eines Leistungswerts von dem Leistungsmodell entsprechend den Messwerten umfasst. Der Ausdruck Leistung kann so, wie er in der gesamten Beschreibung verwendet wird, jedes gewünschte Verhalten einer Software-Anwendung wiedergeben. Gemäß einer bevorzugten Ausführungsform handelt es sich bei dem betreffenden Leistungskriterium um die Zuverlässigkeit der Software.
Wenn beispielhaft ein Anwendungs-Server wie zum Beispiel ein WebSphere-Anwendungs-Server, Tomcat, JBoss usw. als Betriebsumgebung und eine J2EE-Anwendung als Anwendung gewählt wird, würden die Ressourcen (Zentraleinheit (CPU), Speicher, Festplatten-Speicherplatz, virtueller Speicher usw.) ermittelt und formal definiert, da eine Ressource sich auch logisch und indirekt auf eine Hardware-Ressource wie zum Beispiel diejenigen, die der Anwendungs-Server für J2EE-Anwendungen verfügbar macht, und diejenigen, die programmgesteuert für sie verfügbar gemacht werden können, beziehen kann.
Ein festgelegter, verfügbarer Satz von Rechen-Ressourcen (zum Beispiel 1 GB RAM, 100 GB Festplatten-Speicherplatz, 400 Steckplätze usw.) kann als Betriebspunkt einer Anwendung in einem NR-dimensionalen Raum betrachtet werden, wobei NR die Anzahl der ausgewählten Rechen-Ressourcen (eine Teilmenge oder die Gesamtmenge der Rechen-Ressourcen, die in einer Hosting-Umgebung definiert sind) darstellt, die für Leistungsmessgrößen von Bedeutung sind.
Das „Leistungsmodell” wird gemäß jedem Funktionstestfall der Anwendung so berechnet, dass es für jeden Betriebspunkt der Anwendung die Bereitstellung eines formalen numerischen Maßes (vergleichbar mit anderen Versionen derselben Software oder einer anderen Bereitstellung derselben Software) der Anwendungsleistung ermöglicht: Wie dieses ermittelt wird, wird im Abschnitt zur Umsetzung genau beschrieben.
Bei dem Artefakt, das die Leistungsmodelldaten ausdrückt, kann es sich um eine oder mehrere Matrizen, meist um eine dünn besetzte Matrix, handeln, bei der jede der Achsen einer Rechen-Ressource zugeordnet ist, die für die Berechnung der Leistung verwendet wird, und jede Zelle drückt nach einer Normalisierung die Wahrscheinlichkeit aus, dass ein „Problem”, z. B. Abstürze, Verfehlen einer Dienstqualität, Ausnahmen, eine Zeitüberschreitung usw., auftritt. Jedes „Problem” dieser Art wird bevorzugt formal als Bedingung beispielsweise im Hinblick auf eine Übereinstimmung eines Wortes in einer Protokolldatei, eines booleschen Ausdrucks mit einem CIM-Datenmodell usw. definiert.
Gemäß bestimmten Ausführungsformen kann das Leistungsmodell einen Satz von NM verschiedenen Matrizen umfassen, die sich jeweils auf ein bestimmtes, definiertes Problem beziehen oder sich sogar gemäß zusätzlichen Kriterien auf verschiedene Probleme beziehen, sich zum Beispiel auf dieselbe Definition eines „Problems” beziehen, jedoch für eine andere Plattform gelten.
Gemäß bestimmten Ausführungsformen wird das Leistungsmodell durch Testen der Software gefüllt. Dieses Testen der Software kann das wiederholte Ausführen der Software in Systemen, die mit jeder der gewünschten Kombinationen von System-Ressourcen angeordnet sind, und das Zusammenstellen von statistischen Daten zu dem Verhalten, das bei dieser Anordnung auftritt, umfassen. Ein Beispiel für eine System-Ressource, die auf diese Weise getestet werden kann, ist ein Systemspeicher, und das Auftreten eines System- oder Anwendungsabsturzes kann als formales Maß verwendet werden, das als Grundlage der statistischen Daten verwendet wird, wie es zum Beispiel mithilfe von Protokollüberwachungs-Software ermittelt wird, die das Windows-Ereignisprotokoll überwacht. Es ist möglich, einen einzelnen Testfall unter zahlreichen Speicherbedingungen zu testen, um das Profil des „Charakters” der Speichernutzung oder des nichtfunktionalen „Aspekts” des Software-Programms in Bezug auf die Nutzung von Rechen-Ressourcen, in diesem Beispiel von Speicher, einzustufen, derselbe Ansatz kann jedoch auch auf Steckplätze, CPU-Einheiten usw. angewendet werden. Es ist zu erwarten, dass die Testfälle tendenziell fehlschlagen, wenn der verfügbare Speicher über ein bestimmtes Niveau hinaus abnimmt, was in realen Umgebungen einfach deshalb auftreten kann, weil er von anderen Anwendungen in Anspruch genommen wird.
Zweckmäßigerweise können die Wiederholungen von Tests mit Rückgriff auf eine Betriebs-/Ausführungsumgebung durchgeführt werden, die die Einrichtung ihrer Rechen-Ressourcen über eine Programmierschnittstelle ermöglicht. Ein Beispiel könnte eine virtuelle Maschine sein, die der Reihe nach mit verschiedenen Ressourcen-Parametern neu gestartet werden kann. In einer solchen Umgebung können der Speicher, die Anzahl der Prozessoren oder die Anzahl verfügbarer Steckplätze usw. abhängig von dem zu testenden Parameter leicht neu definiert werden. Die Gesamtergebnisse aus der Durchführung der zahlreichen Tests kann verwendet werden, um die mittlere Versagenswahrscheinlichkeit zum Beispiel im Hinblick auf eine Anzahl schlecht ausgeführter Testfälle in Bezug auf die Gesamtzahl und/oder ihre Varianz des Auftretens zu schätzen.
Wenn eine Testbedingung durch einen Punkt in einem mehrdimensionalen Raum gekennzeichnet wird, in dem jede Achse eine Rechen-Ressource ist, kann für jede Testbedingung eine Wahrscheinlichkeitsdichteverteilung (probability density distribution, PDF) geschätzt und jedem Punkt mit Parameterwerten für den Mittelwert und die Varianz zugeordnet werden. Wenn die Anzahl der Testfallwiederholungen oberhalb eines Schwellenwerts liegt (der Schwellenwert selbst kann mithilfe von Analysen von Signifikanztests berechnet werden), zum Beispiel oberhalb von 1.000, kann von einer normalen (gaußschen) PDF ausgegangen werden. Der/die geschätzte durchschnittliche Mittelwert und Varianz kann zur Laufzeit für eine dynamische Schätzung der Wahrscheinlichkeit, dass ein Anwendungsversagen derselben Anwendung auftritt, nur aus den aktuellen Betriebsbedingungen der verfügbaren Rechen-Ressource angewendet werden.
2 zeigt ein Beispiel eines Leistungsmodells in Form eines mehrdimensionalen Raums 200. Insbesondere entsprechen, wie dargestellt, die x-Achse 210 und die y-Achse 220 der verfügbaren CPU und dem verfügbaren Speicher, wobei sich der Ursprung unten links befindet. Die z-Achse 230 stellt indessen die Fehlerwahrscheinlichkeit dar. Die Fehlerwahrscheinlichkeit wird bevorzugt normalisiert, um eine Fehlerwahrscheinlichkeit unter Standardbedingungen zu erhalten, wobei die Fehlerwahrscheinlichkeit die prozentuale Wahrscheinlichkeit dafür darstellen kann, dass ein Fehler in einem/einer vorgegebenen Zeitraum, Anzahl von Zyklen, Wiederholungen usw. auftritt. Wie in 2 dargestellt, wird eine Fläche 240, die aus einer Reihe von Punkten 241 entsprechend einer dichten Matrix von Werten besteht, definiert, sodass für jede Kombination eines Satzes von definierten, regelmäßig beabstandeten Werten auf der x- und der y-Achse ein Wert einer Fehlerwahrscheinlichkeit vorhanden ist. Die Abstände zwischen Werten auf der x-Achse und Werten auf der y-Achse können so gewählt werden, dass sie der Granularität von Messwerten von dem Betriebssystem oder anderen Software-Anwendungen zur Systemüberwachung entsprechen, sodass die Ausgabe der Überwachungs-Software direkt einem Wert der Fehlerwahrscheinlichkeit zugeordnet werden kann. Die Abstände zwischen den Werten auf der x-Achse und den Werten auf der y-Achse können so gewählt werden, dass sie erheblich kleiner als die Granularität von Messwerten von dem Betriebssystem oder anderen Software-Anwendungen zur Systemüberwachung sind, sodass für jede Ausgabe der Überwachungs-Software eine x-y-Kombination vorhanden ist, die nur einen sehr kurzen Abstand zu dem gemessenen Wert aufweist, der direkt dazu verwendet werden kann, eine gute Näherung eines Fehlerwahrscheinlichkeitswertes bereitzustellen. Ein Vorteil dieses Ansatzes besteht darin, dass er nicht von einem bestimmten Betriebssystem oder einer bestimmten Überwachungs-Software abhängig ist, sodass das Modell in einer Vielzahl verschiedener Umgebungen eingesetzt werden kann. Die Abstände zwischen Werten auf der x-Achse und Werten auf der y-Achse können mit jedem geeigneten Wert gewählt werden, beispielsweise so, dass der Wert auf der z-Achse zwischen zwei angrenzenden Punkten sich nicht um mehr als eine vorgegebene Spanne ändert. Wenn Messwerte von dem Betriebssystem oder anderen Software-Anwendungen zur Systemüberwachung zwischen einer Reihe von Kombinationen von x-y-Werten liegen, kann eine Interpolation aus benachbarten Punkten durchgeführt werden, um einen Wert für die gemessenen Werte zu schätzen. Statt die Fläche als einen Satz von Punkten zu speichern, kann gemäß bestimmten Ausführungsformen die Form der gesamten Fläche interpoliert werden, um eine Funktion abzuleiten, die die Fläche als Ganzes beschreibt, woraus nach Bedarf ein Fehlerwahrscheinlichkeitswert für jede x-y-Kombination abgeleitet werden kann. Ein Vorteil dieses Ansatzes ist, dass möglicherweise weniger Speicherplatz erforderlich ist.
3 zeigt ein weiteres Beispiel eines Leistungsmodells in Form eines mehrdimensionalen Raums 300. Die x-Achse 210, die y-Achse 220 und die z-Achse 230 entsprechen denjenigen, die mit Bezug auf 2 beschrieben worden sind. Wie in 3 dargestellt, wird eine Fläche 340 definiert, die aus einer Reihe von Punkten 341 entsprechend einer dünn besetzten Matrix von Werten besteht, sodass für ausgewählte Kombinationen von Werten auf der x- und auf der y-Achse ein Fehlerwahrscheinlichkeitswert vorhanden ist. Im Vergleich zu dem Ansatz von 2 enthält das Leistungsmodell gemäß der Ausführungsform von 2 im Allgemeinen weniger Daten für eine ähnliche Menge an Informationen oder mehr Informationen für eine gleichwertige Menge an Daten. Der Abstand zwischen allen Punkten kann so gewählt werden, dass er erheblich kleiner als die Granularität von Messwerten von dem Betriebssystem oder anderen Software-Anwendungen zur Systemüberwachung ist, sodass für jede Ausgabe der Überwachungs-Software eine x-y-Kombination vorhanden ist, die nur einen sehr kurzen Abstand von dem gemessenen Wert aufweist, der direkt dazu verwendet werden kann, eine gute Näherung eines Fehlerwahrscheinlichkeitswertes bereitzustellen. Ein Vorteil dieses Ansatzes besteht darin, dass er nicht von einem bestimmten Betriebssystem oder einer bestimmten Überwachungs-Software abhängig ist, sodass das Modell in einer Vielzahl verschiedener Umgebungen eingesetzt werden kann. Der Abstand zwischen Werten auf der x-Achse und Werten auf der y-Achse kann mit jedem geeigneten Wert gewählt werden, beispielsweise so, dass der Wert auf der z-Achse zwischen zwei angrenzenden Punkten sich nicht um mehr als eine vorgegebene Spanne ändert. Wenn Messwerte von dem Betriebssystem oder anderen Software-Anwendungen zur Systemüberwachung zwischen einer Reihe von Kombinationen von x-y-Werten liegen, kann eine Interpolation aus benachbarten Punkten durchgeführt werden, um einen Wert für die gemessenen Werte zu schätzen. Statt die Fläche als einen Satz von Punkten zu speichern, kann gemäß bestimmten Ausführungsformen die Form der gesamten Fläche interpoliert werden, um eine Funktion abzuleiten, die die Fläche als Ganzes beschreibt, woraus ein Fehlerwahrscheinlichkeitswert für jede x-y.
Die 2 und 3 zeigen zwar eine dreidimensionale Fläche, die die Fehlerwahrscheinlichkeit für Kombinationen von zwei Systembedingungsvariablen darstellt, es ist jedoch zu erkennen, dass alle Aspekte der vorhergehenden Erörterung an jede Anzahl von Systembedingungsvariablen angepasst werden kann, das heißt, ein Raum kann mehr als drei Dimensionen aufweisen. Das Modell kann folglich eine Vielzahl verschiedener Sätze von Leistungswerten beinhalten, wobei jeder Satz sich auf einige oder alle Messwerte bezieht. Die vorgegebenen System-Ressourcen können mindestens eines des Folgenden umfassen: eine verfügbare System-CPU-Kapazität, ein verfügbarer Systemspeicher, ein verfügbarer Systemdatenträger oder verfügbare Netzwerksteckplätze.
Wie oben mit Bezug auf 2 und 3 beschrieben, kann ein Schritt des Ermittelns, ob das Leistungsmodell einen Leistungswert umfasst, der den Messwerten genau entspricht, und in einem Fall, in dem das Leistungsmodell keinen Leistungswert umfasst, der den Messwerten genau entspricht, des Beziehens eines oder mehrerer angrenzender Leistungswerte aus dem Leistungsmodell, die jeweils einem oder mehreren nächsten verfügbaren Messwerten entsprechen, bereitgestellt werden. Alternativ kann der weitere Schritt des Interpolierens eines Leistungswertes aus den benachbarten Leistungswerten bereitgestellt werden.
Ein bedeutender Vorteil besteht darin, dass „Leistungsmodelle” eine formale und wissenschaftliche (folglich zwischen Anwendungen und Systemen vergleichbare) Dokumentation für Verhaltensaspekte einer Anwendung über ihre gewöhnlichen funktionalen Aspekte hinaus sein können. Durch diese Verlagerung ergibt sich eine sehr große Zahl möglicher Anwendungsgebiete dieser Beschreibung.
Es ist zu erkennen, dass Leistungsmodelle gemäß der vorliegenden Erfindung den Vergleich von Kapazitäten ähnlicher Produkte erleichtern können. Damit dies zweckmäßig ist, sollte für die verschiedenen Produkte im Idealfall eine gemeinsame Definition der Leistungsaussagen, anhand derer die Leistung gemessen wird, und der Ressourcen-Definitionen, die die Achsen des Raums bilden, verwendet werden. Dies sollte zumindest über verschiedene Versionen derselben Produkte hinweg möglich sein und kann sogar für verschiedene Marken möglich sein.
4 stellt die Schritte einer zweiten Ausführungsform der vorliegenden Erfindung dar. Der Prozess in 4 ist derselbe wie derjenige in 3, beschreibt jedoch ausführlich bestimmte beispielhafte Teilschritte des Schritts 110 der Bereitstellung eines Leistungsmodells. Genauer gesagt, 4 stellt ein mögliches Verfahren zum Erstellen eines solchen Leistungsmodells dar. Wie gezeigt, beginnt der in dem Teilschritt 110 definierte Prozess bei Schritt 411, in dem die Ressourcen eines Testsystems zum Zweck einer Testausführung eingerichtet werden. Wie oben erörtert, kann dies abhängig von der Art des Testsystems selbst auf vielfältige Weise realisiert werden, zum Beispiel durch geeignetes Einrichten einer virtuellen Maschine, eines Anwendungs-Servers usw. Der Prozess geht als Nächstes zu Schritt 413 über, während dessen die Anwendung überwacht wird und alle Fehler aufgezeichnet werden. Nachdem die Anwendung bis zu Ende oder durch vorgegebene Testfolgen hindurch oder über einen vorgegebenen Zeitraum hinweg ausgeführt worden ist, geht der Prozess zu Schritt 415 über, in dem untersucht wird, ob die Anwendung mit jeder der verschiedenen Testsystemanordnungen ausgeführt worden ist, die zum Erstellen des Leistungsmodells erforderlich ist. Wenn dies nicht der Fall ist, kehrt der Prozess zu Schritt 411 zurück, in dem das Testsystem in die nächste erforderliche Anordnung versetzt wird, sodass der Prozess jede erforderliche Anordnung der Reihe nach in einer Schleife durchläuft. Wenn die Anwendung mit jeder der verschiedenen Testsystemanordnungen ausgeführt worden ist, die zum Erstellen des Leistungsmodells erforderlich ist, geht der Prozess zu Schritt 416 über, in dem die durch jede Wiederholung von Schritt 415 aufgezeichneten Fehler zusammen mit den Systemanordnungen, die jeweils bei jedem Fehler gültig waren, verarbeitet werden, um das Leistungsmodell zu erstellen, wie oben erörtert. Nachdem das Leistungsmodell ordnungsgemäß erstellt worden ist, kann es entweder zusammen mit einer Kopie der Anwendung oder auf andere Weise an einen Benutzer der Anwendung verteilt werden, woraufhin der Prozess bei Schritt 120 fortfährt, wie oben beschrieben.
Die Berechnung des Leistungsmodells wird bevorzugt durch automatisches Durchführen einer großen Anzahl von Tests (durch Nutzen von Testautomatisierungstechniken, die in den Entwicklungs-Teams weit verbreitet sind) erzeugt, indem die durch einen Anwendungs-Server verfügbar gemachten Ressourcen für jede Anwendung schrittweise verändert werden und die „Leistung” dieses Punktes durch einfaches Zählen der an diesem Punkt erfolgreich bestandenen Tests nachverfolgt wird (d. h., dass der Ausführungstest in einem Qualitätskriterium bestanden worden ist).
Alternativ zu Anwendungs-Servern kann dieselbe Prozedur in jeder Hosting-Umgebung angewendet werden, in der für Anwendungen bestimmte Ressourcen durch Programmierung eingerichtet oder gesteuert werden können.
Mit dieser Prozedur wird ein Bild des Verhaltens der Anwendung bei verschiedenen Betriebsbedingungen abgeleitet.
Gemäß einer Weiterentwicklung der Schritte in 4 oder anderweitig können die folgenden Schritte durchgeführt werden, um das Leistungsmodell zu definieren:

1) Festlegen einer Liste von Testfällen, um Anwendungsfunktionen abzudecken
2) Festlegen einer Liste zu berücksichtigender logischer Ressourcen, wie beispielsweise Folgende: CPU-Einheit, Speicher, Datenträger, Steckplätze usw.
3) Festlegen einer Liste von Qualitätsdefinitionen: „Probleme” werden als nicht erfülltes Qualitätsmaß definiert (ein bestimmtes Schlüsselwort, das im System- oder Anwendungsprotokoll aufgetreten ist, Leistungsergebnisse aus einer internen/externen Überwachung, aus Leistungsmesseinrichtungen usw.). Diese Definition kann zumindest mit dem übereinstimmen, was mit handelsüblicher Überwachungs-Software auf der handelsüblichen Plattform überwacht werden kann (es könnten Einzelheiten bereitgestellt werden, die Software-Pakete und -Plattformen angeben).
4) Festlegen und Codifizieren, wie logische Ressourcen an physische Ressourcen und Betriebssystem-Ressourcen gebunden werden (im vereinfachten Fall könnte es sich dabei um 1 zu 1 handeln), das heißt, für ein besseres Zusammenwirken mit der Überwachungs-Software ist es am besten, die Leistungsmessgrößen auf der Grundlage eines Satzes von Messwerten zu berechnen, die direkt von handelsüblichen Ressourcen-Überwachungspaketen in ihrem systemeigenen Format verfügbar sind. Die Anwendung könnte mehrere Matrizen (beispielsweise für verschiedene Plattformen oder für verschiedene unterstützte Überwachungs-Software) für eine Art von vorhergesagtem „Versagen/Problem” darstellen.
5) Betrachten jeder Ressource als Achse eines mehrdimensionalen Raumes r(l..NR). Jede Zelle soll bei 0 beginnen.
6) Auswählen einer Anzahl von Stichprobenpunkten auf jeder Achse des mehrdimensionalen Raumes auf einer bestimmten Granularitätsstufe und Darstellen des geprüften Raums mit einer NR-dimensionalen, dünn besetzten Matrix von Ganzzahlwerten Failure Space[i1][i2]...[iNR]
7) Erstellen einer Liste der resultierenden Testpunkte, wobei jeder Punkt aus einem einzelnen Testfall aus Schritt 1) stammt und durch eine Monte-Carlo-Variation der Eingabeparameter der Anwendung für jedes einzelne vorgegebene Testszenario bezogen wird.
8) Ausführen jedes resultierenden Testpunktes, der in Schritt 7) erstellt wurde, für alle in Schritt 6) ausgewählten Stichprobenpunkte, wobei jedes Mal die für die Anwendung verfügbaren Ressourcen (Ressourcen-Kontextvektor) gemäß dem durch den Stichprobenpunkt bezeichneten Ressourcen-Vektor verändert werden, und Sammeln der Ergebnisse (Versagensfälle oder nicht): Jedes Versagen/Problem führt zu einer Erhöhung des Wertes in der entsprechenden Matrixzelle (die bei 0 beginnt). Wiederholen des Prozesses für jeden Testfall an Punkt 1).
9) Schätzen der resultierenden Parameter des Versagensmodells, das heißt, für jeden Punkt des „Versagensraums” Schätzen der Wahrscheinlichkeit, dass ein Versagen auftritt, gemäß folgendem Verfahren: Schrittweises Addieren (beginnend bei 0) der Anzahl an Versagensfällen/kritischen Zuständen/Fehlern, die bei der Durchführung jedes Testfalls bei einer bestimmten Ressourcen-Bedingung (Ressourcen-Kontext) in der Zelle des Versagensraums Failure space[i1][12]...[iN] auftraten, die diesen Ressourcen-Kontext der Testfalldurchführung darstellt.

Das resultierende Leistungsmodell wird bevorzugt vor der Verteilung gefüllt, und das Leistungsmodell wird mit der Software verteilt, beispielsweise durch Packen in einem Archiv, das zusammen mit der Anwendung, auf die es sich bezieht, einzusetzen ist. Alternativ kann das Modell über einen getrennten Kanal verteilt werden, beispielsweise durch Herunterladen über ein Netzwerk usw.
Das Leistungsmodell wird dann zum Zeitpunkt der Ausführung zum Beispiel zusammen mit einer Ressourcen-Überwachungs- oder Ressourcen-Vorhersage-Software (mithilfe von Vergangenheitsdaten) verwendet.
Die Ausführungsumgebung lädt die Anwendung und ruft ihr Zuverlässigkeitsmodell ab, ein Satz von Rechen-Ressourcen der Ausführungsumgebung wird als durch eine ausgewählte Ressourcen-Vorhersage/Überwachungs-Software vorherzusagen/zu überwachen bestimmt.
Der vorhergesagte/überwachte Satz an Ressourcen wird anschließend dazu verwendet, einen Vektor von Werten zusammenzustellen, der einem Punkt in einem Ressourcen-Raum entspricht, der als Ressourcen-Kontextvektor verwendet werden kann. Die Ressourcen-Verwaltungseinheit greift auf das Zuverlässigkeitsmodell zu und ruft den verfügbaren Zuverlässigkeitswert an dem durch den Ressourcen-Kontextvektor bezeichneten Punkt durch Lesen des Wertes in dem Modell oder durch Interpolieren aus den verfügbaren nächstgelegenen Punkten in dem Modell ab.
5 stellt die Schritte einer dritten Ausführungsform der vorliegenden Erfindung dar. Der Prozess in 5 ist derselbe wie derjenige in 3, beschreibt jedoch ausführlich bestimmte weitere Schritte zwischen den Schritten 140 und 150. Genauer gesagt, 5 stellt eine Möglichkeit der Verwendung des Leistungswerts dar, der in Schritt 140 aus dem Leistungsmodell bezogen wurde. Statt nach dem Schritt 140 direkt zu Schritt 150 überzugehen, geht der Prozess wie dargestellt zu Schritt 541 über, in dem ermittelt wird, ob der in Schritt 140 bezogene Leistungswert unter einen vorgegebenen Schwellenwert fällt. Gemäß der vorliegenden Ausführungsform stellt dieser vorgegebene Schwellenwert ein vertretbares Leistungsniveau dar. Bei diesem Schwellenwert kann es sich um einen Wert handeln, der speziell mit der Anwendung, einem bestimmten Benutzerkonto, einer bestimmten Maschine, der Uhrzeit, zu der die Anwendung ausgeführt wird, usw. in Zusammenhang steht. Es kann eine Hierarchie von Anwendungen definiert sein, wobei der Schwellenwert für eine bestimmte Anwendung so durch ihre Position in dieser Hierarchie definiert wird, dass wichtigere oder dringendere Anwendungen als weniger fehlertolerant betrachtet werden, sodass für diese Anwendungen ein niedrigerer Schwellenwert festgelegt wird. Wenn sich herausstellt, dass sich das Leistungsniveau oberhalb des Schwellenwerts befindet, was darauf hindeutet, dass die Anwendung gemäß dem Leistungsmodell unter den bestehenden Betriebsbedingungen zufriedenstellend arbeiten sollte, geht der Prozess zu Schritt 150 über, wie oben beschrieben. Wenn sich demgegenüber herausstellt, dass sich das Leistungsniveau unter oder auf dem Schwellenwert befindet, was darauf hindeutet, dass die Anwendung gemäß dem Leistungsmodell unter den bestehenden Betriebsbedingungen nicht zufriedenstellend arbeiten sollte, beispielsweise insofern, als die Wahrscheinlichkeit eines Absturzes oberhalb eines bestimmten Wertes liegt, geht der Prozess zu Schritt 542 über. In Schritt 542 führt der Prozess Schritte aus, die dazu bestimmt sind, die Probleme im Zusammenhang mit der erwarteten schlechten Leistung der Anwendung zu verringern. Das System kann zum Beispiel einen Benutzer der Anwendung, einen Systemverwalter oder eine andere Person automatisch auf die erwartete schlechte Leistung aufmerksam machen, beispielsweise mithilfe eines Aufklappfensters, einer eMail usw. Das System kann außerdem automatisch Schritte zur Behebung der Situation dadurch durchführen, dass es versucht, weitere Ressourcen zu beziehen, indem es entweder die Betriebsumgebung selbst neu definiert oder indem es weniger wichtige Anwendungen oder Prozesse beendet. Dementsprechend werden die Schritte des Warnens eines Benutzers, wenn der Leistungswert unter einen vorgegebenen Schwellenwert fällt, oder des Versuchens, automatisch eine erhöhte Ressourcen-Zuweisung von dem System für die Software auszuhandeln, wenn der Leistungswert unter einen vorgegebenen Schwellenwert fällt, bereitgestellt.
Als Weiterentwicklung des Obigen ist vorstellbar, dass ein System eine Anzahl von Anwendungen im Zusammenhang mit Leistungsmodellen gemäß der vorliegenden Erfindung ausführt. Wo dies der Fall ist, kann das System versuchen, diesen verschiedenen Anwendungen System-Ressourcen so zuzuweisen, dass die Gesamtleistung optimiert wird.

2) Der vorhergesagte/überwachte Satz an Ressourcen wird anschließend dazu verwendet, einen Vektor von Werten zusammenzustellen, der einem Punkt in einem Ressourcen-Raum entspricht, der als Ressourcen-Kontextvektor verwendet werden kann:
3) Durch Angeben des vorhergesagten Kontext-Ressourcen-Vektors des Leistungsmodells wird für den gegebenen Kontext eine Wahrscheinlichkeit von Versagensfällen/Problemen erhalten.
4) In dieser Phase könnte der Administrator einen Schwellenwert festgelegt haben, sodass die Ressourcen-Verwaltungseinheit, wenn das System diesen Wert überschreitet, eine Reihe von Maßnahmen veranlassen kann, um diese wahrscheinlichen Probleme zu vermeiden, wie zum Beispiel folgende:
a) Benachrichtigungen an Administratoren
b) Neuzuweisen/Erhöhen der Ressourcen (Migration auf andere Verbundknoten), die der Anwendung zur Verfügung gestellt werden, beispielsweise durch Zusammenwirken mit einem Bereitstellungssystem
c) Automatisches Erhöhen der Rate der Systemprotokollierung und/oder der Vielfalt der protokollierten Datentypen.

Gemäß einer weiteren Ausführungsform wird ein Leistungs- oder Zuverlässigkeitsmodell bereitgestellt, das das Verhalten einer Anwendung unter verschiedenen Bedingungen von System-Ressourcen darstellt. Dieses Modell kann die Form einer oder mehrerer dünn besetzter Matrizen haben, die Zuverlässigkeits- oder Leistungswerte für verschiedene Kombinationen von Bedingungen bereitstellen. Dieses Modell wird an einen Benutzer der Anwendung verteilt und wird während der Ausführung der Anwendung mit Bezug auf Daten zu System-Ressourcen, die durch das Betriebssystem oder eine andere Überwachungs-Software bereitgestellt werden, abgefragt, um eine Angabe über die erwartete Leistung der Anwendung unter den bestehenden Betriebsbedingungen bereitzustellen. Diese Angabe kann einem Benutzer mitgeteilt werden, beispielsweise in einem Fall, in dem die Angabe außerhalb der Grenzen eines zufriedenstellenden Betriebs fällt. Das System kann außerdem versuchen, die zugewiesenen System-Ressourcen neu auszuhandeln, um die Leistung zu verbessern.

Es ist zu beachten, dass bei bestimmten realen Anwendungen die Leistung bei unterschiedlichen Betriebsbedingungen schwanken kann. Gemäß bestimmten Ausführungsformen können verschiedene Testszenarien entwickelt werden, um verschiedene Aspekte der Software-Leistung zu testen. Solche Szenarien können häufig auftretende Systemereignisse wie zum Beispiel „Neuen Benutzer beim System registrieren” nachvollziehen. Ebenso kann das Leistungsmodell auch so strukturiert werden, dass es Teilabschnitte umfasst, die sich jeweils auf verschiedene Aspekte von Software-Leistung beziehen oder die verschiedenen Anwendungsszenarien entsprechen. Diese Aspekte und/oder Anwendungsszenarien können zweckmäßigerweise den in der Testphase verwendeten Aspekten/Testszenarien entsprechen. Diese Aspekte können in Form von getrennten Leistungsräumen darstellt werden. Wenn das Leistungsmodell auf diese Weise strukturiert wird, kann es wünschenswert sein, verschiedene Teile des Leistungsmodells beispielsweise mithilfe von „Markierungen” (tags), die das Szenario oder einen Teilabschnitt des Szenarios kennzeichnen, verschiedenen Szenarien zuzuordnen. Eine Möglichkeit, ein Szenario oder einen Teilabschnitt eines Szenarios auf diese Weise zu kennzeichnen, bestünde in Form der damit verbundenen Arbeitsauslastung, da verschiedene Grade der Arbeitsauslastung zu getrennten „Leistungsräumen” führen. Wie in der folgenden Tabelle dargestellt, beinhaltet das Leistungsmodell einen Leistungsraum, der den Systemereignissen ”Neuen Benutzer beim System registrieren” entspricht, und Leistungsteilräume, die der Situation, in der 1 bis 20 Benutzer mit dem System verbunden sind, und einer weiteren, in der 21 bis 100 Benutzer mit dem System verbunden sind, entsprechen, auf der Grundlage, dass sich das System bei diesen beiden Auslastungsszenarien unterschiedlich verhält.

FVT-Szenario	FVT-Szenario – Beschreibung	Leistung Teilraum	Kommentar (Beispiel)
neuen Benutzer beim System registriere n	1 bis 20 Benutzer mit dem System verbunden	Modell 1.A	Bei weniger als 100 MB freiem Speicher pro Benutzer beginnt das System wahrscheinlich, schlecht zu funktionieren.
neuen Benutzer beim System registriere n	21 bis 100 Benutzer mit dem System verbunden	Modell 1.B	Bei weniger als 1.000 MB freiem Speicher pro Benutzer beginnt das System wahrscheinlich, schlecht zu funktionieren.

Gemäß bestimmten Ausführungsformen, die ein Mehrraummodell wie oben beschrieben nutzen, wird eine Eingabebeschreibungskomponente bereitgestellt, die die Eingabekanäle der Anwendung überwacht, um eine Beschreibung der aktuellen Eingabebedingung bereitzustellen und aus dieser Klassifizierung den am besten geeigneten mehrdimensionalen Raum auszuwählen, der das Leistungsverhalten darstellt.
Gemäß einer bevorzugten Ausführungsform wird jeder Testfall vor einer Automatisierung des Tests mit einer Technik wie z. B. der Monte-Carlo-Technik erweitert, um genügend Stichprobenwerte zum Berechnen einer statistischen Verteilung in ausgewählten Fällen bereitzustellen. Insbesondere beinhaltet der Schritt des Testens der Software in Systemen, die mit jeder der gewünschten Kombinationen von System-Ressourcen eingerichtet sind, bevorzugt das Definieren der gewünschten Kombinationen von System-Ressourcen in zufälliger oder pseudo-zufälliger Weise. Stärker bevorzugt wird, die gewünschten Kombinationen von System-Ressourcen, die die gewünschten Kombinationen von Testbedingungen bilden, mithilfe von Monte-Carlo-Variationen von Testparametern wie zum Beispiel System-Ressourcen-Parametern zu definieren.
Noch weiter können Aspekte der Schritte von Testfällen selbst mithilfe von zufälligen, pseudozufälligen oder Monte-Carlo-Variationen von Startwerten definiert werden. Beispielsweise kann ein allgemeiner Testfall das Bereitstellen von Eingabeparametern umfassen, die als Eingabe an eine bestimmte Anwendung übergeben werden, wie zum Beispiel den Prozess ,Neuen Benutzer erstellen', der Parameter wie beispielsweise den Vornamen und den Nachnamen erfordert.
System-Ressourcen können bei den verschiedenen zulässigen Permutationen von 16 Bedingungen variieren, bei denen zum Beispiel 3 verfügbare Speicherpunkte (10 MB, 100 MB, 1.000 MB) und 3 verfügbare Betriebspunkte einer CPU-Einheit (10%, 50%, 90%) variieren.
Es ist jedoch zu erkennen, dass in manchen Fällen ein einziger Test mit einer bestimmten Kombination von Parametern möglicherweise keine zuverlässige Darstellung des Verhaltens der Software bereitstellt. Beispielsweise kann das Verhalten der Software oder insbesondere die Weise, in der es von der Verfügbarkeit bestimmter Ressourcen abhängig ist, von den Einzelheiten des Testfalls selbst abhängen. In dem Fall des oben angedeuteten Prozesses ,Neuen Benutzer erstellen' ist es zum Beispiel möglich, dass das System abhängig von dem in dem Testfall verwendeten Namen in unterschiedlicher Weise System-Ressourcen in Anspruch nimmt.
Dementsprechend kann es unvertretbar sein, Schlüsse auf der Grundlage von Software-Verhalten zu ziehen, das während einer Reihe von Wiederholungen desselben identischen Testfalls gemessen worden ist. Es wird dementsprechend vorgeschlagen, Variationen in die Einzelheiten einiger oder aller Testfälle aufzunehmen, um sicherzustellen, dass jeder Testfall den ausgewählten Aspekt der Ressourcen-Abhängigkeit einer Software unabhängig von den Besonderheiten der verwendeten Daten in geeigneter Weise testet.
Statt einen festgelegten Benutzernamen für den Prozess ,Neuen Benutzer erstellen' zu verwenden, kann im Fall des vorliegenden Beispiels ein zufällig oder pseudozufällig erzeugter Benutzername für jede neue Testfallwiederholung erzeugt werden, sodass mit bestimmten Testdaten in Zusammenhang stehende Abweichungen durch Erfassen der Messwerte für die Software-Leistung über eine Reihe von Wiederholungen hinweg ausgeschlossen werden können.
Folglich kann bei dem vorliegenden Beispiel der Prozess ,Neuen Benutzer erstellen' zum Beispiel 1.000-mal durchgeführt werden, wobei jedes Mal ein anderer Benutzererstellungsparameter verwendet wird, z. B. indem der Vorname (zufällig) einem Vornamenverzeichnis und der Nachname (zufällig) einem Nachnamenverzeichnis entnommen wird. Wenn auf dieser Grundlage festgestellt wird, dass bei den ausgewählten Einstellungen für die System-Ressourcen bei 900 von 1.000 Testwiederholungen ein Versagen auftritt, kann eine abschließende Versagenswahrscheinlichkeit von 0,9 ermittelt werden.
Dieser Prozess kann anschließend für jeden weiteren Satz von Parametern wiederholt werden, wie oben beschrieben. Bei der Erzeugung von Variationen von Testfalldaten können erneut Monte-Carlo-Techniken angewandt werden.
Wenn die Testfälle T1...TN so definiert sind, dass sie alle Anwendungsfunktionen abdecken, können im Besonderen für einen gegebenen Testfall T1 abhängig von dem technischen Rahmen Variationen der von T1 benötigten Daten in der Größenordnung von 1.000 erforderlich sein, wobei zu berücksichtigen ist, dass es, falls die Zahl der möglichen Variationen durch das System selbst beschränkt wird, möglicherweise sinnlos ist, Variationen über die Realisierungsmöglichkeiten des Systems hinaus zu suchen. Dementsprechend werden die Tl Eingabeparameter so variiert, dass T1_1...T1_1000 simulierte Testfälle erzielt werden, anschließend T2_1...T2_1000, bis TN_1...TN_1000:
Wenn durch die Stichprobenprüfung des Ressourcen-Raums 16 Ressourcen-Bedingungen identifiziert werden, werden z. B. nur Speicher- und Datenträger-Ressourcen berücksichtigt, und auf ihren entsprechenden Achsen werden 4 Stichprobenpunkte berücksichtigt.
Jede Testfallvariation T1_1...T1_1000, T2_1...T2_1000, TN_1...TN_1000 wird dann in 4 verschiedenen Ressourcen-Kontexten T1_1_1...T1_1_4 und so weiter für jedes Tx_y ausgeführt. Durch die Ausführung insgesamt wird der Versagensraum (Failures_Space) gefüllt. Die Anzahl der Monte-Carlo-Variationen und der Ressourcen-Stichprobenpunkte sind gemäß Erwägungen zur statistischen Signifikanz auszuwählen.
Folglich wird gemäß der vorliegenden Ausführungsform die Software für eine gegebene Kombination von System-Ressourcen eine Vielzahl von Malen ausgeführt. Bevorzugt werden für jede Ausführung der Software mit einer bestimmten Kombination von System-Ressourcen verschiedene Werte für die Eingabedaten definiert, die für die Ausführung erforderlich sind. Die verschiedenen Werte können bevorzugt zufällig definiert werden. Die verschiedenen Werte können bevorzugt pseudozufällig definiert werden. Die verschiedenen Werte können bevorzugt mithilfe von Monte-Carlo-Variationen definiert werden. Solche Monte-Carlo-Variationen können selbst an einem Standardstartwert oder einem zufällig ausgewählten Startwert (seed value) beginnen.
Die Erfindung kann eine reine Hardware-Ausführungsform, eine reine Software-Ausführungsform bzw. eine Ausführungsform sein, die sowohl Hardware- als auch Software-Elemente enthält. Bei einer bevorzugten Ausführungsform wird die Erfindung in Software umgesetzt, was Firmware, residente Software, Mikrocode usw. einschließt, jedoch nicht darauf beschränkt ist.
Die Erfindung kann des Weiteren die Form eines Computerprogrammprodukts annehmen, auf das von einem computerverwendbaren bzw. computerlesbaren Medium zugegriffen werden kann, das Programmcode zur Verwendung durch bzw. in Verbindung mit einem Computer bzw. einem beliebigen Befehlsausführungssystem bereitstellt. Im Sinne dieser Beschreibung kann ein computerverwendbares bzw. computerlesbares Medium jede Vorrichtung sein, die das Programm zur Verwendung durch das System, die Vorrichtung bzw. Einheit zur Befehlsausführung bzw. in Verbindung mit diesen enthalten, speichern, austauschen, übertragen, bzw. transportieren kann.
6 stellt eine Computerumgebung dar, die zum Umsetzen bestimmter Ausführungsformen geeignet ist. Wie in 6 dargestellt, umfasst das Computersystem 600 einen Prozessor 610, einen Hauptspeicher 620, eine Massenspeicher-Schnittstelle 630, eine Anzeigenschnittstelle 640 und eine Netzwerk-Schnittstelle 650. Insbesondere kann es sich bei dem Computersystem 600 zumindest teilweise um eine virtuelle Maschine handeln. Viele der Komponenten des Systems 600 stellen System-Ressourcen dar, die in verschiedenen Kombinationen während der Testphase variiert werden können, wie oben beschrieben. Diese Systemkomponenten werden durch Verwendung eines Systembusses 601 verbunden, der über eine bestimmte Übertragungskapazität verfügt, die ein Beispiel für eine System-Ressource darstellt, die in verschiedenen Kombinationen variiert werden kann, wie oben beschrieben. Die Massenspeicher-Schnittstelle 630 wird dazu verwendet, die Massenspeichereinheiten (ein Festplattenlaufwerk 655, das ein Beispiel für eine System-Ressource darstellt, die in verschiedenen Kombinationen variiert werden kann, wie oben beschrieben) mit dem Computersystem 600 zu verbinden. Ein bestimmter Typ eines Wechselspeicher-Schnittstellenlaufwerks 662 ist ein Diskettenlaufwerk, das Daten auf einer Diskette 695 speichern oder von dieser lesen kann, andere Typen von computerlesbaren Speichermedien sind jedoch vorstellbar, wie zum Beispiel ein Laufwerk für lesbare und optional beschreibbare CD-ROMs. In ähnlicher Weise wird eine Benutzereingabe-Schnittstelle 644 bereitgestellt, die Benutzerinteraktionen von Schnittstelleneinheiten wie zum Beispiel einer Maus 665 und einer Tastatur 664 empfängt. Noch weiter wird eine Druckerschnittstelle 646 bereitgestellt, die Signale an einen Drucker 666 senden und optional von diesem empfangen kann.
Der Hauptspeicher 620, der ein Beispiel für eine System-Ressource darstellt, die in verschiedenen Kombinationen variiert werden kann, wie oben gemäß den bevorzugten Ausführungsformen beschrieben, enthält Daten 622 und ein Betriebssystem 624.
Das Computersystem 600 nutzt bestens bekannte Mechanismen der virtuellen Adressierung, die es den Programmen des Computersystems 600 ermöglichen, sich so zu verhalten, als hätten sie lediglich Zugriff auf eine einzige große Speichereinheit statt auf mehrere kleinere Speichereinheiten wie den Hauptspeicher 620 und das Festplatten-Laufwerk 655, die ein Beispiel für eine System-Ressource darstellen, die in verschiedenen Kombinationen variiert werden kann, wie oben beschrieben. Obgleich gezeigt wird, dass sich die Daten 622 und das Betriebssystem 624 im Hauptspeicher 620 befinden, ist daher für Fachleute zu erkennen, dass diese Elemente nicht zwangsläufig alle gleichzeitig vollständig im Hauptspeicher 620 enthalten sind. Es ist außerdem zu beachten, dass der Begriff „Speicher” hier verwendet wird, um allgemein auf den gesamten virtuellen Speicher des Computersystems 600 Bezug zu nehmen.
Die Daten 622 stellen alle Daten dar, die als Eingabe in ein Programm oder Ausgabe aus einem Programm in dem Computersystem 200 dienen, und können insbesondere die Testanwendung beinhalten. Bei dem Betriebssystem 424 handelt es sich um ein Multitasking-Betriebssystem, das in der Branche als OS/400 bekannt ist; für Fachleute ist jedoch zu erkennen, dass der Gedanke und Umfang der vorliegenden Erfindung nicht auf ein Betriebssystem beschränkt ist.
Der Prozessor 610 kann aus einem oder mehreren Mikroprozessoren und/oder integrierten Schaltungen erstellt sein. Die Kapazität des Prozessors stellt ein Beispiel für eine System-Ressource dar, die in verschiedenen Kombinationen variiert werden kann, wie oben beschrieben. Der Prozessor 610 führt im Hautspeicher 620 gespeicherte Programmbefehle aus. Der Hauptspeicher 620 speichert Programme und Daten, auf die der Prozessor 610 zugreifen kann. Wenn das Computersystem 600 hochfährt, führt der Prozessor 610 zunächst die Programmbefehle aus, die das Betriebssystem 624 bilden. Bei dem Betriebssystem 624 handelt es sich um ein hoch entwickeltes Programm, das die Ressourcen des Computersystems 600 verwaltet. Bei einigen dieser Ressourcen handelt es sich um den Prozessor 610, den Haupt- oder Systemspeicher 620, die Massenspeicher-Schnittstelle 630, die Anzeigenschnittstelle 640, die Netzwerk-Schnittstelle 650 und den Systembus 601.
Wenngleich das Computersystem 600 so dargestellt wird, dass es nur einen einzigen Prozessor und einen einzigen Systembus beinhaltet, ist für Fachleute zu erkennen, dass die vorliegende Erfindung unter Verwendung eines Computers umgesetzt werden kann, der mehrere Prozessoren und/oder mehrere Busse aufweist. Darüber hinaus beinhalten die in der bevorzugten Ausführungsform verwendeten Schnittstellen jeweils getrennte, vollständig programmierte Mikroprozessoren, die dazu verwendet werden, den Prozessor 610 von rechenintensiven Verarbeitungsvorgängen zu entlasten. Für Fachleute ist jedoch zu erkennen, dass die vorliegende Erfindung gleichermaßen Computersysteme betrifft, die einfach E/A-Adapter verwenden, um ähnliche Funktionen auszuführen.
Die Anzeigenschnittstelle 640 wird dazu verwendet, eine oder mehrere Anzeigen 660 direkt mit dem Computersystem 600 zu verbinden. Diese Anzeigen 660, bei denen es sich um nicht programmierbare (d. h. intelligenzlose) Endgeräte oder um vollständig programmierbare Arbeitsplatzrechner handeln kann, werden verwendet, um Systemadministratoren und Benutzern zu ermöglichen, Daten mit dem Computersystem 600 auszutauschen. Es ist jedoch zu beachten, dass das Computersystem 600, wenngleich die Anzeigenschnittstelle 640 bereitgestellt wird, um einen Datenaustausch mit einer oder mehrerer Anzeigen 660 zu ermöglichen, nicht zwangsläufig eine Anzeige 665 benötigt, da die gesamte erforderliche Wechselwirkung mit Benutzern und anderen Prozessen über die Netzwerk-Schnittstelle 650 stattfinden kann.
Die Netzwerk-Schnittstelle 650, die ein Beispiel für eine System-Ressource darstellt, die in verschiedenen Kombinationen variiert werden kann, wie oben beschrieben, wird dazu verwendet, andere Computersysteme und/oder Arbeitsplatzrechner (z. B. 675 in 6) über ein Netzwerk 670 mit dem Computersystem 600 zu verbinden. Die vorliegende Erfindung hat ungeachtet dessen, wie das Computersystem 600 mit anderen Computersystemen und/oder Arbeitsplatzrechnern verbunden werden kann, unabhängig davon, ob die Netzwerkverbindung 670 mithilfe heutiger analoger und/oder digitaler Techniken oder über einen zukünftigen Vernetzungsmechanismus hergestellt wird, gleichermaßen Gültigkeit. Darüber hinaus können zahlreiche verschiedene Netzwerkprotokolle zum Realisieren eines Netzwerks verwendet werden. Bei diesen Protokollen handelt es sich um spezialisierte Computerprogramme, die Computern ermöglichen, Daten über das Netzwerk 670 auszutauschen. TCP/IP (Transmission Control Protocol/Internet Protocol, Übertragungssteuerungsprotokoll/Internetprotokoll) ist ein Beispiel für ein geeignetes Netzwerkprotokoll, beispielsweise über ein Ethernet-Netzwerk. Wie gezeigt, verbindet das Netzwerk 670 das System 600 mit zwei weiteren Einheiten 671 und 672, bei denen es sich um andere Computersysteme ähnlich dem oben beschriebenen oder um andere netzwerkfähige Einheiten wie Drucker, Leitwegrechner usw. handeln kann. In dem vorliegenden Beispiel handelt es sich bei der Netzwerkeinheit 672 um einen lokalen Server, der über einen Modem 681 mit einem öffentlichen Netzwerk 680 wie zum Beispiel dem World Wide Web verbunden ist. Mithilfe dieses öffentlichen Netzwerks 680 kann eine Verbindung mit einer/einem entfernt angeordneten Einheit oder System 685 aufgebaut werden.
An dieser Stelle muss darauf hingewiesen werden, dass die vorliegende Erfindung zwar im Zusammenhang eines voll funktionsfähigen Computersystems beschrieben wurde bzw. weiterhin beschrieben wird, Fachleuten jedoch ersichtlich ist, dass die vorliegende Erfindung als Programmprodukt in einer Vielfalt von Formen vertrieben werden kann und dass die vorliegende Erfindung unabhängig von dem jeweiligen Typ der signaltragenden Medien, die für die eigentliche Verteilung verwendet werden, gleichermaßen gültig ist. Zu Beispielen für ein geeignetes signaltragendes Medium zählen: beschreibbare Medien wie zum Bespiel Disketten und CD-ROMs (z. B. 695 in 6) und Übertragungsmedien wie zum Beispiel digitale und analoge Datenübertragungsverbindungen.
Bei dem Medium kann es sich um ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- bzw. Halbleitersystem (bzw. eine entsprechende Vorrichtung oder Einheit) oder ein Übertragungsmedium handeln. Zu Beispielen für ein computerlesbares Medium zählen ein Halbleiter- bzw. Festkörperspeicher, ein Magnetband, eine entfernbare Computer-Diskette, ein Speicher mit wahlfreiem Zugriff (random access memory, RAM), ein Festwertspeicher (read-only memory, ROM), eine starre Magnetplatte und eine optische Speicherplatte. Zu aktuellen Beispielen für optische Speicherplatten zählen eine CD-ROM (compact disk read only memory, Kompakt-Disk-Festwertspeicher), eine CD-R/W (compact disk read/write, Compact-Disk-Schreib-Lese-Speicher) und eine DVD.
Ein Datenverarbeitungssystem, das zum Speichern und/oder Ausführen von Programmcode geeignet ist, beinhaltet zumindest einen Prozessor, der direkt bzw. indirekt durch einen Systembus mit Speicherelementen verbunden ist. Die Speicherelemente können einen lokalen Speicher, der während der tatsächlichen Ausführung des Programmcodes eingesetzt wird, einen Massenspeicher und Cachespeicher beinhalten, die eine zeitweilige Speicherung von zumindest einem Teil des Programmcodes bereitstellen, um die Häufigkeit zu verringern, mit der der Code während der Ausführung aus dem Massenspeicher abgerufen werden muss.
Eingabe/Ausgabe- bzw. E/A-Einheiten (zum Beispiel Tastaturen, Anzeigen, Zeigeeinheiten usw., jedoch nicht auf diese beschränkt) können entweder direkt oder durch eingreifende E/A-Steuereinheiten mit dem System verbunden sein.
Netzwerkadapter können ebenfalls mit dem System verbunden werden, um dem Datenverarbeitungssystem zu ermöglichen, durch eingreifende private bzw. öffentliche Netzwerke mit anderen Datenverarbeitungssystemen bzw. entfernt angeordneten Druckern oder Speichereinheiten verbunden zu werden. Modems, Kabelmodems und Ethernet-Karten sind nur einige der gegenwärtig verfügbaren Arten von Netzwerkadaptern.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 5655074 [0003]

Claims

Verfahren zum Optimieren einer Software-Ausführung in einem System, in dem die Software ausgeführt wird, wobei das Verfahren folgende Schritte umfasst: Bereitstellen eines Leistungsmodells, das die Leistung der Software unter verschiedenen ausgewählten Systembedingungen darstellt, wie im Hinblick auf eine oder mehrere vorgegebene System-Ressourcen beschrieben; Empfangen eines Messwerts der vorgegebenen System-Ressourcen für einen bestimmten Zeitpunkt; und Beziehen eines Leistungswerts von dem Leistungsmodell entsprechend den Messwerten.
Verfahren nach einem der vorangehenden Ansprüche, das einen weiteren Schritt des Füllens des Leistungsmodells durch Testen der Software umfasst.
Verfahren nach Anspruch 2, wobei das Testen der Software das wiederholte Ausführen der Software in Systemen, die mit jeder Kombination von ausgewählten System-Ressourcen eingerichtet sind, und das Zusammenstellen von statistischen Daten zu dem Verhalten der Anwendung bei dieser Anordnung umfasst.
Verfahren nach Anspruch 3, wobei die Software für eine gegebene Kombination von System-Ressourcen eine Vielzahl von Malen ausgeführt wird.
Verfahren nach Anspruch 4, wobei für jede Ausführung der Software bei einer vorgegebenen Kombination von System-Ressourcen verschiedene Werte für die Eingabedaten, die für die Ausführung erforderlich sind, zufällig, pseudozufällig oder mithilfe von Monte-Carlo-Variationen von ihnen definiert werden.
Verfahren nach Anspruch 3, wobei es sich bei den Systemen, die mit jeder der gewünschten Kombinationen von System-Ressourcen eingerichtet sind, um virtuelle Maschinen handelt.
Verfahren nach Anspruch 2, wobei das Modell vor dem Vertrieb gefüllt wird und wobei das Leistungsmodell mit der Software vertrieben wird.
Verfahren nach einem der vorangehenden Ansprüche, das den weiteren Schritt des Ermittelns, ob das Leistungsmodell einen Leistungswert umfasst, der den Messwerten genau entspricht, und in einem Fall, in dem das Leistungsmodell keinen Leistungswert umfasst, der den Messwerten genau entspricht, des Beziehens eines oder mehrerer angrenzender Leistungswerte aus dem Leistungsmodell, die jeweils einem oder mehreren nächsten verfügbaren Messwerten entsprechen, umfasst.
Verfahren nach Anspruch 8, das den weiteren Schritt des Interpolierens eines Leistungswertes aus den benachbarten Leistungswerten umfasst.
Verfahren nach einem der vorangehenden Ansprüche, das den weiteren Schritt des Warnens eines Benutzers umfasst, wenn der Leistungswert unter einen vorgegebenen Schwellenwert fällt.
Verfahren nach einem der vorangehenden Ansprüche, das den weiteren Schritt des Versuchens umfasst, automatisch eine erhöhte Ressourcen-Zuweisung von dem System für die Software auszuhandeln, wenn der Leistungswert unter einen vorgegebenen Schwellenwert fällt.
Verfahren nach einem der vorangehenden Ansprüche, wobei das Leistungsmodell eine mehrdimensionale Matrix umfasst.
Verfahren nach einem der vorangehenden Ansprüche, wobei das Modell eine Vielzahl verschiedener Sätze von Leistungswerten beinhaltet, wobei jeder Satz sich auf einige oder alle Messwerte bezieht.
Verfahren nach einem der vorangehenden Ansprüche, wobei die vorgegebenen System-Ressourcen von Folgendem mindestens eines umfasst: eine verfügbaren System-CPU-Kapazität, ein verfügbarer Systemspeicher, ein verfügbarer Systemdatenträger oder verfügbare Netzwerksteckplätze.
Vorrichtung, die ein Mittel umfasst, das zum Ausführen jedes Schritts des Verfahrens nach einem der Ansprüche 1 bis 14 geeignet ist.
Computerprogramm, das Befehle zum Ausführen der Schritte des Verfahrens nach einem der Ansprüche 1 bis 14 umfasst, wenn das Computerprogramm auf einem Computer ausgeführt wird.
Leistungsmodell nach einem der Ansprüche 1 bis 14, wenn das Computerprogramm auf einem Computer ausgeführt wird.
Computerlesbares Medium, in dem ein Computerprogramm nach Anspruch 16 oder ein Leistungsmodell nach Anspruch 17 codiert ist.