nbw-bt/Proposal/LaTeX/proposal.tex

\input{docstyleDE}

% Einrichtung von Paket Glossaries
\usepackage[ngerman]{translator}
\usepackage[xindy,toc,style=altlistgroup]{glossaries}
\input{glossary} % Glossardaten ausgelagert
\makeglossaries

% PDF Metadaten
\hypersetup{pdftitle=Monitoring von Perl-basierten Webanwendungen mittels Kieker}
\hypersetup{pdfauthor=Nis Börge Wechselberg}
\hypersetup{pdfsubject=Proposal zur Bachelor-Arbeit}
\hypersetup{pdfkeywords=}

% Dokumenteninhalt
\begin{document}

% Präambel (Deckblatt, Inhalt, ...)
\frontmatter
  \thesistitlepage
    {Monitoring von Perl-basierten\\[.1em]Webanwendungen mittels Kieker}% Title
    {Proposal zur Bachelor-Arbeit}% Thesistype
    {Nis Börge Wechselberg}% Name
    {\today}% Date
    {Dipl.-Inf. Peer Brauer}
  
  \tableofcontents

% Hauptteil
\mainmatter

\chapter{Einleitung}
Dieses Proposal soll zur genauen Definition des Themas und des Umfangs der Bachelorarbeit dienen. Hierzu wird zunächst die Zielsetzung der Arbeit und eine Einordnung in das umgebende Themenfeld vorgestellt. Anschließend werden die benötigten und verwendeten Technologien und Softwaresysteme vorgestellt.

Hierauf aufbauend wird dann das geplantes Vorgehen für die Lösung der Problemstellung aufgezeigt.

%\section{Zielsetzung der Arbeit}  %Auskommentiert um Gliederungsfehler zu vermeiden
Die Bachelorarbeit trägt den Arbeitstitel \emph{Monitoring von Perl-basierten Webanwendungen mittels \gls{kieker}}. Somit soll in der Arbeit zunächst ein Monitoringverfahren für Perl-Anwendungen im Allgemeinen und Webanwendungen im speziellen etabliert werden. Das \gls{moni} soll hierbei mit dem \gls{kieker} Framework geschehen, welches bisher primär auf Java-Anwendungen ausgerichtet war. In mehreren Abschlussarbeiten wurden unter anderem bereits Erweiterungen für .NET oder COBOL sowie COM entwickelt, allerdings ist bisher noch kein \gls{moni} von Perl-Anwendungen möglich. Somit muss zunächst ein System entwickelt werden um Perl-Anwendungen mit \emph{\glspl{probe}} zu versehen und diese Daten anschließend an \gls{kieker} zu übergeben. Hierbei liegt der Fokus auf dem \emph{performance monitoring}, also der Erfassung des zeitlichen Verhaltens der Anwendung.

Mit diesen \emph{\glspl{probe}} soll dann zunächst eine isolierte Testanwendung instrumentiert werden und das Verhalten der Anwendung ausgewertet werden. Hierbei können erste Ergebnisse zu dem Einfluss der \emph{\glspl{probe}} auf die Laufzeit der Anwendung und das korrekte Verhalten der Probes ermittelt werden.

Sobald diese Tests erfolgreich abgeschlossen sind, sollen dann die Probes in die Anwendung Kielprints eingeführt werden. Diese Plattform wird vom Geomar Helmholtz-Zentrum betrieben und in der letzten Zeit sind hier einige Probleme mit dem Laufzeitverhalten beobachtet worden. Durch das Monitoring kann dann das Verhalten der Anwendung im Betrieb beobachtet werden. Es soll versucht werden Ursachen für Leistungseinbußen zu lokalisieren und Optimierungspotential in der Anwendung aufgezeigt werden.

Bei ausreichender Zeit können dann noch weitere Funktionen für die Perl-Schnittstelle implementiert werden wie Optionen zur automatischen oder teil-automatischen Instrumentierung der Anwendung oder andere Monitoringoptionen.


