% !TeX root = ../../thesis.tex \chapter{Zusammenfassung und Ausblick} \label{ch:summary_and_outlook} \section{Zusammenfassung} \label{sec:Summary_and_outlook:results} % In der Gegenwart schreiben, außer bei verweisen auf die Arbeit, dann in der Vergangenheit! Die Untersuchungen am Beispiel des Wedekind"=Projektes zeigen, dass mehrere Optimierungsmöglichkeiten in den Briefeditionen existieren. Für die Untersuchung wurde sich auf die Dokumentenliste beschränkt und anhand dieser die Optimierung implementiert, untersucht und jeweils mit der Ausgangsmessung verglichen. Für die Messung wurden Skripte erstellt, welche auf dem gleichen Computer wie der Webserver und der Datenbankserver laufen, damit diese auch vergleichbar bleiben und externe Einflussfaktoren minimiert werden. Durch die Ausgangsmessungen war erkennbar, dass der größte Teil der Verarbeitungszeit im Bereitstellen der Entitäten liegt. Die Messung der Abfragen auf der Datenbank wiederum konnte die hohe Verarbeitungszeit nicht bestätigen, daher lag hier die Vermutung nahe, dass der Großteil der Zeit im \ac{ORM} verloren geht. Die Methode der Nutzerumfrage wurde nicht weiterverfolgt, da diese auf Grund von zu wenigen Bedienern nicht zielführend war. Bei der Untersuchung der Datenbank wurde festgestellt, dass die Struktur aktuell für die Anwendung optimal ist und daher eine Restrukturierung keine Vorteile entstehen lässt. Die statische Webseite und die komplett client basierte Webseite wurden auf Grund von technischen Einschränkungen nicht weiterverfolgt. Bei den Caches sind der Query"=Cache und der \ac{EJB}"=Cache nicht für die Optimierung verwendbar. Der Query"=Cache wird von OpenJPA nur verwendet, wenn die Abfrage keine Parameter besitzt, welche in der Dokumentliste verwendet werden müssen. Im \ac{EJB}"=Cache werden nicht die Objekt, sondern die Provider gespeichert, wodurch hier keine Auswirkung auf die Performance festgestellt werden konnte. Anders sieht es bei dem OpenJPA"=Cache aus, dieser hat direkten Einfluss auf die Performance der Ermittlung der Daten und Bereitstellung der dazugehörigen Java"=Objekte. Anhand der vorgegeben Cache"=Größe kann das Potential der Optimierung eingestellt werden. Dies bedeutet, soweit der Cache groß genug ist, um alle notwendigen Objekte zu speichern, sind die Verbesserungen gut sichtbar. Ab dem Zeitpunkt ab dem Objekte aus dem Cache entfernt werden müssen, wird die Optimierung immer geringer. Ein sehr ähnliches Verhalten konnte mit dem Ehcache festgestellt werden, nur dass bei diesem die Limitierungen höher angesetzt sind und die Verwaltung des Caches im Gesamtsystem effizienter aufgebaut ist, als bei OpenJPA. In beiden Fällen der Optimierung über die Nutzung eines Caches konnte durch die Messungen in der Software und der Abfragen an der Datenbank nachgewiesen werden, dass nicht das Ermitteln der Daten die größte Zeit einnimmt, sondern das Erstellen und Befüllen der Objekte in Java. Bei dem Vergleich der unterschiedlichen Abfragemethoden Criteria API und JPQL konnte kein Unterschied in der Performance und Abarbeitung festgestellt werden. Bei beiden Methoden konnte nachgewiesen werden, dass die syntaktisch gleichen Abfragen an die Datenbank gestellt wurden. Bei den Abfragen zur Dokumentenliste konnten in beiden Fällen durch die Umstellung der Ermittlung der unterlagerten Daten durch Hints eine Optimierung erreicht werden. Die Umstellung bezweckt, dass die unterlagerten Daten nicht einzeln für jede Zeile ermittelt werden, sondern alle Daten auf einmal geladen werden und die Zuordnung der Datensätze im OpenJPA"=Framework durchgeführt wird. Mit der Übernahme der \textit{Materialized View} aus dem Wedekind"=Projekt kann eine gute Optimierung beobachtet werden. Dies ist auf die einfachere Abfrage, die Reduzierung der Abfrage an den Datenbankserver und dass die Objekte im eigenen Code erstellt werden zurückzuführen und nicht auf das OpenJPA"=Framework. Hierbei konnte noch nachgewiesen werden, dass das Parsen der Json"=Daten, die die unterlagerten Objekte enthalten, den größten Teil der Zeit benötigen. Auf Grund dessen wurde das Parsen der Json"=Daten auf den Client verschoben, was zu einem noch besseren Ergebnis führte. Für die Optimierung der Abfragen wurde die Hauptabfrage betrachtet. Bei dieser konnte anhand der visuellen Darstellung das Problem gut identifiziert werden. Durch die Verwendung einer \textit{Common Table Expression} wurde die Anzahl der Datensätze direkt am Anfang auf die angefragte Menge reduziert, wodurch die Anzahl der zu betrachteten Datensätze für die weiteren Verlinkungen enorm reduziert wird. Somit konnte der Datenbankserver bei diesen Verlinkungen auf Indexe zurückgreifen und damit die Abfragen zusätzlich beschleunigen. Die Untersuchungen zeigen, dass mehrere Möglichkeiten zur Optimierung existierten, um die Zugriffe auf die Briefeditionen zu beschleunigen und dass das größte Optimierungspotential in dem \ac{ORM} liegt. Die Umstellung auf eine \textit{Materialized View} ist eine sinnvolle Wahl, wenn die Abfrage der Daten komplexer ausfällt oder aus mehreren n:m"=Beziehungen besteht. Bei der Verwendung eines Caches sollte darauf geachtet werden, dass die notwendigen Ressourcen am Server bereitgestellt werden können und es wird empfohlen auf den Ehcache umzustellen. \section{Ausblick} \label{sec:summary_and_outlook:outlook} Die Untersuchungen zeigen, dass die Schichten über OpenJPA weitestgehend optimal umgesetzt sind, beziehungsweise wenig Möglichkeiten für eine Optimierungen zulassen. Einzig das Parsen von Json ist in einem Webbrowser schneller als im Server durchführbar. Auf diese Weise könnten zusätzlich die Ressourcen am Server reduziert werden beziehungsweise mit gleichen Ressourcen mehr Anfragen als bisher beantwortet werden. Die größten Optimierungspotentiale können durch Umstellung der Abfragen und der Optimierung des \ac{ORM} umgesetzt werden. Bei den Umstellungen der Abfragen ist die größte Stärke, wenn die Anzahl der Abfragen drastisch reduziert werden könnte. Dadurch zeigt sich, dass die Untersuchung auf Ebene der \ac{ORM} noch nicht abgeschlossen ist. Weitere Untersuchungen von anderen \ac{ORM} könnten wie in \autoref{sec:evaluation:materialized-view} angedeutet das Speicherproblem lösen, sowie eine generelle Optimierung der Webseite zur Folge haben. Eine eigenständige Implementierung eines einfachen \ac{ORM} wäre ebenfalls in Betracht zu ziehen, solange sich die Komplexität der Daten"=Struktur nicht erhöht.