Daily CheckIn
This commit is contained in:
marcodn
parent
f028148892
commit
1bcc6e1c15
3 changed files with 155 additions and 6 deletions
|
|
@ -84,8 +84,8 @@ hostname="http://localhost:8080/WedekindJSF-1.0.0"
|
||||||
# the Array of the Urls
|
# the Array of the Urls
|
||||||
url_arr=(
|
url_arr=(
|
||||||
"$hostname/index.xhtml"
|
"$hostname/index.xhtml"
|
||||||
"$hostname/view/document/list.xhtml"
|
#"$hostname/view/document/list.xhtml"
|
||||||
#"$hostname/view/document/list_mv.xhtml"
|
"$hostname/view/document/listsearch.xhtml"
|
||||||
#"$hostname/view/correspondent/list.xhtml"
|
#"$hostname/view/correspondent/list.xhtml"
|
||||||
#"$hostname/view/person/list.xhtml"
|
#"$hostname/view/person/list.xhtml"
|
||||||
)
|
)
|
||||||
|
|
|
||||||
|
|
@ -304,13 +304,160 @@ in den Java-Objekten fast identisch sind. Und in der Datenbank sind die Anfragen
|
||||||
\subsection{materialized views}
|
\subsection{materialized views}
|
||||||
\label{sec:performance-checking:investigation-application: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}
|
\subsection{cached queries}
|
||||||
\label{sec:performance-checking:investigation-application:cached-query}
|
\label{sec:performance-checking:investigation-application:cached-query}
|
||||||
|
|
||||||
Über die Einstellung \textit{openjpa.jdbc.QuerySQLCache} wird der Cache aktiviert. Hierbei können Abfragen angeben
|
Über die Einstellung \textit{openjpa.jdbc.QuerySQLCache} wird der Cache für abfragen aktiviert. Hierbei können Abfragen
|
||||||
werden, die aus dem Cache ausgeschlossen werden. Der QueryCache wiederrum beachtet aber nur Abfragen die keine
|
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},
|
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
|
dass hier keine Veränderung der Aufrufzeiten stattgefunden hat. Gleich ob man mit \ac{JPQL} oder mit der Criteria API
|
||||||
abfragt.
|
abfragt.
|
||||||
|
|
@ -344,4 +491,6 @@ abfragt.
|
||||||
|
|
||||||
Wenn man die Dokumentenliste als statische Webseiten ablegt, werden die Zugriffszeiten sehr kurz sein. Darüber hinaus
|
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
|
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.
|
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.
|
||||||
BIN
thesis.pdf
BIN
thesis.pdf
Binary file not shown.
Loading…
Reference in a new issue