\chapter{Ziele \& Technologien}
Im folgenden werden kurz die wichtigsten Technologien und Softwaresysteme vorgestellt, welche im Rahmen dieser Bachelor-Arbeit eingesetzt werden sollen. Zuvor wird auf das Verfahren des Performance Monitorings (\ref{sec:perfmoni}) eingegangen um den Zweck dieser Systeme zu verdeutlichen. Die verwendeten Softwaresysteme umfassen neben der Programmiersprache Perl (\ref{sec:perl}) primär das Monitoring Framework \gls{kieker} (\ref{sec:kieker}). Das zu untersuchende System \gls{eprints} wird ebenfalls kurz vorgestellt (\ref{sec:eprints}) um die Rahmenbedingungen zu erläutern. Zum Abschluss werden dann die Ziele der Arbeit aufgelistet (\ref{sec:ziele}).

\section{Performance Monitoring}
\label{sec:perfmoni}
Beim Monitoring, auch dynamische Analyse genannt, werden während der Ausführung einer Anwendung Messdaten erzeugt und anschließend anhand dieser Messdaten das Verhalten der Anwendung analysiert. Dieses Verfahren steht als ergänzendes Mittel zur statischen Analyse, bei welchem die Software anhand ihres Quelltextes analysiert wird. Allerdings ist die statische Analyse für umfangreichere Softwaresysteme nur schwierig durchführbar. Mit der dynamischen Analyse können die tatsächlich ausgeführten Programmpfade ermittelt werden und direkt das Verhalten der Anwendung nachvollzogen werden.(\cite[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.

Die dynamische Analyse wird auch häufig eingesetzt um das Verhalten eines existierenden Softwaresystems in Modernisierungsprozessen zu erfassen. 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 geniest, weicht häufig das dokumentierte Verhalten von dem tatsächlich beobachteten ab. Diese Differenzen können durch die dynamische Analyse erkannt werden und in den Modernisierungsprozess eingebunden werden.

Zur Durchführung des Monitorings wird der Quelltext des Programms mit sogenannten Probes versehen, welche verschiedene Ereignisse im Programmablauf protokollieren. Hierbei sind häufig Verzweigungen, Sprünge oder Funktionsaufrufe besonders von Interesse, aber auch andere Ereignisse wie Anfragen an Datenbanken können protokolliert werden. 

Mit diesen Messdaten kann dann eine Analyse und Visualisierung durchgeführt werden um das Verhalten der Anwendung zu dokumentieren. Hierbei werden dann zum Beispiel UML Sequenz Diagramme erstellt oder das zeitliche Verhalten der Anwendung detailliert untersucht.

Der Schwerpunkt dieser Arbeit wird 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. Somit können dann besonders lang und/oder häufig laufende Funktionen identifiziert werden um Ansatzpunkte für Performanceprobleme aufzuzeigen. Neben der Zeit können bei Bedarf auch noch weitere Systemdaten wie CPU-Auslastung oder Speicherverbrauch protokolliert werden.

\section{Kieker Monitoring Framework}
\label{sec:kieker}
\gls{kieker}\footnote{\url{http://www.kieker-monitoring.net}} 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}} angeboten.

\begin{figure}
\centering
\includegraphics[width=0.96\textwidth]{images/kiekerComponentDiagram-woCloud-bw-w-record-newNames-withTraceAnalysis-colors}
\caption[Kieker Komponentendiagramm]{Kieker Komponentendiagramm \footnotemark}
\label{fig:KiekerComponentDiagram}
\end{figure}

Wie in Grafik \ref{fig:KiekerComponentDiagram} dargestellt besteht \gls{kieker} aus den zwei zentralen Komponenten Kieker.Monitoring und 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. Zum \gls{moni} stehen manuelle Methoden aber auch automatische Mechanismen zur Verfügung die, zum Beispiel mittels \emph{AspectJ}, die Programmstruktur analysieren und automatisch die benötigten Messpunkte erzeugen.

Die Analyse der erhaltenen Daten wird mittels 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 Sequenz Diagramme oder Abhängigkeitsbäume erzeugt werden um das Verhalten der Anwendung zu beschreiben.

Die Kieker.Monitoring Funktionen werden in dieser Arbeit nicht oder nur teilweise eingesetzt werden, da sie primär auf Java-Anwendungen ausgerichtet sind. Allerdings werden die Kieker.Analysis Funktionen benutzt werden um die weitere Analyse durchzuführen.
\footnotetext{Grafik entnommen aus \citep{Kieker1.6UserGuide}}

\section{Perl}
\label{sec:perl}
Die Programmiersprache Perl\footnote{\url{http://www.perl.org}} ist eine imperative, plattformunabhängige, interpretierte Programmiersprache. Die erste Version wurde 1987 vorgestellt und hat seine Wurzeln primär in C und awk. 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.

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. 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.

Eines der stärksten Features von Perl sind Reguläre Ausdrücke. Bereits in frühen Versionen wurden diese unterstützt und aufgrund der hohen Verbreitung von Perl wurden die Perl Syntax de facto Standard für Reguläre Ausdrücke. Auch aufgrund dieser Stärke bei der Verarbeitung von Regulären Ausdrücken und der guten Verbindung mit anderen Softwaresystemen wird Perl in vielen Websystemen eingesetzt. Die meisten Webserver bieten Schnittstellen um den Perl-Interpreter einzubinden und Perl-Anwendungen somit in die Webpräsenz einzubinden.

\section{ePrints / Kielprints}
\label{sec:eprints}
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/}} bereit.

An der Universität Kiel wird die Software Kielprints verwendet, was einen angepasste Version von \gls{eprints} ist. Betrieben wird diese Plattform von dem Kieler Datenmanagement Team am Geomar Helmholtz-Zentrum für Ozeanforschung Kiel. Das Deployment der Anwendung ist in der Abbildung \ref{fig:deploy} grob skizziert.
\begin{figure}
\centering
\includegraphics[width=0.6\textwidth]{images/deployment}
\caption{Deployment der Kielprints-Anwendung}
\label{fig:deploy}
\end{figure}

Für die Plattform wurden bereits einige Erweiterungen entwickelt und in die Plattform integriert. Mit der Öffnung der Plattform für alle Institute der Universität sind unerwartete Performanceprobleme aufgetreten. Diese sollen mit dieser Arbeit und den entwickelten Modulen aufgespürt werden. Diese Probleme treten einerseits für die Benutzer beim Datenabruf auf, wobei unerwünscht lange Antwortzeiten, besonders bei der Suche nach Autoren oder Forschungsbereichen, beobachtet werden können. Aber auch die Administration und Datenpflege leidet unter den Problemen, da die Oberflächen für das Eintragen oder Editieren von Publikationen teilweise Wartezeiten von über 10 Sekunden aufweisen. Diese Zeiten sind bei einer Datenbankgröße von etwa 14000 Publikationen und 1000 Autoren nicht angemessen und weisen auf Probleme in der Aufbereitung der Seiten hin.

\section{Zielsetzung}
\label{sec:ziele}
Folgende Punkte sollen in der Bachelorarbeit konkret umgesetzt werden:
\begin{itemize}
  \item Implementierung von \glspl{probe} und einem monitoring writer in Perl.
  \item Verwendung eines monitoring logs in Dateiform.
  \item Untersuchung des Einflusses der \glspl{probe} auf die Laufzeit von Anwendungen.
  \item Instrumentierung der Kielprints-Anwendung.
  \item Lokalisierung von Performanceproblemen in der Kielprints-Anwendung.
\end{itemize}


\chapter{Geplante Umsetzung}
Wie bereits in der Einleitung skizziert muss für die Umsetzung der Arbeit zunächst eine Möglichkeit des Monitorings der Perl-Anwendungen geschaffen werden (\ref{sec:PerlMoni}). Anschließend soll das Verhalten zunächst getestet werden (\ref{sec:testInstr}) und schließlich das Projekt Kielprints untersucht werden (\ref{sec:KielprintsInstr}).

\section{Monitoring-Probes in Perl}
\label{sec:PerlMoni}
\begin{figure}
\centering
\includegraphics[width=0.9\textwidth]{images/architektur2}
\caption{Entwurf der Systemarchitektur}
\label{fig:architecture}
\end{figure}
Das \gls{kieker} Framework unterstützt zur Zeit noch kein \gls{moni} von Perl-Anwendungen. Im Rahmen von früheren Abschlussarbeiten wurden bereits Verfahren zum \gls{moni} von zum Beispiel .NET- \citep{cau15486} oder COBOL-Anwendungen \citep{cau15489} realisiert. Aufbauend auf den bisherigen Entwicklungen soll in dieser Arbeit nun das \gls{moni} von Perl-Anwendungen ermöglicht werden. Hierzu soll ein Perl-Modul implementiert werden, welches die Aufgaben des Kieker.Monitoring übernimmt. Dieser Ansatz ist in Abbildung \ref{fig:architecture} dargestellt.

Dieses Modul muss zunächst Funktionen zur Anreicherung des Codes mit Probes bereitstellen. Diese Funktionen müssen das Verhalten der Anwendung protokollieren und an eine (zu implementierende) Funktion weiterreichen, welche die persistente Sicherung der Daten übernimmt. Hierbei ist abzuwägen, ob von diesem Perl-Modul direkt \emph{\glspl{record}} erzeugt werden sollen, die von Kieker.Analysis verarbeitet werden können, oder ob ein Ansatz gewählt werden soll, der zunächst eigene Records erstellt und anschließend mit einer neuen Kieker Komponente die Übersetzung in \gls{kieker} \emph{\glspl{record}} realisiert. Dieser zweistufige Ansatz wurde bereits für COBOL-Anwendungen realisiert, allerdings ist auch die Erzeugung fertiger Records in Perl möglich. Für die erste Implementierung soll aber der Ansatz mit einer zwischengelagerten Kieker-Ausführung gewählt werden.

Da in Perl auch recht mächtige Funktionen zur Anbindung anderer Programmiersprachen unterstützt werden könnte auch eine Integration der bestehenden \gls{kieker} Klassen in Betracht gezogen werden. Da aber hierbei eine Verbindung von vorcompiliertem Java-Code und interpretiertem Perl-Code realisiert werden muss, kann bei dieser Veriante das Laufzeitverhalten stärker als in dem oben skizzierten Ansatz beeinflusst werden.

\section{Instrumentierung und Monitoring einer Testanwendung}
\label{sec:testInstr}
Das fertige Perl-Modul wird anschließend auf eine isolierte Testanwendung angewendet. Hierbei wird es sich voraussichtlich um eine Kopie des ePrints-Systems handeln. In dieser Testanwendung kann dann die Instrumentierung durchgeführt werden und verschiedenen Testszenarien untersucht werden. Durch die Simulation von verschiedenen Anfragen kann neben dem Verhalten der Anwendung auch der Einfluss des Monitorings auf die Anwendung untersucht werden. Es sollte versucht werden, den zusätzlichen Aufwand der Anwendung möglichst gering zu halten um das tatsächliche Verhalten der Anwendung nicht zu stark zu verzerren.

Mit den erzeugten Daten soll die Anbindung an Kieker.Analysis getestet werden und eine geeignete Analysemethode für die späteren Tests festgelegt werden. Sobald diese Tests zufriedenstellend ausfallen kann dann die Instrumentierung von Kielprints im produktiven Betrieb durchgeführt werden.

\section{Instrumentierung von Kielprints}
\label{sec:KielprintsInstr}
In Zusammenarbeit mit dem Geomar Helmholtz-Zentrum für Ozeanforschung Kiel soll dann Kielprints instrumentiert werden. In dem momentanen Zustand der Anwendung sind langsame Reaktionszeiten aufgetreten, obwohl bisher mit knapp 14000 Publikationen die Auslastung der Datenbank noch in einem üblichen Rahmen liegt. Somit soll die Anwendung instrumentiert werden und Engpässe in der Anwendung identifiziert werden. Hierzu werden die Erkenntnisse der vorherigen Testläufe verwendet um Analysemethoden festzulegen und Vergleichswerte zu erhalten. Mit den erhaltenen Analysedaten soll dann versucht werden Optimierungspotential der Anwendung aufzuzeigen.
\chapter{Organisatorischer Rahmen}
\begin{itemize}
  \item Organisation
  \begin{description}
    \item[Dauer der Arbeit] 1. Oktober 2012 bis 31. März 2013
    \item[Bearbeiter] Nis Börge Wechselberg, Mat-Nr. 774996, nbw@informatik.uni-kiel.de
    \item[Berater] Dipl.-Inf. Peer Brauer, pcb@informatik.uni-kiel.de
  \end{description}
  \item Entwicklung
  \begin{description}
    \item[Hardware] Die Kielprints-Plattform wird im Geomar auf einer SunFire 4250 betreiben. Das Testsystem wird auf einem Blade des Lehrstuhls bereitgestellt.
    \item[System] Solaris 10
    \item[Software] ePrints 3.3 unter Perl 5.10
    \item[Entwicklungsumgebung] Für den Betreib von Kielprints werden PostgreSQL 8.3 sowie Apache 2.2.22 eingesetzt. Die Pakete wurden von OpenCSW.org angepasst.
  \end{description}
\end{itemize}


\chapter{Zeitplan}
In der folgenden Tabelle ist das geplante Vorgehen skizziert:
\begin{table}[tph]
\centering
\begin{tabular}{rlp{5.5cm}}
KW & Projektphase & Meilensteine \\
\hline
47 & Vorbereitung & Literaturrecherche \\
\hline
48 & Perl-Modul & Analyse der benötigten Funktionen, Festlegung des Datenformats \\
48 &  & Implementierung der Probes \\
49 &  & Implementierung der Probes \\
50 &  & Lokale Tests und Fehlerbehebung \\
\hline
51 & Konsolidierung & Schreiben der Arbeit \\
52 &  & Schreiben der Arbeit \\
\hline
1 &  Test-Instrumentierung & Einrichtung von Testanwendungen, Instrumentierung \\
2 &  & Feststellung von Monitoring-Overhead \\
\hline
3 & Konsolidierung & Schreiben der Arbeit \\
\hline
4 & Kielprints & Instrumentierung der Anwendung \\
5 &  & Ablauf des Monitorings zur Laufzeit \\
6 &  & Analyse der Traces \\
7 &  & Evtl. Langzeit \gls{moni} \\
8 &  &  \\
9 &  &  \\
\hline
10 & Konsolidierung & Schreiben der Arbeit \\
\hline
11 & Abschluss der Arbeit & Fertigstellung, Kolloqium \\
12 &  &  \\
13 &  &
\end{tabular}
\caption{Zeitplan}
\label{tab:zeitplan}
\end{table}

Dieser Verlauf ist auch aus dem folgenden Gantt-Diagramm (Abbildung \ref{fig:GanttChart}) ersichtlich.
\begin{figure}
\centering
\includegraphics[angle=90,scale=0.45]{images/ganttchart}
\caption{Gantt-Chart}
\label{fig:GanttChart}
\end{figure}

% Abschluss
\backmatter

  \printglossaries

  \tocbibliography

\end{document}