55 lines
11 KiB
TeX
55 lines
11 KiB
TeX
|
\epigraph{\textit{Perhaps we are asking the wrong questions. }}{--- Agent Brown, \textit{The Matrix}}
|
||
|
|
|
||
|
|
\noindent Im folgenden werden die verwendete Technologien vorgestellt und die benötigten Grundlagen besprochen. Dies umfasst neben einer kurzen Vorstellung des \gls{kieker} Monitoring Frameworks in \autoref{sec:grundKieker} sowie der Programmiersprache Perl in \autoref{sec:grundPerl} auch eine Beschreibung des EPrints-System im allgemeinen und der angepassten Variante \gls{kielpr} in \autoref{sec:grundKielprints}. Schließlich wird dann in \autoref{sec:grundPerformance} eine Einführung in das \gls{moni} gegeben.
|
||
|
|
|
||
|
|
\section{Kieker Monitoring Framework}\label{sec:grundKieker}
|
||
|
|
\gls{kieker}\footnote{\url{http://www.kieker-monitoring.net} (Zuletzt aufgerufen 2013-03-19)} ist ein System zum \gls{moni} und zur Analyse des Laufzeit-Verhaltens einer Software. Es wird seit 2006 in der Arbeitsgruppe Software Engineering an der CAU Kiel entwickelt. Frühere Versionen von \gls{kieker} waren primär auf das \gls{moni} von Java-Anwendungen ausgerichtet, doch wurden bereits ergänzende Module entwickelt oder befinden sich zur Zeit in der Entwicklung um zum Beispiel .NET oder COBOL mit \gls{kieker} analysieren zu können. Seit 2011 wird \gls{kieker} von der SPEC Research Group als empfohlenes Tool im SPEC RG Software Verzeichnis\footnote{\url{http://research.spec.org/projects/tools.html} (Zuletzt aufgerufen 2013-03-20)} angeboten.
|
||
|
|
|
||
|
|
\begin{figure}
|
||
|
|
\centering
|
||
|
|
\includegraphics[width=0.96\textwidth]{images/kiekerComponentDiagram-woCloud-bw-w-record-newNames-withTraceAnalysis-colors}
|
||
|
|
\caption[Kieker Komponentendiagramm]{Kieker Komponentendiagramm \citep{Kieker1.7UserGuide}}
|
||
|
|
\label{fig:KiekerComponentDiagram}
|
||
|
|
\end{figure}
|
||
|
|
|
||
|
|
Wie in \autoref{fig:KiekerComponentDiagram} dargestellt besteht \gls{kieker} aus den zwei zentralen Komponenten \textsf{Kieker.Monitoring} und \textsf{Kieker.Analysis}. Die Monitoring-Komponente stellt Klassen und Methoden zum Instrumentieren und Überwachen der Software zur Verfügung. Hierzu werden von \emph{\glspl{probe}} Messungen vorgenommen und hierzu \emph{\glspl{record}} erstellt. Diese \emph{\glspl{record}} werden dann an einen \emph{Monitoring Writer} übergeben, der die Informationen in eine Log-Datei schreibt oder mit einem Stream an die Analysis-Komponente übergibt. Zur Instrumentierung des Systems stehen manuelle Methoden, also das statische Einfügen der \emph{\glspl{probe}} in den Quelltext, aber auch automatische Mechanismen zur Verfügung, welche zum Beispiel mittels \emph{AspectJ} die Programmstruktur analysieren und automatisch die benötigten Messpunkte erzeugen \citep{Kieker1.7UserGuide,KiekerICPE2012,KiekerTR2009}.
|
||
|
|
|
||
|
|
\noindent Die Analyse der erhaltenen Daten wird mittels \textsf{Kieker.Analysis} durchgeführt. Diese Komponente liest die \emph{\glspl{record}} ein und stellt einen konfigurierbaren Ablauf zum Filtern, Analysieren und Visualisieren der Daten bereit. Hierbei können zum Beispiel Sequenzdiagramme oder Abhängigkeitsbäume erzeugt werden um das Verhalten der Anwendung zu beschreiben \citep{Kieker1.7UserGuide,KiekerICPE2012,KiekerTR2009}.
|
||
|
|
|
||
|
|
Die \textsf{Kieker.Monitoring}-Komponente wird in dieser Arbeit mit der parallel zu dieser Arbeit neu entwickelten Kieker-Data-Bridge erweitert um die Schnittstelle zwischen den Programmiersprachen Java und Perl zu überbrücken. Die Perl-Module sowie die Kieker-Data-Bridge werden in \autoref{cha:perl} ausführlicher erläutert.
|
||
|
|
|
||
|
|
\section{Die Programmiersprache Perl}\label{sec:grundPerl}
|
||
|
|
Die Programmiersprache Perl\footnote{\url{http://www.perl.org} (Zuletzt aufgerufen 2013-03-20)} ist eine imperative, plattformunabhängige, interpretierte Programmiersprache. Die erste Version wurde 1987 vorgestellt und hat seine Wurzeln primär in C und awk \citep{PerlHistory}. Die aktuelle Version ist Perl 5.16, die im Mai 2012 veröffentlicht wurde. Perl ist eine interpretierte Programmiersprache, also werden die Programme nicht zu einer nativen Anwendung übersetzt sondern mit einem Interpreter ausgeführt. Der Perl-Interpreter ist für alle relevanten Betriebssysteme verfügbar und in vielen Systemen bereits integriert. Neben der Verwendung des Interpreters im Betriebsystems wird der Interpreter auch häufig in Webserver eingebettet \citep{modPerl}.
|
||
|
|
|
||
|
|
In Perl werden verschiedenste Programmierparadigmen umgesetzt, allerdings ist es dem Programmierer freigestellt, welche dieser Möglichkeiten er umsetzen will. So ist zum Beispiel die Objektorientierung ein Teil der Sprache, allerdings nicht wie in Java erzwungen sondern mit verschiedenen Modulen optional verfügbar. Auch stellt Perl häufig mehrere Optionen für die selben Probleme bereit, so können häufig Befehle verkürzt werden oder es stehen mehrere äquivalente Befehle zur Verfügung. Dies führt allerdings sehr schnell zu schlechter Lesbarkeit der Programme, da Perl auch eine sehr freie Syntax ermöglicht. Zeilenumbrüche und Leerzeichen sind weitgehend bedeutungslos und führen zu einem sehr unterschiedlichen Code-Format und sehr persönlichen Gestaltungen der Programme \citep{perlsyn}.
|
||
|
|
|
||
|
|
Perl verwendet keine expliziten Typen und verfügt nur über die Datenstrukturen \gls{skalar}, \gls{array} bzw. Liste sowie \glspl{hash} \citep{perldata}. Wird mit Perl objektorientiert programmiert, so werden normale Variablen mit einem Attribut versehen, das die Klasse definiert (\emph{\glspl{blessvar}}). Diese Variablen verfügen intern über ein Hash zum Speichern ihrer Attribute und können auf Methoden der Klasse zugreifen \citep{perlobj}.
|
||
|
|
|
||
|
|
\section{EPrints \& Kielprints}\label{sec:grundKielprints}
|
||
|
|
Das System \gls{eprints} ist eine quelloffene Webplattform zur Veröffentlichung von Publikationen, Forschungsberichten oder anderen Dokumenten. Die Plattform implementiert dabei das OAI-PMH\footnote{Open Archives Initiative Protocol for Metadata Harvesting} Protokoll und ist somit ein Projekt zur Umsetzung von Open Access. \gls{eprints} wurde initial von der University of Southampton entwickelt und unter der \citep{gpl} lizenziert. Die Plattform wurde in Perl implementiert und steht zur Zeit in der Version 3.3 zum Download\footnote{\url{http://www.eprints.org/software/} (Zuletzt aufgerufen 2013-03-20)} bereit.
|
||
|
|
|
||
|
|
An der Universität Kiel wird die Software \gls{kielpr} verwendet, was eine angepasste Version von \gls{eprints}, basierend auf EPrints 3.2., ist. Betrieben wird diese Plattform durch das Kieler Datenmanagement Team am GEOMAR | Helmholtz-Zentrum für Ozeanforschung Kiel. Das Deployment der Anwendung ist in \autoref{fig:deploy} grob skizziert.
|
||
|
|
|
||
|
|
\begin{figure}
|
||
|
|
\centering
|
||
|
|
\includegraphics[width=0.6\textwidth]{images/Kielprints-Deployment}
|
||
|
|
\caption{Deployment der Kielprints-Anwendung}
|
||
|
|
\label{fig:deploy}
|
||
|
|
\end{figure}
|
||
|
|
|
||
|
|
Wie bereits angesprochen sind im laufenden Betrieb einige Performance-Probleme aufgetreten, speziell bei einigen Seiten zur Administration. Hierbei treten mitunter Wartezeiten von über 10 Sekunden auf, obwohl sich die Datenbank mit 15050 Publikationen und 1090 Autoren\footnote{Stand: 2013-03-20, 12:50} noch in üblichen Größenordnungen bewegt.
|
||
|
|
|
||
|
|
\section{Monitoring}\label{sec:grundPerformance}
|
||
|
|
Beim \gls{moni} werden während der Ausführung einer Anwendung Messdaten erzeugt und anschließend anhand dieser Messdaten das Verhalten der Anwendung analysiert. Aufgrund der Art der Datenerfassung wird diese Analyse auch dynamische Analyse genannt. Das Verfahren steht als ergänzendes Mittel zur statischen Analyse zur Verfügung, bei welchem die Software anhand ihres Quelltextes analysiert wird. Allerdings ist die statische Analyse für umfangreichere Softwaresysteme nur schwierig durchführbar, da hier zum Beispiel alle theoretisch möglichen Programmpfade ausgewertet werden. Mit der dynamischen Analyse können die tatsächlich ausgeführten Programmpfade ermittelt werden und direkt das Verhalten der Anwendung nachvollzogen werden \citep[vgl. auch][]{schmalenbach2007performancemanagement}.
|
||
|
|
Mit verschiedenen Techniken können dann auch bei Bedarf nur Teile der Anwendung beobachtet werden und der Fokus auf bestimmte Programmteile gelegt werden. Dies kann einerseits durch verschiedene Instrumentierungstechniken, andererseits durch Filterung der erhaltenen Daten erreicht werden.
|
||
|
|
|
||
|
|
Zur Durchführung des Monitorings wird der Quelltext des Programms mit \emph{\glspl{probe}} versehen, welche verschiedene Ereignisse im Programmablauf protokollieren. Hierbei sind häufig Verzweigungen, Sprünge oder Funktionsaufrufe besonders von Interesse \citep[S. 38]{cau15489}, aber auch andere Ereignisse wie Anfragen an Datenbanken können protokolliert werden.
|
||
|
|
|
||
|
|
Mit den erhaltenen Messdaten wird eine Analyse und Visualisierung durchgeführt um das Verhalten der Anwendung zu dokumentieren. Hierbei werden zum Beispiel UML Sequenzdiagramme erstellt oder das zeitliche Verhalten der Anwendung detailliert untersucht. Auch kann ein Abhängigkeitsgraph erstellt werden, der die Verschränkung der verschiedenen Komponenten zeigt, oder eine statistische Analyse durchgeführt werden \citep{probDeterm}
|
||
|
|
|
||
|
|
Eine Sonderform der dynamischen Analyse ist das \emph{\gls{profil}}. Hierbei wird die Analyse eingesetzt um das Verhalten eines existierenden Softwaresystems auf Funktionsebene zu erfassen. Dies wird zum Beispiel in Modernisierungsprozessen verwendet. Da Anwendungen häufig im Betrieb modifiziert und weiterentwickelt werden und hierbei mitunter die Dokumentation der Änderungen nur untergeordneten Charakter gegenüber der Funktionalität genießt, weicht häufig das dokumentierte Verhalten von dem tatsächlich beobachteten ab. Diese Differenzen können durch das \emph{\gls{profil}} erkannt werden und in den Modernisierungsprozess eingebunden werden \citep{cau15489}.
|
||
|
|
|
||
|
|
\noindent Der Schwerpunkt dieser Arbeit wird auf dem \emph{\gls{profil}} sowie auf dem \emph{Performance Monitoring} liegen. Hierbei wird eine möglichst präzise Zeitmessung im Programmablauf durchgeführt und dieser Zeitcode in den \emph{\glspl{record}} eingefügt. Somit kann nicht nur die Aufrufreihenfolge sondern auch der zeitliche Ablauf, also konkret die Dauer zur Ausführung einer Funktion und auch die Häufigkeit der Ausführung, festgestellt werden. Es können dann besonders lang und/oder häufig laufende Funktionen identifiziert werden um Ansatzpunkte für Performanceprobleme aufzuzeigen. Neben der Zeit können noch weitere Systemdaten wie CPU-Auslastung oder Speicherverbrauch protokolliert werden. Das \gls{kieker} Framework unterstützt für diesen Zweck neben Kontrollflussdaten auch \emph{\glspl{record}} welche die Systemauslastung protokollieren oder die Systemzeit messen. Aufgrund der Erweiterbarkeit von \gls{kieker} können auch beliebige weitere \emph{\glspl{record}} erzeugt werden.
|
||
|
|
|
||
|
|
Der Hauptunterschied zwischen \emph{\gls{profil}} und \emph{Performance Monitoring} besteht darin, dass beim \emph{Performance Monitoring} die Anwendung kontinuierlich im laufenden Betrieb untersucht wird. Beim \emph{\gls{profil}} werden in der Regel Testfälle ausgeführt um eine möglichst gute Abdeckung nach klassischen Testkriterien wie Pfad-, Zweig- oder Anweisungsüberdeckung zu erreichen.
|