diff --git a/chapters/thesis/appendix02_timing.sh b/chapters/thesis/appendix02_timing.sh index a5af4c7..5ff06d3 100644 --- a/chapters/thesis/appendix02_timing.sh +++ b/chapters/thesis/appendix02_timing.sh @@ -84,8 +84,8 @@ hostname="http://localhost:8080/WedekindJSF-1.0.0" # the Array of the Urls url_arr=( "$hostname/index.xhtml" - "$hostname/view/document/list.xhtml" - #"$hostname/view/document/list_mv.xhtml" + #"$hostname/view/document/list.xhtml" + "$hostname/view/document/listsearch.xhtml" #"$hostname/view/correspondent/list.xhtml" #"$hostname/view/person/list.xhtml" ) diff --git a/chapters/thesis/chapter04.tex b/chapters/thesis/chapter04.tex index 54637e0..eea8860 100644 --- a/chapters/thesis/chapter04.tex +++ b/chapters/thesis/chapter04.tex @@ -304,13 +304,160 @@ in den Java-Objekten fast identisch sind. Und in der Datenbank sind die Anfragen \subsection{materialized views} \label{sec:performance-checking:investigation-application:materialized-views} -\mytodos{Sourcecode erfragen bei Herrn Holstein!} +Materialized Views sind Sichten in der Datenbank, die beim erstellen der Sicht den aktuellen Zustand ermitteln und +Zwischenspeichern. Somit wird beim Zugriff auf diese Sichten, nicht die hinterlegte Abfrage ausgeführt, sondern auf +die gespeicherten Daten zugegriffen. Dies ist gerade bei vielen Joins von Vorteil. Zusätzlich können auf solchen +Sichten auch Indexe erstellt werden, um noch effektiver die Abfragen bearbeiten zu können. + +Der größte Nachteil dieser Sichten ist, dass sie zyklisch oder bei Datenänderungen aktualisiert werden müssen, sonst +läuft der Datenbestand der Sicht und der zugrundeliegenden Abfrage auseinander. + +In diesem Test, wurde zusätzlich zur normalen Abfragen noch die nachfolgenden einzelabfragen als Sub-Selects +hinzugefügt, wie in \ref{lst:sql-materialized-view} zu sehen. Somit können die nachfolgenden einzelnen Abfragen +eingespart werden. Dies wiederrum geht aber auf die Performance der Erstellung der Sicht und ihrer Aktualisierung. + +\begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view] +CREATE MATERIALIZED VIEW searchdocument AS +SELECT + d.id, d.documentId, d.datetype, d.startdatestatus, d.startyear, + d.startmonth, d.startday, d.enddatestatus, d.endyear, d.endmonth, + d.endday, + ( + SELECT + jsonb_build_object( + 'personId', hp.personid, + 'surname', hp.surname, + 'firstname', hp.firstname, + 'dateBirth', json_build_object( + 'year', hp.birthstartyear, + 'month', hp.birthstartmonth, + 'day', hp.birthstartday + ), + 'dateDeath', json_build_object( + 'year', hp.deathstartyear, + 'month', hp.deathstartmonth, + 'day', hp.deathstartday + ) + ) + FROM historicalperson hp + WHERE hp.id = d.authorperson_id + AND hp.validuntil > NOW() + ) as author, + ( + SELECT + jsonb_agg(jsonb_build_object( + 'personId', hcap.personid, + 'surname', hcap.surname, + 'firstname', hcap.firstname, + 'dateBirth', json_build_object( + 'year', hcap.birthstartyear, + 'month', hcap.birthstartmonth, + 'day', hcap.birthstartday + ), + 'dateDeath', json_build_object( + 'year', hcap.deathstartyear, + 'month', hcap.deathstartmonth, + 'day', hcap.deathstartday + ) + )) + FROM documentcoauthorperson dcap + JOIN historicalperson hcap + ON hcap.id = dcap.authorperson_id + AND dcap.validuntil > NOW() + AND hcap.validuntil > NOW() + WHERE dcap.document_id = d.id + ) AS coauthors, + ( + SELECT + jsonb_agg(jsonb_build_object( + 'personId', hap.personid, + 'surname', hap.surname, + 'firstname', hap.firstname, + 'dateBirth', json_build_object( + 'year', hap.birthstartyear, + 'month', hap.birthstartmonth, + 'day', hap.birthstartday + ), + 'dateDeath', json_build_object( + 'year', hap.deathstartyear, + 'month', hap.deathstartmonth, + 'day', hap.deathstartday + ) + )) + FROM documentaddresseeperson dap + JOIN historicalperson hap + ON hap.id = dap.addresseeperson_id + AND dap.validuntil > NOW() + AND hap.validuntil > NOW() + WHERE dap.document_id = d.id + ) AS addressees, + sc.city, d.documentcategory, d.ispublishedindb, d.createdat, + d.modifiedat, d.validuntil +FROM document d +LEFT JOIN sitecity sc ON sc.id = d.city_id; +\end{lstlisting} + +\begin{table}[h!] + \centering + \begin{tabular}{|r|r|r|r|r|r|r|r|} + \hline + & \multicolumn{3}{|c|}{Aufrufzeit} & & \multicolumn{3}{|c|}{RSS} \\ + \hline + \# & min & avg & max & Queries & davor & danach & diff \\ + \hline + 1 & 364 & 472 & 1225 & 306 & 821.03 & 890.15 & xxx.xx \\ + 2 & 345 & 361 & 290 & 100 & 839.89 & 852.26 & xxx.xx \\ + 3 & xxx & xxx & xxx & xxxxx & xxxx.xx & xxxx.xx & xxx.xx \\ + 4 & xxx & xxx & xxx & xxxxx & xxxx.xx & xxxx.xx & xxx.xx \\ + \hline + \end{tabular} + \caption{Messung mit Materialized View} + \label{tbl:measure-materialized-view} +\end{table} + +Wie in Tabelle \ref{tbl:measure-materialized-view} zu sehen, bringt die Verwendung der Materialized View ein Verbesserung +in verschiedenen Punkten. Zum einen ist eine Verbesserung der Aufrufzeiten zu erkennen, zusätzlich fällt der +Speicheranstieg weniger stark aus. + +Nach dem der Quellcode nochmal untersucht wurde, konnte man festellen, dass bei jeder Anfrage die gleiche Bedingung +benötigt wurde. Da die Sicht nun explizit für dies Anfrage geschaffen wurde, wurde die Bedingungen nun direkt in Sicht +mit integriert. Dies bedeutet eine Erweiterung der Sicht aus \ref{lst:sql-materialized-view} um +\ref{lst:sql-materialized-view-ext} und das entfernen der Parameter aus dem SQL-Anfragen im Java-Code. + +\begin{lstlisting}[language=SQL,caption={SQL Materialized View Erweiterung},label=lst:sql-materialized-view-ext] +WHERE d.validuntil > NOW() +AND d.ispublishedindb = true; +\end{lstlisting} + +\mytodos{Die Indizies noch mit aufnehmen!} + +Nach dem Anpassungen haben sich dann die Werte aus \ref{tbl:measure-materialized-view-ext} ergeben. + +\begin{table}[h!] + \centering + \begin{tabular}{|r|r|r|r|r|r|r|r|} + \hline + & \multicolumn{3}{|c|}{Aufrufzeit} & & \multicolumn{3}{|c|}{RSS} \\ + \hline + \# & min & avg & max & Queries & davor & danach & diff \\ + \hline + 1 & 348 & 419 & 869 & 178 & 792.11 & 846.29 & 54.18 \\ + 2 & 340 & 347 & 367 & 90 & 810.77 & 832.57 & 21.80 \\ + 3 & 296 & 353 & 491 & 90 & 840.39 & 867.92 & 27.53 \\ + 4 & 294 & 315 & 392 & 90 & 876.19 & 885.31 & 9.12 \\ + \hline + \end{tabular} + \caption{Messung mit erweiterter Materialized View} + \label{tbl:measure-materialized-view-ext} +\end{table} + + \subsection{cached queries} \label{sec:performance-checking:investigation-application:cached-query} -Über die Einstellung \textit{openjpa.jdbc.QuerySQLCache} wird der Cache aktiviert. Hierbei können Abfragen angeben -werden, die aus dem Cache ausgeschlossen werden. Der QueryCache wiederrum beachtet aber nur Abfragen die keine +Über die Einstellung \textit{openjpa.jdbc.QuerySQLCache} wird der Cache für abfragen aktiviert. Hierbei können Abfragen +angeben werden, die aus dem Cache ausgeschlossen werden. Der QueryCache wiederrum beachtet aber nur Abfragen die keine Parameter verwenden. Das sieht man auch entsprechend der Auswertung der Aufrufe \ref{tbl:measure-cached-queries}, dass hier keine Veränderung der Aufrufzeiten stattgefunden hat. Gleich ob man mit \ac{JPQL} oder mit der Criteria API abfragt. @@ -344,4 +491,6 @@ abfragt. Wenn man die Dokumentenliste als statische Webseiten ablegt, werden die Zugriffszeiten sehr kurz sein. Darüber hinaus funktionieren in statische Webseiten aber keine Suche oder eine Sortierung. Sonst müsste man für jede mögliche -Sortierung und Suchanfrage einen Satz der Dokumentenliste als statische Webseite bereitstellen. \ No newline at end of file +Sortierung und Suchanfrage einen Satz der Dokumentenliste als statische Webseite bereitstellen. Für die Sortierungen +wäre das noch möglich, aber für die Suchanfragen ist dies nicht mehr möglich. Daher ist die Umstellung auf statische +Webseiten nicht sinnvoll. \ No newline at end of file diff --git a/thesis.pdf b/thesis.pdf index 5e84714..91d1451 100644 Binary files a/thesis.pdf and b/thesis.pdf differ