next up previous contents
Next: 4.3.3 Realisierung der Sicherheit Up: 4.3.2 Messung von Antwortzeiten Previous: 4.3.2.1 Netzwerkebene

4.3.2.2 Applikationsebene

 Die Anforderung für die Messung von Antwortzeiten auf Applikationsebene wurde bereits in Kapitel 2.3.3 hergeleitet. In diesem Abschnitt soll nun ein Konzept für die Realisierung dargestellt werden.
Zu Beginn ist zu überprüfen, welche Applikationen durch ein Service-Level-Agreement festgelegte Dienstgüteparameter aufzuweisen hat. Ist dies geschehen, wird anhand der folgenden Schritte eine Überwachung der entsprechenden Werte realisiert.
1.
Definition der Transaktionen
Beginnend bei den für den Nutzer sichtbaren Transaktionen werden Blöcke definiert, die in der Regel auch Service-Level-Agreements zugrunde liegen.
2.
Analyse der Transaktionen
Wie ist diese Transaktion aufgebaut? Bestehen Abhängigkeiten zu externen Komponenten? In diesem Fall liegt eine Client/ Server Beziehung vor, wie sie in Abbildung bla dargestellt ist.
3.
Bestimmung der zu messenden (Sub-)Transaktionen
Welche (Sub-)Transaktionen sind relevant für die Messung des Service Level? Wer kann die gemessenen Daten verwerten? Welche korrigirenden Maßnahmen können aufgrund nicht zufriedenstellender Werte ergriffen werden? Es ist sinnvoll, nur die Werte zu messen, die auch genutzt werden können. Durch diese einfachen Fragen kann schnell festgestellt werden, welche Transaktionen gemessen werden sollen.
4.
Instrumentierung der Applikation
Ist die Applikation nicht bereits durch den Entwickler mit einer Management-Schnittstelle ausgestattet, so ist sie in diesem Schritt zu instrumentieren. Zur Auswahl stehen mittlerweile eine Vielzahl von Entwicklungswerkzeuge, von denen einige in Abschnitt 3.4 dargestellt worden.
5.
Entwicklung einer Management-Applikation oder Integration in eine bestehende Plattform
Abschließend müßte eine Möglichkeit implementiert werden, auf die gemessenen Daten zuzugreifen und diese auszuwerten. Hierzu kann eine eigene Applikation entworfen werden, oder man integriert das zuvor entworfene System in eine bestehende Management-Plattform.
Im folgenden wird nun eine Konzept für die Überwachung der Antwortzeit eines WWW-Dienstes dargestellt.
Da nicht bekannt ist, ob die durch die BMW-Händler genutzten Applikationen bereits Management-Schnittstellen aufweisen, wird hier auf der Grundlage der in Abschnitt 3.4.3.4 erfolgten Bewertung die ARM-API der CMG als Entwicklungswerkzeug ausgewählt.
Ziel der Instrumentierung ist es, die Dauer einer Transaktion zu messen, in der eine Web-Seite geladen wird. Dabei soll es möglich sein, die dafür benötigte Zeit einzelnen Subtransaktionen zuzuordnen.
Dieser Vorgang läuft wie folgt ab [Tanen 98] (vereinfacht):
1.
Der Browser ermittelt eine URL (Benutzereingabe, ...).
2.
Der Browser fragt DNS nach der IP-Adresse des zu der URL gehörigen Web-Servers.
3.
DNS gibt die gewünschte IP-Adresse zurück.
4.
Der Brower baut eine TCP Verbindung auf.
5.
Der Browser fordert mittels HTTP eine Datei an.
6.
Der verbundene Server sendet die gewünschte Datei.
7.
Die TCP-Verbindung wird getrennt.
8.
Der Browser zeigt die empfangene Datei an.
Interessant ist in diesem Ablauf die Zeit die benötigt wird, um eine URL aufzulösen (2.-3.) und die Zeit, die benötigt wird, eine Datei aus dem WWW zu empfangen (4.-7.).
  
Abbildung: Konzept einer transaktionsorientierten Antwortzeitüberwachung eines Web-Browsers
\begin{figure}
 \begin{center}
 \leavevmode
 \epsfxsize = \textwidth
 
\epsfbox {./Bilder/ArmKonzept.eps}

 \end{center}\end{figure}

In Abbildung 4.6 ist dargestellt, wie mit Hilfe eines Agenten, der die Anwendung überwacht, eine solche Zeitmessung zu realisieren ist.
Die benötigte Architektur besteht aus einem Flexiblen Management Agenten, der neben der Überwachung der Applikation auch andere Aufgaben erfüllt, einem Agenten, der direkt über ein entsprechendes Interface mit dem Web-Browser verbunden ist und dem Web-Browser selber.
Der Browser wird so instrumentiert, daß er die oben beschriebenen Zeitspannen kennzeichnet und dem Agenten jeweils Anfang und Ende dieser Transaktionen mitteilt. Daraus resultieren drei unterschieldiche Transaktionen:
1.
Transaktion A: beginnt mit der Bestätigung der URL durch den Benutzer und endet nach der Darstellung der dazugehörigen Seite. Diese Transaktion beinhaltet die (Sub-)Transaktionen B und C.
2.
Transaktion B beginnt mit der Anfrage an den DNS-Server und endet mit der Erhalt der dazugehörigen IP-Adresse.
3.
Transaktion C beginnt mit dem Verbindungsaufbau zu dem Web-Server und endet mit der Darstellung der HTML-Seite. Es ist darauf zu achten, daß die Länge dieser Transaktion von der Größe der übertragen Datei abhängt. Diese Information muß bei der Auswertung berücksichtigt werden. Unter Umständen ist es sinnvoll, den Verbindungsaufbau zum Web-Server getrennt zu Messen.
Die Ergebnisse dieser Messungen werden anschließend dem FMA übergeben, der sie dann entsprechend seiner Vorgaben an den Manager weiterreicht. Hierbei ist zu beachten, daß der FMA die Daten in einer Form übergeben bekommt, in der die Korrelation der Sub-Transaktionszeiten zu der Haupttransaktion möglich ist.


next up previous contents
Next: 4.3.3 Realisierung der Sicherheit Up: 4.3.2 Messung von Antwortzeiten Previous: 4.3.2.1 Netzwerkebene
Copyright Munich Network Management Team