Daily CheckIn

This commit is contained in:
marcodn 2024-08-08 22:19:43 +02:00
parent f028148892
commit 1bcc6e1c15
3 changed files with 155 additions and 6 deletions

View file

@ -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"
) )

View file

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

Binary file not shown.