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