bachelor-thesis/chapters/thesis/chapter05.tex

878 lines
55 KiB
TeX
Raw Normal View History

2024-07-31 22:12:53 +02:00
% !TeX root = ../../thesis.tex
2024-08-19 21:00:19 +02:00
\chapter{Performance-Untersuchung der Anwendung}
\label{ch:performance-investigation-application}
2024-09-26 23:43:15 +02:00
Nun werden die unterschiedlichen Schichten betrachtet und mögliche Performance"=Verbesserungen untersucht und deren
2024-08-19 21:00:19 +02:00
Vor"= und Nachteile herausgearbeitet.
2024-09-26 23:43:15 +02:00
Für die Tests wird ein aktuelles Manjaro"=System mit frisch installierten Payara als Serverhost und der IntelliJ IDEA
2024-08-19 21:00:19 +02:00
als Entwicklungsumgebung verwendet. Der Computer ist mit einer Intel CPU i7-12700K, 32 GB Arbeitsspeicher und einer SSD
als Systemfestplatte ausgestattet.
2024-09-28 13:33:24 +02:00
Zur ersten Untersuchung und der Bestimmung der Basis-Linie wurde das Script ohne eine Änderung am Code und der
2024-09-10 00:46:35 +02:00
Konfiguration mehrfach aufgerufen. Hierbei hat sich gezeigt, dass der erste Aufruf nach dem Deployment circa 1500 ms
gedauert hat. Die weiteren Aufrufe benötigen im Durchschnitt noch 600 ms. Beim achten Aufruf des Scripts hat der
2024-09-26 23:43:15 +02:00
Server nicht mehr reagiert und im Log ist ein \textit{OutOfMemoryError} protokolliert worden.
2024-09-28 21:50:12 +02:00
Nach einem Neustart des Servers konnte das gleiche Verhalten wieder reproduziert werden. Daraufhin ist eine Erweiterung
2024-09-29 11:02:28 +02:00
des Test"=Scripts notwendig, um die aktuelle Speichernutzung des Payara"=Servers darzustellen und auszuwerten. Diese
Auswertung zeigt, dass der Server mit circa 1500 MB RSS Nutzung an seine Grenzen stößt. Diese Grenze wird durch die
2024-08-19 21:00:19 +02:00
Konfigurationsänderung im Payara-Server von \texttt{-Xmx512m} auf \texttt{-Xmx4096m} nach oben verschoben. Nun werden
2024-09-26 23:43:15 +02:00
circa 60 Aufrufe des Scripts benötigt, damit der Server nicht mehr reagiert. Hierbei wird aber kein \textit{OutOfMemoryError}
2024-09-10 00:46:35 +02:00
in der Log-Datei protokolliert und der Server verwendet nun circa 4700 MB RSS. Bei allen Tests war noch mehr als die
2024-09-01 23:06:28 +02:00
Hälfte des verfügbaren Arbeitsspeichers des Computers ungenutzt.
2024-09-15 00:47:49 +02:00
Mit der Konfiguration \texttt{-Xmx} wird der maximal verwendbare Heap"=Speicher in der \ac{JVM} definiert.
2024-09-26 23:43:15 +02:00
Dies zeigt direkt, dass es ein Problem in der Freigabe der Objekte gibt, da dass Erhöhen des verwendbaren
2024-09-27 20:58:59 +02:00
Arbeitsspeicher das Problem nicht löst, sondern nur verlagert.
2024-09-15 00:47:49 +02:00
Für alle nachfolgenden Messungen wird das Skript im \autoref{ap:calling_script} verwendet, welches die einzelnen
2024-09-26 23:43:15 +02:00
Aufrufe steuert. Die Ergebnisse werden in eine Tabelle überführt, wie in \autoref{tbl:measure-without-cache}.
2024-09-15 00:47:49 +02:00
Hierbei werden die Aufrufzeiten der Webseite aus dem Skript für die Zeitmessung mit Mindest"~, Durchschnitt"~ und
2024-09-28 13:33:24 +02:00
Maximalzeit aufgenommen, hierbei ist eine kürzere Zeit besser. Zusätzlich wird die Anzahl der aufgerufenen \ac{SQL} Abfragen
2024-09-27 20:58:59 +02:00
ermittelt, auch hier gilt, je weniger Aufrufe desto besser. Als letztes wird noch der verwendete Arbeitsspeicher
2024-09-28 21:50:12 +02:00
vom \textit{Payara}"=Server vor und nach dem Aufruf ermittelt und die Differenz gebildet, hierbei sollte im idealen
2024-09-05 00:02:53 +02:00
Fall die Differenz bei 0 liegen. Dieser Aufbau gilt für alle weiteren Messungen. Zusätzlich werden noch die Laufzeiten
der \ac{JSF} ermittelt und die durchschnittlichen Zeiten mit in der Tabelle dargestellt, und auch hier ist es besser,
wenn die Zeiten kürzer sind.
2024-09-26 23:43:15 +02:00
Als Grundlage für die Vergleiche wurde eine Messung durchgeführt, bei welcher alle Caches deaktiviert wurden und keine
2024-09-15 00:47:49 +02:00
Änderung am Code vorgenommen wurde. Das Ergebnis dieser Messung ist in \autoref{tbl:measure-without-cache} zu finden.
2024-09-26 23:43:15 +02:00
Diese zeigen auch direkt ein zu erwartendes Ergebnis, dass der erste Aufruf bedeutend länger dauert als die Nachfolgenden.
2024-08-19 21:00:19 +02:00
Ebenfalls sieht man eindeutig, dass die Anzahl der Anfragen nach dem ersten Aufruf immer die gleiche Anzahl besitzen.
2024-09-28 13:33:24 +02:00
Der Speicherbedarf steigt relativ gleichmässig, was nicht recht ins Bild passt, da hier keine Objekte im Cache
2024-08-19 21:00:19 +02:00
gehalten werden sollten.
2024-09-28 16:16:31 +02:00
\begin{table}[H]
2024-08-19 21:00:19 +02:00
\centering
\begin{tabular}{|r|r|r|r|r|r|r|r|}
\hline
2024-09-15 00:47:49 +02:00
& \multicolumn{3}{c|}{Aufrufzeit (ms)} & & \multicolumn{3}{c|}{RSS (MB)} \\
2024-08-19 21:00:19 +02:00
\hline
\# & min & avg & max & Queries & davor & danach & diff \\
\hline
1 & 395 & 578 & 1312 & 12237 & 747.15 & 924.88 & 177.73 \\
2 & 353 & 375 & 464 & 12080 & 924.51 & 1027.75 & 103,24 \\
3 & 286 & 345 & 535 & 12080 & 1018.21 & 1145.36 & 127.15 \\
4 & 291 & 307 & 340 & 12080 & 1129.91 & 1239.75 & 109,84 \\
\hline
\end{tabular}
\caption{Messung ohne Caches}
\label{tbl:measure-without-cache}
\end{table}
2024-09-26 23:43:15 +02:00
Vor jedem weiteren Test"=Lauf wird die Domain beendet und komplett neugestartet, um mit einer frischen Instanz zu
2024-09-28 21:50:12 +02:00
beginnen. Hierbei ist aufgefallen, dass fast immer 62 Abfragen zur Startup-Phase dazugehören, unabhängig von den
2024-09-22 19:32:07 +02:00
konfigurierten Cache Einstellungen. Einige dieser Abfragen sind durch das Erstellen der \textit{Materialized View}
2024-09-15 00:47:49 +02:00
\textit{searchreference} und \textit{searchfulltext} erklärbar. Zusätzlich ist noch ein zyklischer Dienst
2024-09-10 00:46:35 +02:00
\textit{SearchEntityService} vorhanden, der zum Start und alle sechs Stunden den Datenbestand für die Suche aufbereitet
und entsprechend einige Abfragen an die Datenbank absetzt. Da weder die Sichten noch der Dienst für die Dokumentenliste
2024-09-29 11:02:28 +02:00
benötigt werden, werden der Dienst und das Erstellen im Code für die weiteren Tests deaktiviert.
2024-08-19 21:00:19 +02:00
2024-09-28 21:50:12 +02:00
Da die Abfragezeiten auf der Datenbank zu gering sind, um eine Verbesserung feststellen zu können, wird für den
2024-09-29 11:02:28 +02:00
PostgreSQL und den Payara"=Server ein Docker"=Container erzeugt und dieser limitiert. Die Konfiguration ist in
2024-09-15 00:47:49 +02:00
\autoref{ap:docker_config} beschrieben.
2024-08-19 21:00:19 +02:00
2024-09-27 20:58:59 +02:00
Mit dem neuen Aufbau ergibt sich eine neue Messung. Für den Speicherbedarf wird nun nicht mehr der benutzte
2024-09-01 23:06:28 +02:00
Speicher der Anwendung beobachtet, sondern die Speichernutzung des Docker-Containers für den Payara-Server. Auch hier
ist es besser, wenn es keine oder nur geringe Änderungen vor und nach dem Aufruf der Webseite gibt, ein steigender Wert
zeigt an, dass der verwendete Speicher nicht sauber freigegeben werden kann.
2024-09-28 21:50:12 +02:00
Für die Ausführungszeiten der \ac{SQL}"=Abfragen werden nur die sechs Abfragen für die Darstellung der Tabelle beachtet.
Hierzu zählt die Hauptabfrage der Dokumenten"=Tabelle, die Ermittlung des letzten und ersten Eintrags in der Tabelle,
2024-09-13 13:21:22 +02:00
die Ermittlung der Adressen des Autors, die Ermittlung der Koautoren, die Ermittlung der Faksimile, sowie die Ermittlung
2024-09-01 23:06:28 +02:00
der Anzahl aller vorhandenen Dokumente.
2024-08-19 21:00:19 +02:00
2024-09-27 20:58:59 +02:00
Zusätzlich wird die Zeit des Rendern der Sicht gemessen. Die erste Messung erfasst die komplette Laufzeit die fürs Rendern
2024-09-28 21:50:12 +02:00
notwendig ist. Die zweite Messung ermittelt die Zeit für das Laden der Daten aus der Datenbank und das Erstellen
2024-09-27 20:58:59 +02:00
der Java"=Objekte inklusive dem Befüllen mit den geladenen Daten.
2024-09-08 00:33:09 +02:00
2024-09-28 16:16:31 +02:00
\begin{table}[H]
2024-08-19 21:00:19 +02:00
\centering
2024-09-08 00:33:09 +02:00
\resizebox{\textwidth}{!}{
\begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|}
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
& \multicolumn{3}{c|}{Aufrufzeit (ms)} & \multicolumn{2}{c|}{Queries (ms)} & \multicolumn{3}{c|}{Memory (MB)} & \multicolumn{3}{c|}{Render (ms)} & \multicolumn{3}{c|}{DB-load (ms)} \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
1 & 451 & 682 & 1931 & 1223.0 & 30.3 & 931.3 & 986.1 & 54.8 & 440 & 666 & 1859 & 290 & 399 & 710 \\ % 12230 - 303 ms (135+ 79+ 39+ 22+17+11) (#2-6,8)
2 & 341 & 389 & 478 & 1208.0 & 31.2 & 986.5 & 1159.0 & 172.5 & 331 & 378 & 468 & 235 & 282 & 367 \\ % 24310 - 615 ms (270+156+ 78+ 56+34+21) (#2-7)
3 & 299 & 407 & 682 & 1208.0 & 33.5 & 1163.0 & 1273.0 & 110.0 & 290 & 398 & 672 & 207 & 307 & 579 \\ % 36390 - 950 ms (406+256+118+ 79+55+36) (#2-7)
4 & 278 & 359 & 424 & 1208.0 & 33.7 & 1272.0 & 1465.0 & 193.0 & 270 & 351 & 415 & 198 & 269 & 342 \\ % 48470 - 1287 ms (564+334+167+105+72+45) (#2-7)
5 & 264 & 317 & 356 & 1208.0 & 32.9 & 1467.0 & 1574.0 & 107.0 & 256 & 309 & 348 & 184 & 235 & 276 \\ % 60560 - 1616 ms (699+428+210+128+92+59) (#2-7)
2024-08-19 21:00:19 +02:00
\hline
\end{tabular}
2024-09-08 00:33:09 +02:00
}
2024-08-19 21:00:19 +02:00
\caption{Messung ohne Caches im Docker}
\label{tbl:measure-without-cache-docker}
\end{table}
\section{Caching im OpenJPA}
\label{sec:performance-investigation-application:caching-openjpa}
2024-09-26 23:43:15 +02:00
Die Cache"=Einstellung von OpenJPA werden über die zwei Einstellungen \texttt{openjpa.DataCache} und
2024-08-19 21:00:19 +02:00
\texttt{openjpa.QueryCache} konfiguriert. Bei beiden Einstellungen kann zuerst einmal über ein einfaches Flag
2024-09-28 13:33:24 +02:00
\textit{true} und \textit{false} entschieden werden, ob der Cache aktiv ist. Zusätzlich kann über das Schlüsselwort
2024-09-27 20:58:59 +02:00
\textit{CacheSize} die Anzahl der Elemente im Cache gesteuert werden. Wird diese Anzahl erreicht, werden zufällige
2024-09-26 23:43:15 +02:00
Objekte aus dem Cache entfernt und in eine SoftReferenceMap übertragen. Bei der Berechnung der Anzahl der Elemente werden
2024-09-01 23:06:28 +02:00
angeheftete Objekte nicht beachtet.
Die Anzahl der Soft References kann ebenfalls über eine Einstellung gesteuert werden. Hierfür wird die Anzahl der
Elemente über \textit{SoftReferenceSize} gesetzt, dessen Wert im Standard auf \textit{unbegrenzt} steht. Mit dem Wert
2024-09-28 13:33:24 +02:00
\textit{0} werden die Soft Referenzen komplett deaktiviert. Über die Attribute an den Entitätsklassen können diese
2024-09-01 23:06:28 +02:00
Referenzen ebenfalls gesteuert werden, hierzu muss eine Überwachungszeit angegeben werden. Diese Zeit gibt in ms an,
wie lange ein Objekt gültig bleibt. Mit dem Wert \textit{-1} wird das Objekt nie ungültig, was ebenfalls der
Standardwert ist.
2024-08-19 21:00:19 +02:00
2024-09-28 13:33:24 +02:00
Zuerst wird mit aktiviertem Cache mit einer Cache-Größe von 1000 Elemente getestet. Wie in
2024-09-15 00:47:49 +02:00
\autoref{tbl:measure-ojpa-active} zu sehen, dauert auch hier der erste Aufruf minimal länger als ohne aktiviertem
2024-09-28 13:33:24 +02:00
Cache. Alle nachfolgenden Aufrufe wiederrum sind um 100ms schneller in der Verarbeitung. Auch bei der Anzahl der
2024-09-15 00:47:49 +02:00
Anfragen an die Datenbank kann der Rückgang der Anfragen sehr gut gesehen werden. Aktuell kann die Verringerung des
wachsenden Speicherbedarfs nur nicht erklärt werden.
2024-08-19 21:00:19 +02:00
2024-09-28 16:16:31 +02:00
\begin{table}[H]
2024-08-19 21:00:19 +02:00
\centering
2024-09-08 00:33:09 +02:00
\resizebox{\textwidth}{!}{
\begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|}
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
& \multicolumn{3}{c|}{Aufrufzeit (ms)} & \multicolumn{2}{c|}{Queries (ms)} & \multicolumn{3}{c|}{Memory (MB)} & \multicolumn{3}{c|}{Render (ms)} & \multicolumn{3}{c|}{DB-load (ms)} \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
1 & 291 & 611 & 2347 & 730.2 & 28.8 & 852.7 & 891.9 & 39.2 & 282 & 595 & 2286 & 172 & 284 & 770 \\ % 7302 - 288 ms (145+ 42+ 40+ 24+18+ 8+ 7+ 4) (#2-8,12)
2 & 278 & 319 & 422 & 667.3 & 25.8 & 892.7 & 1010.0 & 117.3 & 266 & 309 & 411 & 173 & 195 & 220 \\ % 13975 - 546 ms (282+ 81+ 70+ 47+33+14+11+ 8) (#2-9)
3 & 229 & 281 & 329 & 680.6 & 27.6 & 1011.0 & 1067.0 & 56.0 & 220 & 271 & 313 & 134 & 180 & 222 \\ % 20781 - 822 ms (430+120+ 99+ 77+49+20+16+11) (#2-9)
4 & 222 & 280 & 321 & 671.3 & 27.6 & 1067.0 & 1122.0 & 55.0 & 213 & 271 & 310 & 131 & 189 & 238 \\ % 27494 - 1098 ms (569+160+137+ 99+68+26+22+17) (#2-9)
5 & 206 & 272 & 388 & 683.6 & 27.6 & 1122.0 & 1219.0 & 97.0 & 199 & 264 & 380 & 122 & 175 & 291 \\ % 34330 - 1374 ms (704+202+171+128+86+34+27+22) (#2-9)
2024-08-19 21:00:19 +02:00
\hline
\end{tabular}
2024-09-08 00:33:09 +02:00
}
2024-08-19 21:00:19 +02:00
\caption{Messung mit OpenJPA-Cache und Größe auf 1000}
\label{tbl:measure-ojpa-active}
\end{table}
2024-09-26 23:43:15 +02:00
Bei einer erhöhten Cache"=Größe, von 1000 auf 10000, zeigt sich auf den ersten Blick ein noch besseres Bild ab, wie in
2024-09-15 00:47:49 +02:00
\autoref{tbl:measure-ojpa-active-bigger} ersichtlich ist. Der erste Aufruf entspricht der Laufzeit mit geringerer
Cache"=Größe, aber schon die Anfragen an die Datenbank gehen drastisch zurück. Bei den weiteren Aufrufen werden im
2024-09-29 11:02:28 +02:00
Schnitt nun nur noch sechs Anfragen pro Seitenaufruf an die Datenbank gestellt, wodurch die Laufzeit im Schnitt nochmal
2024-09-28 21:50:12 +02:00
um 100 ms beschleunigt werden kann.
2024-08-19 21:00:19 +02:00
2024-09-28 16:16:31 +02:00
\begin{table}[H]
2024-08-19 21:00:19 +02:00
\centering
2024-09-08 00:33:09 +02:00
\resizebox{\textwidth}{!}{
\begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|}
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
& \multicolumn{3}{c|}{Aufrufzeit (ms)} & \multicolumn{2}{c|}{Queries (ms)} & \multicolumn{3}{c|}{Memory (MB)} & \multicolumn{3}{c|}{Render (ms)} & \multicolumn{3}{c|}{DB-load (ms)} \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
1 & 151 & 368 & 1904 & 141.2 & 20.8 & 906.3 & 936.8 & 30.5 & 164 & 404 & 2232 & 39 & 124 & 847 \\ % 1412 - 208 ms (133+ 40+ 23+9+2+1) (#2,4-6,10,12)
2 & 133 & 143 & 159 & 6.0 & 20.5 & 935.7 & 939.3 & 3.6 & 121 & 136 & 146 & 32 & 36 & 44 \\ % 1472 - 413 ms (274+ 80+ 47+9+2+1) (#2-3,5,6,10,12)
3 & 120 & 126 & 132 & 6.0 & 19.9 & 939.4 & 942.7 & 3.3 & 116 & 136 & 256 & 32 & 47 & 167 \\ % 1532 - 612 ms (412+119+ 69+9+2+1) (#2,3,5,6,10,12)
4 & 120 & 124 & 128 & 6.0 & 21.4 & 944.3 & 945.4 & 1.1 & 105 & 113 & 125 & 30 & 32 & 39 \\ % 1592 - 826 ms (550+168+ 96+9+2+1) (#2-4,6,10,12)
5 & 109 & 114 & 131 & 6.0 & 19.7 & 945.5 & 946.7 & 1.2 & 101 & 107 & 112 & 30 & 32 & 35 \\ % 1652 - 1023 ms (683+209+119+9+2+1) (#2-4,6,10,12)
2024-08-19 21:00:19 +02:00
\hline
\end{tabular}
2024-09-08 00:33:09 +02:00
}
2024-08-19 21:00:19 +02:00
\caption{Messung mit OpenJPA-Cache und Größe auf 10000}
\label{tbl:measure-ojpa-active-bigger}
\end{table}
2024-09-15 00:47:49 +02:00
Bei dem deaktivieren der \textit{SoftReference} und dem kleineren Cache zeigt sich keine große Differenz, somit scheint
die \textit{SoftReference} nicht das Problem für den steigenden Arbeitsspeicher zu sein, wie in
\autoref{tbl:measure-ojpa-active-bigger-no-softref} ersichtlich.
2024-09-08 00:33:09 +02:00
% document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile
2024-09-28 16:16:31 +02:00
\begin{table}[H]
2024-09-08 00:33:09 +02:00
\centering
\resizebox{\textwidth}{!}{
\begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|}
\hline
& \multicolumn{3}{c|}{Aufrufzeit (ms)} & \multicolumn{2}{c|}{Queries (ms)} & \multicolumn{3}{c|}{Memory (MB)} & \multicolumn{3}{c|}{Render (ms)} & \multicolumn{3}{c|}{DB-load (ms)} \\
\hline
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
\hline
1 & 339 & 659 & 2435 & 880.8 & 33.2 & 909.6 & 960.2 & 50.6 & 330 & 644 & 2375 & 218 & 343 & 815 \\ % 8808 - 332 ms (168+ 63+ 44+ 32+21+ 4) (#1,3-6,10)
2 & 267 & 332 & 388 & 832.1 & 28.1 & 959.7 & 1000.0 & 40.3 & 259 & 323 & 377 & 178 & 229 & 280 \\ % 17129 - 613 ms (313+111+ 82+ 48+42+17) (#1-3,5-6,8)
3 & 265 & 397 & 350 & 830.3 & 27.3 & 1001.0 & 1107.0 & 106.0 & 256 & 288 & 241 & 172 & 204 & 252 \\ % 25432 - 886 ms (455+156+125+ 64+63+23) (#1-3,5-6,8)
4 & 249 & 311 & 401 & 727.8 & 27.1 & 1108.0 & 1234.0 & 126.0 & 240 & 303 & 392 & 165 & 225 & 317 \\ % 32710 - 1157 ms (594+205+163+ 85+80+30) (#1-5,8)
5 & 268 & 296 & 325 & 931.9 & 28.0 & 1236.0 & 1239.0 & 3.0 & 260 & 288 & 318 & 192 & 217 & 244 \\ % 42029 - 1437 ms (738+254+204+106+97+38) (#1-5,8)
\hline
\end{tabular}
}
\caption{Messung mit OpenJPA-Cache und Größe auf 1000 und 0 SoftReference}
\label{tbl:measure-ojpa-active-bigger-no-softref}
\end{table}
2024-09-27 20:58:59 +02:00
Der Vergleich zeigt, dass der Cache eine gute Optimierung bringt, aber dies kann nur dann gut funktionieren, wenn immer
2024-09-10 00:46:35 +02:00
wieder die gleichen Objekte ermittelt werden. Sobald die Anfragen im Wechsel gerufen werden oder einfach nur die Menge
der Objekte den Cache übersteigt, fällt die Verbesserung geringer aus.
2024-08-19 21:00:19 +02:00
2024-09-21 15:05:19 +02:00
\section{Cached Queries}
2024-09-01 23:06:28 +02:00
\label{sec:performance-investigation-application:cached-query}
2024-09-26 23:43:15 +02:00
Über die Einstellung \textit{openjpa.""jdbc.""QuerySQLCache} wird der Cache für Abfragen aktiviert. Hierbei können
2024-09-28 13:33:24 +02:00
Abfragen angeben werden, die aus dem Cache ausgeschlossen werden. Der QueryCache wiederrum beachtet aber nur Abfragen,
2024-09-26 23:43:15 +02:00
die keine Parameter verwenden. Das sieht man auch entsprechend der Auswertung der Aufrufe in
\autoref{tbl:measure-cached-queries}, dass hier keine Veränderung der Aufrufzeiten stattgefunden hat, gleich ob
mit \ac{JPQL} oder Criteria API abfragt wird.
2024-09-01 23:06:28 +02:00
2024-09-08 00:33:09 +02:00
% document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile
2024-09-28 16:16:31 +02:00
\begin{table}[H]
2024-09-01 23:06:28 +02:00
\centering
2024-09-08 00:33:09 +02:00
\resizebox{\textwidth}{!}{
\begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|}
2024-09-01 23:06:28 +02:00
\hline
2024-09-08 00:33:09 +02:00
& \multicolumn{3}{c|}{Aufrufzeit (ms)} & \multicolumn{2}{c|}{Queries (ms)} & \multicolumn{3}{c|}{Memory (MB)} & \multicolumn{3}{c|}{Render (ms)} & \multicolumn{3}{c|}{DB-load (ms)} \\
2024-09-01 23:06:28 +02:00
\hline
2024-09-08 00:33:09 +02:00
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
2024-09-01 23:06:28 +02:00
\hline
2024-09-24 00:08:33 +02:00
1 & 409 & 771 & 2660 & 1222.4 & 32.8 & 850.4 & 982.8 & 132.4 & 366 & 633 & 2019 & 254 & 364 & 758 \\ % 12224 - 328 ms (140+ 90+ 43+ 22+20+13) (#1-6)
2 & 336 & 387 & 504 & 1208.0 & 31.2 & 982.9 & 1113.0 & 130.1 & 310 & 374 & 433 & 221 & 268 & 345 \\ % 24304 - 640 ms (280+174+ 80+ 41+39+26) (#1-6)
3 & 312 & 373 & 422 & 1208.0 & 31.1 & 1114.0 & 1221.0 & 107.0 & 295 & 401 & 658 & 216 & 320 & 570 \\ % 36384 - 951 ms (417+258+119+ 62+57+38) (#1-6)
4 & 288 & 363 & 471 & 1208.0 & 31.3 & 1239.0 & 1474.0 & 235.0 & 269 & 356 & 486 & 200 & 279 & 405 \\ % 48464 - 1264 ms (557+341+159+ 82+75+49) (#1-6)
5 & 325 & 398 & 535 & 1208.0 & 33.5 & 1474.0 & 1666.0 & 192.0 & 280 & 466 & 804 & 208 & 390 & 725 \\ % 60544 - 1599 ms (698+436+198+109+96+62) (#1-6)
2024-09-01 23:06:28 +02:00
\hline
\end{tabular}
2024-09-08 00:33:09 +02:00
}
2024-09-01 23:06:28 +02:00
\caption{Messung mit aktiviertem Cached Queries}
\label{tbl:measure-cached-queries}
\end{table}
2024-09-18 00:19:25 +02:00
\section{Caching mit Ehcache}
\label{sec:performance-investigation-application:caching-ehcache}
2024-09-28 13:33:24 +02:00
Der Ehcache ist ein L2"=Cache, den man direkt in OpenJPA mit integrieren kann. Hierfür sind einige Punkte zu beachten.
2024-09-27 20:58:59 +02:00
Zum einen muss die Referenz auf das \textit{ehcache} und das \textit{ehcache"=openjpa} Paket hinzugefügt werden.
2024-09-20 16:51:59 +02:00
Zusätzlich dazu sind die Konfiguration \textit{openjpa.""QueryCache}, \textit{openjpa.""DataCache} und
2024-09-26 23:43:15 +02:00
\textit{openjpa.""DataCacheManager} auf \textit{ehcache} anzupassen. Anhand der Annotation \texttt{@DataCache} kann
2024-09-20 16:51:59 +02:00
an jeder Klasse die Benennung des Caches sowie die Verwendung selbst gesteuert werden. Es wird für jede Klasse ein
eigener Cache angelegt und der Name auf den vollen Klassennamen gesetzt. Die Verwendung ist für alle Klassen
2024-09-27 20:58:59 +02:00
aktiviert und muss explizit deaktiviert werden, wenn dies nicht gewünscht ist. Als letztes muss noch der
2024-09-18 00:19:25 +02:00
Cache"=Manager aktiviert werden, dieser kann entweder durch Code programmiert werden oder über eine Konfiguration
in der \textit{ehcache.xml}.
2024-09-28 21:50:12 +02:00
Anhand der Auswertung von \autoref{tbl:measure-ehcache-active} sieht man, dass der Ehcache eine starke Performance
2024-09-26 23:43:15 +02:00
Verbesserung aufbringt. Über die Performance"=Statistik"=Webseite kann beobachtet werden, dass bei gleichen Aufrufen
2024-09-20 16:51:59 +02:00
der Webseite nur die Treffer in Cache steigen, aber die Misses nicht. Ebenfalls erhöht sich die Anzahl der Objekte
2024-09-26 23:43:15 +02:00
im Cache nicht. Zusätzlich steigt in diesem Fall der Speicherverbrauch nur gering bis gar nicht. Des Weiteren zeigt sich,
2024-09-27 20:58:59 +02:00
dass die Abfragezeiten in der Datenbank nur gering verkürzt wurden, aber die Laufzeit der Webseite sich stark
2024-09-24 00:08:33 +02:00
verbessert hat. Dies lässt auch hier den Schluss zu, dass die Erstellung der Objekte im OpenJPA die meiste Zeit
benötigt.
2024-08-19 21:00:19 +02:00
2024-09-18 00:19:25 +02:00
% document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile
2024-09-28 16:16:31 +02:00
\begin{table}[H]
2024-09-18 00:19:25 +02:00
\centering
\resizebox{\textwidth}{!}{
\begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|}
\hline
& \multicolumn{3}{c|}{Aufrufzeit (ms)} & \multicolumn{2}{c|}{Queries (ms)} & \multicolumn{3}{c|}{Memory (MB)} & \multicolumn{3}{c|}{Render (ms)} & \multicolumn{3}{c|}{DB-load (ms)} \\
\hline
2024-09-20 16:51:59 +02:00
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
2024-09-18 00:19:25 +02:00
\hline
%- & 151 & 368 & 1904 & 141.2 & 20.8 & 906.3 & 936.8 & 30.5 & 164 & 404 & 2232 & 39 & 124 & 847 \\ % 1412 - 208 ms (133+ 40+ 23+9+2+1) (#2,4-6,10,12)
2024-09-24 00:08:33 +02:00
1 & 156 & 488 & 2820 & 135.2 & 20.7 & 981.6 & 1006.0 & 24.4 & 147 & 490 & 2809 & 39 & 175 & 1186 \\ % 1352 - 207 ms (136+ 35+ 19+12+3+2) (#1-4,7-8)
2 & 135 & 144 & 166 & 6.0 & 20.1 & 1006.0 & 1007.0 & 1.0 & 124 & 136 & 157 & 33 & 38 & 47 \\ % 1412 - 408 ms (272+ 77+ 42+12+3+2) (#1-4,7-8)
3 & 121 & 129 & 136 & 6.0 & 19.4 & 1008.0 & 1009.0 & 1.0 & 113 & 121 & 126 & 32 & 34 & 33 \\ % 1472 - 602 ms (407+115+ 63+12+3+2) (#1-4,7-8)
4 & 116 & 123 & 133 & 6.0 & 19.7 & 1008.0 & 1016.0 & 8.0 & 108 & 116 & 125 & 31 & 33 & 34 \\ % 1532 - 799 ms (542+155+ 85+12+3+2) (#1-4,7-8)
5 & 111 & 118 & 127 & 6.0 & 12.7 & 1016.0 & 1012.0 & -4.0 & 104 & 111 & 119 & 32 & 34 & 38 \\ % 1592 - 926 ms (608+194+107+12+3+2) (#1-4,7-8)
2024-09-18 00:19:25 +02:00
\hline
\end{tabular}
}
\caption{Messung mit aktiviertem Ehcache}
\label{tbl:measure-ehcache-active}
\end{table}
2024-08-19 21:00:19 +02:00
2024-09-12 23:02:22 +02:00
\section{Caching in EJB}
2024-08-19 21:00:19 +02:00
\label{sec:performance-investigation-application:caching-ejb}
2024-09-26 23:43:15 +02:00
Die Cache"=Einstellungen des \ac{EJB} sind in der Admin-Oberfläche des Payara-Servers zu erreichen. Unter dem Punkt
2024-09-29 11:02:28 +02:00
Configurations $\Rightarrow$ server"=config $\Rightarrow$ \ac{EJB} Container werden zum einen die minimalen und maximalen
Größen des Pools definiert. Zum anderen werden an dieser Stelle die maximale Größe des Caches und die Größe der
2024-09-20 01:21:04 +02:00
Erweiterung definiert.
2024-09-15 00:47:49 +02:00
2024-09-20 01:21:04 +02:00
Anhand der Auswertung der \autoref{tbl:measure-ejb-cache-active} ist ersichtlich, dass der \ac{EJB}"=Cache keine
2024-09-26 23:43:15 +02:00
Auswirkung auf die Performance hat. Ebenso ist es ersichtlich, dass die Anzahl der Datenbankabfragen nicht reduziert
2024-09-28 21:50:12 +02:00
werden. Dies ist dadurch zu erklären, dass im \ac{EJB} die Provider gelagert sind, die über Dependency Injection
dem Controller bereitgestellt werden. Die Objekte selbst sind nicht im \ac{EJB}"=Cache hinterlegt.
2024-09-20 01:21:04 +02:00
2024-09-24 00:08:33 +02:00
% document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile
2024-09-28 16:16:31 +02:00
\begin{table}[H]
2024-08-19 21:00:19 +02:00
\centering
2024-09-08 00:33:09 +02:00
\resizebox{\textwidth}{!}{
\begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|}
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
& \multicolumn{3}{c|}{Aufrufzeit (ms)} & \multicolumn{2}{c|}{Queries (ms)} & \multicolumn{3}{c|}{Memory (MB)} & \multicolumn{3}{c|}{Render (ms)} & \multicolumn{3}{c|}{DB-load (ms)} \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-24 00:08:33 +02:00
1 & 364 & 741 & 2962 & 1222.1 & 29.4 & 880.6 & 991.7 & 111.1 & 353 & 725 & 2902 & 248 & 366 & 689 \\ % 12221 - 294 ms (135+ 73+ 41+ 20+16+ 9) (#1,2,4-7)
2 & 318 & 378 & 460 & 1208.0 & 31.0 & 992.4 & 1099.0 & 106.6 & 310 & 370 & 451 & 225 & 275 & 362 \\ % 24301 - 604 ms (274+154+ 80+ 42+34+20) (#1-3,5-7)
3 & 314 & 397 & 528 & 1208.0 & 32.5 & 1109.0 & 1308.0 & 199.0 & 306 & 388 & 519 & 227 & 307 & 434 \\ % 36381 - 929 ms (411+245+122+ 63+54+34) (#1-3,5-7)
4 & 334 & 371 & 420 & 1208.0 & 32.7 & 1308.0 & 1528.0 & 220.0 & 326 & 363 & 412 & 246 & 289 & 333 \\ % 48461 - 1256 ms (557+333+163+ 84+73+46) (#1-5,7)
5 & 304 & 392 & 562 & 1208.0 & 33.3 & 1518.0 & 1662.0 & 144.0 & 297 & 385 & 555 & 229 & 311 & 478 \\ % 60541 - 1589 ms (697+431+202+104+95+60) (#1-5,7)
2024-08-19 21:00:19 +02:00
\hline
\end{tabular}
2024-09-08 00:33:09 +02:00
}
2024-09-26 23:43:15 +02:00
\caption{Messung mit EJB"=Cache}
2024-08-19 21:00:19 +02:00
\label{tbl:measure-ejb-cache-active}
\end{table}
2024-09-12 23:02:22 +02:00
\section{Abfragen JPQL}
2024-08-19 21:00:19 +02:00
\label{sec:performance-investigation-application:query-jpql}
2024-09-28 21:50:12 +02:00
Für die \ac{JPQL} wird ein \ac{SQL} ähnlicher Syntax verwendet, um die Abfragen an die Datenbank durchzuführen. Der
nachfolgende Code für die Dokumentenliste, welche in \ac{JPQL} geschrieben ist, ist aus dem DFG"=Projekt
\citep{DFGProje43:online} entnommen. Das \autoref{lst:jpql-document-list-jpql} zeigt den \ac{JPQL}"=Code welcher unter
dem Namen \textit{Document.""findAll} hinterlegt ist, um die Daten aus dem \textit{PostgreSQL}"=Server zu ermitteln.
Die enthaltenen Namen mit vorangestellten Doppelpunkt sind Übergabevariablen, um die Auswahl einzuschränken.
2024-08-19 21:00:19 +02:00
\begin{lstlisting}[language=Java,caption={JPQL Dokumentenliste},label=lst:jpql-document-list-jpql]
SELECT DISTINCT d FROM Document d
LEFT JOIN FETCH d.authorPerson
LEFT JOIN FETCH d.coauthorPersonSet
LEFT JOIN FETCH d.addresseePersonSet
WHERE d.validUntil > :now
AND d.isPublishedInDb = :published
ORDER BY d.documentId ASC
\end{lstlisting}
2024-09-28 21:50:12 +02:00
Der dazugehörige Code im Server ist in \autoref{lst:jpql-document-list} zu finden und zeigt wie die benannte Anfrage
2024-09-29 11:02:28 +02:00
aufgerufen und die ermittelten Daten übernimmt. Zusätzlich werden an dieser Stelle die Parameter versorgt, die Grenzwerte
2024-09-28 21:50:12 +02:00
der Paginierung und die Hints hinterlegt.
2024-08-19 21:00:19 +02:00
\begin{lstlisting}[language=Java,caption={Java JPQL Dokumentenliste},label=lst:jpql-document-list]
List<Document> myResultList = createNamedTypedQuery("Document.findAll")
.setParameter("now", _IncludeDeleted ? new Date(0) : Date.from(LocalDateTime.now().atZone(ZoneId.systemDefault()).toInstant()))
.setParameter("published", true)
.setFirstResult(_Start)
.setMaxResults(_Size)
.setHint("javax.persistence.query.fetchSize", _Size)
.getResultList();
// Uebergabe der Ergebnisliste
if(myResultList != null && !myResultList.isEmpty()) {
myResult.addAll(myResultList);
}
\end{lstlisting}
2024-09-29 11:02:28 +02:00
Da dieser Code direkt aus dem Projekt stammt, wird hierfür keine gesonderte Zeitmessung durchgeführt, da diese der
2024-09-15 00:47:49 +02:00
Messung aus \autoref{tbl:measure-without-cache} entspricht.
2024-09-26 23:43:15 +02:00
Für die Optimierung wurden noch zusätzlich die Hints \texttt{openjpa.""hint.""OptimizeResultCount},
\texttt{javax.""persistence.""query.""fetchSize} und \texttt{openjpa.""FetchPlan.""FetchBatchSize} gesetzt. Hierbei
2024-09-15 00:47:49 +02:00
konnten je nach gesetzten Wert, keine relevanten Unterschiede festgestellt werden. Hierbei wurde der Wert auf zwei
2024-09-27 20:58:59 +02:00
gesetzt, welcher viel zu gering ist. Als weiterer Test wurde der Wert auf die angefragte Größe und den
20"=fachen Wert dieser Größe gestellt.
2024-09-15 00:47:49 +02:00
2024-09-26 23:43:15 +02:00
Ebenso bringt der Hint \texttt{openjpa.""FetchPlan.""ReadLockMode} auch keinen Unterschied bei der Geschwindigkeit.
2024-09-27 20:58:59 +02:00
Dies ist dadurch erklärbar, dass im Standard bei einer reinen Selektion eine Lesesperre aktiv sein muss.
2024-09-26 23:43:15 +02:00
Bei \texttt{openjpa.""FetchPlan.""Isolation} wird gesteuert, auf welche Sperren beim Laden geachtet wird. Damit könnte
2024-09-28 13:33:24 +02:00
man lediglich Schreibsperren umgehen und würde damit die Anfrage nicht mehr blockieren lassen, jedoch führt es unweigerlich
2024-09-26 23:43:15 +02:00
zu sogenannten >>Dirty"=Reads<<, wodurch die Ausgabe verfälscht werden könnte. Daher ist diese Einstellung
2024-09-10 00:46:35 +02:00
mit Vorsicht zu verwenden.
2024-09-26 23:43:15 +02:00
Mit dem Hint \texttt{openjpa.""FetchPlan.""EagerFetchMode} wird definiert, wie zusammengehörige Objekte abgefragt werden.
2024-09-10 00:46:35 +02:00
Bei dem Wert \textit{none} werden nur die Basis"=Daten abgefragt und jedes weitere Objekt wird in einem eigenen
2024-09-28 13:33:24 +02:00
Statement abgefragt. Mit \textit{join} wird definiert, dass abhängige Objekte, die als >>to-one<<"=Relation
2024-09-10 00:46:35 +02:00
definiert sind, in der Abfrage über einen Join verknüpft und damit direkt mitgeladen werden. Bei reinen
2024-09-26 23:43:15 +02:00
>>to-one<<"=Relation funktioniert das Rekursiv und spart sich damit einige einzelne Abfragen.
Bei der Einstellung \textit{parallel} wird zwar für jede abhängige Objektdefinition eine Abfrage ausgeführt und
2024-09-27 20:58:59 +02:00
diese werden direkt auf die Hauptobjekte gefiltert und die Verknüpfung im OpenJPA"=Framework durchgeführt.
Somit muss in diesem Beispiel nicht für jedes Dokument eine einzelne Abfrage für die Koautoren durchgeführt werden,
2024-09-28 13:33:24 +02:00
es wird lediglich eine Abfrage für alle Dokumente, welche ermittelt wurden, abgesetzt. Technisch gesehen wird die gleiche
2024-09-26 23:43:15 +02:00
WHERE"=Abfrage nochmal durchgeführt und um die JOINS ergänzt, um die Daten der Unterobjekte zu ermitteln.
Mit dem Hint \texttt{openjpa.""FetchPlan.""SubclassFetchMode} ist die Konfiguration für Unterklassen definiert. Die
Möglichkeiten entsprechen der vom \texttt{openjpa.""FetchPlan.""EagerFetchMode}.
2024-09-10 00:46:35 +02:00
Beim Umstellen der 2 Hints auf \textit{parallel} wird die Bearbeitungszeit fast halbiert und Anzahl der Datenbankaufrufe
2024-09-28 13:33:24 +02:00
wurde fast geviertelt. Dies zeigt, dass die einzelnen Aufrufe je Dokument aufwendiger sind als eine komplette Abfrage
2024-09-10 00:46:35 +02:00
der abhängigen Daten und das zusammensetzen in der OpenJPA-Schicht.
2024-09-26 23:43:15 +02:00
Der letzte Hint \texttt{openjpa.""FetchPlan.""MaxFetchDepth} schränkt die rekursive Tiefe ein, für die abhängige
2024-09-28 21:50:12 +02:00
Objekte mitgeladen werden. Lediglich auf Grund fehlender Datenbestände wird die Abfrage beschleunigt und ist daher
in diesem Fall nicht zu verwenden.
2024-09-10 00:46:35 +02:00
2024-08-19 21:00:19 +02:00
\section{Abfragen Criteria API}
\label{sec:performance-investigation-application:query-criteria-api}
2024-09-29 11:02:28 +02:00
Für die Criteria API wird die Abfrage nicht in einem \ac{SQL}"=Dialekt geschrieben, hierbei werden über Attribute die
2024-08-19 21:00:19 +02:00
Verlinkung zur Datenbank durchgeführt. An der Klasse selbst wird der Tabellenname definiert und an den Attributen die
2024-09-28 13:33:24 +02:00
Spaltennamen. Um die Anfrage durchzuführen, muss nun nur noch die Datenklasse angegeben und mit den Parametern
2024-09-15 00:47:49 +02:00
versorgt werden, wie es in \autoref{lst:criteria-api} gezeigt wird.
2024-08-19 21:00:19 +02:00
\begin{lstlisting}[language=Java,caption={Criteria API Dokumentenliste},label=lst:criteria-api]
CriteriaBuilder cb = getEntityManager().getCriteriaBuilder();
CriteriaQuery<Document> cq = cb.createQuery(Document.class);
Root<Document> from = cq.from(Document.class);
ParameterExpression<Boolean> includedPara = cb.parameter(Boolean.class, "published");
ParameterExpression<Date> validPart = cb.parameter(Date.class, "now");
CriteriaQuery<Document> select = cq.select(from)
.where(cb.and(
cb.equal(from.get("isPublishedInDb"), includedPara),
cb.greaterThan(from.get("validUntil"), validPart)
));
TypedQuery<Document> typedQuery = getEntityManager().createQuery(select)
.setParameter("now", _IncludeDeleted ? new Date(0) : Date.from(LocalDateTime.now().atZone(ZoneId.systemDefault()).toInstant()))
.setParameter("published", true)
.setFirstResult(_Start)
.setMaxResults(_Size)
.setHint("javax.persistence.query.fetchSize", _Size);
List<Document> myResultList = typedQuery.getResultList();
// Uebergabe der Ergebnisliste
if (myResultList != null && !myResultList.isEmpty()) {
myResult.addAll(myResultList);
}
\end{lstlisting}
2024-09-15 00:47:49 +02:00
Wie in der Messung in \autoref{tbl:measure-criteria-api} zu sehen, unterscheiden sich die Abfragezeiten nur marginal
2024-09-27 20:58:59 +02:00
von denen mit \ac{JPQL}. Wenn man sich den Code im Debugger betrachtet, lässt sich erkennen, dass die zusammengesetzten
Abfragen in den Java-Objekten fast identisch sind. In der Datenbank sind die Anfragen identisch zu denen über JPQL.
2024-08-19 21:00:19 +02:00
2024-09-28 16:16:31 +02:00
\begin{table}[H]
2024-08-19 21:00:19 +02:00
\centering
2024-09-08 00:33:09 +02:00
\resizebox{\textwidth}{!}{
\begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|}
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
& \multicolumn{3}{c|}{Aufrufzeit (ms)} & \multicolumn{2}{c|}{Queries (ms)} & \multicolumn{3}{c|}{Memory (MB)} & \multicolumn{3}{c|}{Render (ms)} & \multicolumn{3}{c|}{DB-load (ms)} \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-24 00:08:33 +02:00
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-24 00:08:33 +02:00
1 & 429 & 704 & 2472 & 1224.4 & 27.0 & 848.5 & 928.2 & 79.7 & 419 & 687 & 2400 & 276 & 368 & 732 \\ % 12244 - 270 ms (120+ 66+ 41+ 20+12+11) (#1-6)
2 & 327 & 396 & 482 & 1208.0 & 30.1 & 929.3 & 1151.0 & 221.7 & 318 & 383 & 472 & 216 & 284 & 339 \\ % 24324 - 571 ms (257+138+ 82+ 44+26+24) (#1-6)
3 & 322 & 397 & 507 & 1208.0 & 28.6 & 1151.0 & 1304.0 & 153.0 & 312 & 389 & 498 & 232 & 308 & 420 \\ % 36404 - 857 ms (370+219+123+ 66+41+38) (#1-6)
4 & 306 & 351 & 416 & 1208.0 & 27.1 & 1303.0 & 1439.0 & 136.0 & 298 & 341 & 401 & 218 & 261 & 323 \\ % 48484 - 1128 ms (489+284+163+ 91+53+48) (#1-6)
5 & 288 & 357 & 448 & 1208.0 & 27.1 & 1440.0 & 1580.0 & 140.0 & 279 & 348 & 441 & 201 & 271 & 360 \\ % 60564 - 1399 ms (603+354+205+113+65+59) (#1-6)
2024-08-19 21:00:19 +02:00
\hline
\end{tabular}
2024-09-08 00:33:09 +02:00
}
2024-08-19 21:00:19 +02:00
\caption{Messung mit Criteria-API ohne Cache}
\label{tbl:measure-criteria-api}
\end{table}
2024-09-29 11:02:28 +02:00
Daher bringt die Criteria API keinen Performance"=Vorteil gegenüber der JPQL"=Implementierung. Somit können beide
2024-09-27 20:58:59 +02:00
Implementierungen ohne Bedenken gegeneinander ausgetauscht werden, und die verwendet werden, die für den Anwendungsfall
2024-09-01 23:06:28 +02:00
einfacher umzusetzen ist.
2024-08-19 21:00:19 +02:00
2024-09-27 20:58:59 +02:00
Bei den Hints ist es das Gleiche wie bei \ac{JPQL}. Auch hier haben die meisten Hints keinen merkbaren Einfluss. Die
2024-09-26 23:43:15 +02:00
Einstellung \texttt{openjpa.""FetchPlan.""EagerFetchMode} liefert auch hier Optimierungen, wenn der Wert auf
2024-09-10 00:46:35 +02:00
\textit{parallel} gestellt wird. Hier wird ebenfalls die Anzahl der Anfragen reduziert und damit auch die
Geschwindigkeit optimiert.
2024-09-15 00:47:49 +02:00
\section{Materialized Views}
2024-08-19 21:00:19 +02:00
\label{sec:performance-investigation-application:materialized-views}
2024-09-26 23:43:15 +02:00
\textit{Materialized Views} sind Sichten in der Datenbank, die beim Erstellen der Sicht den aktuellen Zustand ermitteln
2024-09-28 13:33:24 +02:00
und zwischenspeichern. Somit wird beim Zugriff auf diese Sichten nicht die hinterlegte Abfrage ausgeführt, sondern auf
2024-08-19 21:00:19 +02:00
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
2024-09-01 23:06:28 +02:00
läuft der Datenbestand der Sicht und der zugrundeliegenden Abfrage auseinander. Da die Hauptarbeiten auf der Webseite
2024-09-28 13:33:24 +02:00
die Abfrage der Daten ist und nicht das Editieren, kann dieser Nachteil bei entsprechender Optimierung ignoriert werden.
2024-08-19 21:00:19 +02:00
2024-09-22 19:32:07 +02:00
In diesem Test wurde die aktuelle Implementierung aus dem Wedekind"=Projekt der \textit{Materialized View} inklusive
der Trigger und der \textit{SearchDocument}"=Klasse übernommen \citep{Dokument53:online}. Wie in
2024-09-28 13:33:24 +02:00
\autoref{lst:sql-materialized-view} zu sehen, wurden zur Standard"=Abfrage die sonst zusätzlichen Abfragen als
direkte Sub"=Selects mit integriert. Der Datenbestand dieser Sub"=Selects wird im Json"=Format angegeben, damit bei
2024-09-22 19:32:07 +02:00
den Koautoren und den Adressen mehrere Datensätze in einer Zeile zurückgegeben werden können. Ohne diese Technik würde
sich die Anzahl der Dokumente vervielfachen.
2024-08-19 21:00:19 +02:00
\begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view]
CREATE MATERIALIZED VIEW searchdocument AS
SELECT
2024-09-15 00:47:49 +02:00
d.id, d.documentid, d.datetype, d.startdatestatus, d.startyear,
2024-08-19 21:00:19 +02:00
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}
2024-09-20 01:21:04 +02:00
Zusätzlich zur View, werden noch die Indexe aus \autoref{lst:sql-materialized-view-index} erstellt. Diese werden für
2024-09-21 15:05:19 +02:00
eine bessere Performance der Abfrage benötigt.
2024-09-10 23:33:57 +02:00
\begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view-index]
CREATE INDEX idx_searchdocument_documentid
ON searchdocument (documentid);
CREATE INDEX idx_searchdocument_author_surname_firstname
ON searchdocument ((author->>'surname'), (author->>'firstname'));
CREATE INDEX idx_searchdocument_startdate
ON searchdocument (startyear, startmonth, startday);
CREATE INDEX idx_searchdocument_addressees_first_entry
ON searchdocument
2024-09-12 23:02:22 +02:00
( ((addressees->0->>'surname')::text)
, ((addressees->0->>'firstname')::text));
2024-09-10 23:33:57 +02:00
CREATE INDEX idx_searchdocument_city
ON searchdocument (city);
CREATE INDEX idx_searchdocument_documentcategory
ON searchdocument (documentcategory);
\end{lstlisting}
2024-09-21 15:05:19 +02:00
Für die Datenermittlung wurden die notwendigen Teile aus dem Wedekind"=Projekt kopiert. Bei der Darstellung wurden die
2024-09-26 23:43:15 +02:00
vorhanden Elemente, welche die Liste der Dokumente anzeigt, kopiert und auf die \texttt{SearchDocument}"=Klasse angepasst.
2024-09-20 01:21:04 +02:00
2024-08-21 00:30:20 +02:00
% document, first/last, documentaddresseeperson, documentcoauthorperson, documentfacsimile und count
2024-08-21 23:44:10 +02:00
% document, count, first/last
2024-09-28 16:16:31 +02:00
\begin{table}[H]
2024-08-19 21:00:19 +02:00
\centering
2024-09-08 00:33:09 +02:00
\resizebox{\textwidth}{!}{
\begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|}
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
& \multicolumn{3}{c|}{Aufrufzeit (ms)} & \multicolumn{2}{c|}{Queries (ms)} & \multicolumn{3}{c|}{Memory (MB)} & \multicolumn{3}{c|}{Render (ms)} & \multicolumn{3}{c|}{DB-load (ms)} \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-24 00:08:33 +02:00
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-24 00:08:33 +02:00
1 & 232 & 424 & 1486 & 14.3 & 1.4 & 828.2 & 929.3 & 101.1 & 222 & 408 & 1404 & 138 & 208 & 393 \\ % 143 - 14 ms (13+1+0) (#1,3,6)
2 & 154 & 182 & 219 & 7.0 & 1.2 & 939.9 & 941.2 & 1.3 & 145 & 174 & 209 & 81 & 103 & 132 \\ % 213 - 26 ms (25+1+0) (#1,3,5)
3 & 139 & 147 & 163 & 7.0 & 1.3 & 941.1 & 949.2 & 8.1 & 131 & 140 & 156 & 76 & 80 & 88 \\ % 283 - 39 ms (38+1+0) (#1,4,5)
4 & 128 & 134 & 141 & 7.0 & 1.3 & 946.0 & 946.6 & 0.6 & 121 & 127 & 133 & 72 & 75 & 78 \\ % 353 - 52 ms (51+1+0) (#1,4,5)
5 & 123 & 129 & 134 & 7.0 & 1.5 & 946.7 & 947.8 & 1.1 & 116 & 122 & 127 & 65 & 68 & 72 \\ % 423 - 67 ms (66+1+0) (#1,4,5)
2024-08-19 21:00:19 +02:00
\hline
\end{tabular}
2024-09-08 00:33:09 +02:00
}
2024-08-19 21:00:19 +02:00
\caption{Messung mit Materialized View}
\label{tbl:measure-materialized-view}
\end{table}
2024-09-27 20:58:59 +02:00
Wie in \autoref{tbl:measure-materialized-view} zu sehen ist, bringt die Verwendung der \textit{Materialized View} eine
Verbesserung in verschiedenen Punkten. Zum einen ist eine Verbesserung der Aufrufzeiten zu erkennen, zum anderen fällt
2024-09-22 19:32:07 +02:00
der Speicheranstieg weniger stark aus. Die Verbesserung der Aufrufzeiten lässt sich zusätzlich erklären, dass hier nun
2024-09-28 21:50:12 +02:00
nur noch vier statt der sechs Abfragen an die Datenbank gestellt werden, da die Einzelabfragen für die Adressen der
2024-09-21 15:05:19 +02:00
Personen und der Koautoren komplett entfallen.
2024-08-19 21:00:19 +02:00
2024-09-28 21:50:12 +02:00
Nach einer weiteren Untersuchung des Quellcodes wird festgestellt, dass bei jeder Anfrage die gleichen Bedingungen
2024-09-28 13:33:24 +02:00
benötigt werden. Da die Sicht nun explizit für diese Anfrage geschaffen ist, werden die Bedingungen nun direkt in die
2024-09-20 01:21:04 +02:00
Sicht mit integriert. Dies bedeutet eine Erweiterung der Sicht aus \autoref{lst:sql-materialized-view} um
2024-09-28 13:33:24 +02:00
\autoref{lst:sql-materialized-view-ext} und das Entfernen der Parameter aus dem \ac{SQL}"=Anfragen im Java"=Code.
2024-08-19 21:00:19 +02:00
\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}
2024-09-29 11:02:28 +02:00
Nach den Anpassungen haben sich die Werte aus \autoref{tbl:measure-materialized-view-ext} ergeben. Diese Werte
2024-09-26 23:43:15 +02:00
zeigen nur minimale Unterschiede in den Zeiten, diese sind auf Messtoleranzen zurückzuführen.
2024-08-19 21:00:19 +02:00
2024-09-28 16:16:31 +02:00
\begin{table}[H]
2024-08-19 21:00:19 +02:00
\centering
2024-09-08 00:33:09 +02:00
\resizebox{\textwidth}{!}{
\begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|}
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
& \multicolumn{3}{c|}{Aufrufzeit (ms)} & \multicolumn{2}{c|}{Queries (ms)} & \multicolumn{3}{c|}{Memory (MB)} & \multicolumn{3}{c|}{Render (ms)} & \multicolumn{3}{c|}{DB-load (ms)} \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-08 00:33:09 +02:00
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
2024-08-19 21:00:19 +02:00
\hline
2024-09-24 00:08:33 +02:00
1 & 241 & 348 & 859 & 16.8 & 2.5 & 896.0 & 932.4 & 36.4 & 232 & 331 & 803 & 132 & 174 & 334 \\ % 168 - 25 ms (14+11+0) (#1,2,8)
2 & 164 & 194 & 225 & 9.0 & 2.4 & 933.3 & 935.9 & 2.6 & 154 & 185 & 215 & 79 & 99 & 117 \\ % 258 - 49 ms (30+18+1) (#1,2,8)
3 & 147 & 161 & 179 & 9.0 & 2.4 & 935.8 & 938.8 & 3.0 & 139 & 152 & 167 & 68 & 77 & 86 \\ % 348 - 73 ms (45+27+1) (#1,2,7)
4 & 135 & 145 & 183 & 9.0 & 2.4 & 939.4 & 936.0 & -3.4 & 127 & 137 & 174 & 70 & 73 & 75 \\ % 438 - 97 ms (61+35+1) (#1,2,7)
5 & 126 & 137 & 154 & 9.0 & 2.4 & 936.1 & 939.1 & 3.0 & 118 & 129 & 143 & 66 & 72 & 79 \\ % 528 - 121 ms (76+44+1) (#1,2,7)
2024-08-19 21:00:19 +02:00
\hline
\end{tabular}
2024-09-08 00:33:09 +02:00
}
2024-08-19 21:00:19 +02:00
\caption{Messung mit erweiterter Materialized View}
\label{tbl:measure-materialized-view-ext}
\end{table}
2024-09-26 23:43:15 +02:00
Da bei der \textit{Materialized View} das Laden der Daten und das Wandeln in die Java"=Objekte getrennt programmiert
2024-09-22 19:32:07 +02:00
wurde, können hier eigene Zeitmessungen für die zwei Schritte eingebaut werden. Hierfür wird die Zeit vor dem
2024-09-28 13:33:24 +02:00
\texttt{map}"=Aufruf und der \texttt{map}"=Aufruf gemessen. Für die erste Messung wurde vor der Datenbankabfrage ein
2024-09-27 20:58:59 +02:00
\texttt{SearchDocument} Objekt erzeugt und dieses in jedem \texttt{map}"=Aufruf zurückgegeben. Mit diesem Aufbau wurde
2024-09-28 13:33:24 +02:00
die Zeit ermittelt, um die Daten aus der Datenbank zu laden und dieses Ergebnis einmalig zu durchlaufen, ohne ein
2024-09-26 23:43:15 +02:00
Objekt zu erstellen. Hierbei lagen die Zeiten bei circa 1 ms für das reine Laden der Daten und 3 ms
für den Aufruf der \texttt{map}"=Funktion. Sobald innerhalb der \texttt{map}"=Funktion pro Eintrag ein Objekt
2024-09-27 20:58:59 +02:00
erzeugt wird, ohne die Konvertierung der ermittelten Daten in das Objekt, steigt die Laufzeit bereits auf 54 ms.
2024-09-26 23:43:15 +02:00
Wenn man nun noch die Konvertierung der Daten mit einbaut, erhöht sich die Laufzeit nochmals, auf nun 82 ms.
Alleine für das Erzeugen der Objekte und der Json"=Parse Aufrufe wird die meiste Zeit aufgewendet.
2024-09-27 20:58:59 +02:00
Bei der Verwendung des Hints \texttt{openjpa.""FetchPlan.""FetchBatchSize} kann sich die Abfrage enorm verschlechtern. Wenn
2024-09-11 19:34:36 +02:00
dieser Wert zu klein oder groß definiert ist, wird die Laufzeit verschlechtert. Bei einem zu großen Wert wird die
Laufzeit der Datenbankanfrage auf circa 20 ms verlängert. Wenn der Wert zu gering gewählt ist, dann wird zwar die
2024-09-26 23:43:15 +02:00
Laufzeit der Datenbankanfrage minimal verkürzt, aber die \texttt{map}"=Funktion wird dadurch verlängert.
2024-09-11 19:34:36 +02:00
2024-09-28 16:16:31 +02:00
Das Aktivieren der Cache"=Optionen wie in \autoref{sec:performance-investigation-application:caching-openjpa} oder in
2024-09-28 13:33:24 +02:00
\autoref{sec:performance-investigation-application:cached-query} dargestellt, haben keine Auswirkung auf die Performance.
Dies ist dadurch erklärbar, dass keine Objekte durch das OpenJPA"=Framework erstellt werden, sondern erst in der
2024-09-26 23:43:15 +02:00
\texttt{map}"=Funktion des eigenen Codes und daher wird der Cache nicht genutzt.
2024-09-22 00:51:24 +02:00
2024-09-26 23:43:15 +02:00
Wie schon ermittelt, benötigt das Erstellen der Objekte den Großteil der Zeit für die Datenermittlung. Auf Grund dessen
wurde die übernommene \texttt{SearchDocument}"=Klasse abermals genauer betrachtet. Beim Erstellen werden die
2024-09-22 00:51:24 +02:00
\textit{Json}"=Daten direkt in Java"=Objekte gewandelt. Im ersten Schritt wird die Parse"=Funktion entfernt und die
Seite nochmals aufgerufen. Durch diese Umstellung fällt die Laufzeit der Datenermittlung auf circa 4 ms ab. Nun muss
2024-09-26 23:43:15 +02:00
noch überprüft werden, welche Zeit nun der Client zum parsen der \textit{Json}"=Daten benötigt. Hierfür werden die
Daten in einem versteckten \texttt{span}"=Element hinterlegt, wie es im \autoref{lst:jsf-datatable-json} zu sehen ist.
2024-09-28 16:16:31 +02:00
Die hinterlegte \textit{\ac{CSS}}"=Klasse ist zum Auffinden der Elemente für den späteren Javascript. Das
2024-09-26 23:43:15 +02:00
\textit{ajax}"=Element im Beispiel ist notwendig, damit bei einem Seitenwechsel die gleiche Interpreter"=Funktion für
2024-09-28 13:33:24 +02:00
die \textit{Json}"=Daten aufgerufen wird, wie beim Laden der Webseite.
2024-09-10 23:33:57 +02:00
\begin{lstlisting}[language=xml,caption={DataTable mit Json},label=lst:jsf-datatable-json]
<p:ajax event="page" oncomplete="convertJsonData()"/>
<p:column id="author" headerText="#{lang.List_Docs_Author}" sortable="true" sortBy="#{myObj.surname}">
<h:outputText styleClass="json-convert" style="display: none;" value="#{myObj.authorJson}"/>
</p:column>
<p:column id="Addressee"
headerText="#{lang.List_Docs_Addressee}"
sortable="true"
sortBy="#{(myObj.addresseePersonSet!=null and myObj.addresseePersonSet.size() > 0)?myObj.addresseePersonSet[0].addresseePerson:''}">
<h:outputText styleClass="json-convert" style="display: none;" value="#{myObj.adresseeJson}" data="abc"/>
</p:column>
\end{lstlisting}
2024-09-28 13:33:24 +02:00
Die Interpreter"=Funktion, welche in JavaScript geschrieben ist, wird benötigt, um die übertragenen
2024-09-27 20:58:59 +02:00
\textit{Json}"=Daten in eine darstellbare Form zu bringen. Die Funktion aus dem \autoref{lst:jsf-datatable-json-convert}
2024-09-28 13:33:24 +02:00
ermittelt erst alle versteckten Elemente, deserialisiert den Inhalt und erstellt neue \textit{\ac{HTML}}"=Elemente mit dem
2024-09-26 23:43:15 +02:00
darzustellenden Inhalt. Zusätzlich wird noch eine Zeitmessung eingebaut, um die Laufzeit am Client für das Rendern
2024-09-21 15:05:19 +02:00
in der Konsole anzuzeigen. Die Funktion wird nun direkt nach dem die Webseite fertig geladen wurde aufgerufen.
2024-09-10 23:33:57 +02:00
\begin{lstlisting}[language=javascript,caption={Wandeln von Json nach Html},label=lst:jsf-datatable-json-convert]
function isEmpty(str) {
return (str === null) || (str === undefined) || (typeof str === "string" && str.length === 0);
}
function convertJsonData() {
let $jsonObj = $(".json-convert")
, start = new Date()
;
$.each($jsonObj, function() {
let json = this.innerHTML
, strEmpty = (json === null) || (typeof json === "string" && json.length === 0)
, jsonDat = strEmpty ? null : JSON.parse(json)
;
if(!strEmpty) {
let res = ""
, $that = $(this)
, $par = $that.parent()
;
$.each(jsonDat, function() {
let hasOnlyOne = isEmpty(this.surname) || isEmpty(this.firstname)
, pseudonymExists = !isEmpty(this.pseudonym)
, namePart = "<span>" + (hasOnlyOne ? this.surname + this.firstname : this.surname + ", " + this.firstname) + "</span><br/>"
, pseudoPart = pseudonymExists ? "<span class='w3-small w3-text-dark-gray'>" + this.pseudonym + "</span><br/>" : ""
;
res += namePart + pseudoPart;
});
$par.append(res);
}
});
let end = new Date()
, diff = (end - start)
;
console.log(Math.round(diff) + " ms");
}
$(document).ready(function() {
convertJsonData();
});
\end{lstlisting}
2024-09-26 23:43:15 +02:00
Da nun am Client der Code ausgeführt wird, nachdem die Daten übertragen wurden, kann nicht mehr alles über das Script
2024-09-10 23:33:57 +02:00
durchgeführt werden. Daher werden nun die Laufzeiten am Server und am Client zusammenaddiert. Im Schnitt benötigt der
2024-09-26 23:43:15 +02:00
Aufruf auf der Serverseite nun 70 ms und am Client sind es circa 13 ms. Die summierte Laufzeit von Client und Server
2024-09-27 20:58:59 +02:00
ist geringer als die reine Serverlösung und erzeugt gleichzeit weniger Last am Server.
2024-09-10 00:46:35 +02:00
2024-09-21 15:05:19 +02:00
\section{Optimierung der Abfrage}
\label{sec:performance-investigation-application:optimizing-query}
2024-09-26 23:43:15 +02:00
Für die Optimierung der Abfragen werden diese zuerst mit \texttt{EXPLAIN}, wie in \autoref{lst:explain-diagnostic}
2024-09-28 13:33:24 +02:00
dargestellt, untersucht. Für die einfachere Diagnose wird der erstellte Plan mit Hilfe von
2024-09-22 19:32:07 +02:00
\textit{Postgres Explain Visualizer 2} (\url{https://github.com/dalibo/pev2}) visualisiert.
2024-09-21 15:05:19 +02:00
\begin{lstlisting}[language=SQL,caption={Explain für Diagnose},label=lst:explain-diagnostic]
explain (analyze, verbose, buffers, summary, format json)
select <Spalten>
from
public.document t0
left outer join public.historicalperson t1 on t0.authorperson_id = t1.id
left outer join public.sitecity t5 on t0.city_id = t5.id
left outer join public.appuser t6 on t0.editor_id = t6.id
left outer join public.extendedbiography t2 on t1.extendedbiography_id = t2.id
left outer join public.sitecity t3 on t1.sitecity_birth_id = t3.id
left outer join public.sitecity t4 on t1.sitecity_death_id = t4.id
left outer join public.appuserrole t7 on t6.appuserrole_id = t7.id
where (t0.validuntil > NOW()
and t0.ispublishedindb = true)
order by startyear DESC, startmonth DESC, startday DESC
limit 400;
\end{lstlisting}
Die erstellte Visualisierung der Abfrage ist in \autoref{fig:explain-visualize} zu sehen. In der Visualisierung wurde
die Darstellung der Kosten gewählt, da ein Vergleich auf Basis der Zeit sehr schwierig ist und von äußeren Faktoren
2024-09-26 23:43:15 +02:00
abhängt, wie zum Beispiel dem Cache. Die Kosten sind stabiler und hängen in erster Linie von der Art des Datenbestandes ab.
2024-09-21 15:05:19 +02:00
2024-09-28 16:16:31 +02:00
\begin{figure}[H]
2024-09-21 15:05:19 +02:00
\includegraphics[width=\linewidth]{gfx/chapter05_ExplainVisualize.png}
\caption{Visualisierung EXPLAIN}
\label{fig:explain-visualize}
\end{figure}
In der Graphik ist zu sehen, dass zum einen die Hauptkosten im untersten Knoten \textit{Seq Scan} und einen der
2024-09-26 23:43:15 +02:00
obersten Knoten dem \textit{HashAggregate} liegen. Zusätzlich sieht man anhand der Stärke von den Verbindungslinien der
Knoten, dass die Menge der Datensätze enorm hoch ist und diese sich bis zum obersten Knoten durchziehen. Dies
2024-09-21 15:05:19 +02:00
bedeutet, dass die Einschränkung des Datenbestandes erst am Ende der Abfrage durchgeführt wird und diesbezüglich die
Dauer der Abfrage linear mit den Inhalt der \textit{document}"=Tabelle zusammenhängt. Des Weiteren wird für keine
2024-09-26 23:43:15 +02:00
Tabelle ein \textit{Index Scan} verwendet, sondern immer mit einem \textit{Seq Scan} gearbeitet, da durch das Ermitteln
2024-09-29 13:27:02 +02:00
des kompletten Datenbestandes der Optimizer entscheidet, dass der komplette Scan der Tabelle kostengünstiger ist als
2024-09-21 15:05:19 +02:00
die Verwendung eines der vorhandenen Indexe. Dies kann durch den Befehl \lstinline[language=SQL]|SET enable_seqscan = off|
2024-09-26 23:43:15 +02:00
sehr einfach verifiziert werden. Damit wird die Verwendung von \textit{Seq Scan} deaktiviert und es wird anschließend ein
2024-09-28 13:33:24 +02:00
\textit{Index Scan} verwendet. Wenn man nun beide Pläne vergleicht, sieht man die Erhöhung der Kosten bei der Verwendung
2024-09-21 15:05:19 +02:00
von \textit{Index Scan}.
Die beste Optimierung hierbei ist, die Menge der Datensätze so früh wie möglich einzuschränken. Da die Verwendung von
2024-09-28 21:50:12 +02:00
\texttt{order by} innerhalb eines Sub"=Selects nicht erlaubt ist, wird hierfür eine \textit{Common Table Expression}
2024-09-29 11:02:28 +02:00
verwendet, wie es in \autoref{lst:explain-optimize-cte} zu sehen ist. Zusätzlich wird noch ein Index auf die
\textit{document}"=Tabelle für die Spalten der Bedingung und der Sortierung erstellt, wie in
2024-09-28 21:50:12 +02:00
\autoref{lst:explain-optimize-cte-idx} zu sehen, damit in der \textit{Common Table Expression} nur der Index verwendet
2024-09-21 15:05:19 +02:00
werden kann und kein zusätzlicher Zugriff in die Tabelle notwendig ist.
\begin{lstlisting}[language=SQL,caption={Optimierung mit Common Table Expression},label=lst:explain-optimize-cte]
with doc_limit as (
select id
from public.document
where validuntil > now()
and ispublishedindb = true
order by startyear desc, startmonth desc, startday desc
limit 400
)
select *
from doc_limit t
join public.document t0 on t0.id = t.id
order by t0.startyear desc, t0.startmonth desc, t0.startday desc
\end{lstlisting}
\begin{lstlisting}[language=SQL,caption={Index für Common Table Expression},label=lst:explain-optimize-cte-idx]
create index idx_document_with_stmt on document using btree
( ispublishedindb, validuntil, startyear desc, startmonth desc
, startday desc, id );
\end{lstlisting}
2024-09-28 21:50:12 +02:00
Mit diesen Umstellungen erkennt man, dass die Kosten entsprechend gefallen sind. Ebenfalls konnte die Laufzeit um
2024-09-21 15:05:19 +02:00
mehr als den Faktor drei reduziert werden. Die Optimierung ist in \autoref{fig:explain-visualize-with} sehr deutlich
2024-09-26 23:43:15 +02:00
an den dünneren Verbindungslinien zwischen den Knoten und der Umstellung von einigen \textit{Seq Scan} zu
2024-09-21 15:05:19 +02:00
\textit{Index Scan} ersichtlich. Zeitgleich ist auch der teure \textit{HashAggregate} nicht mehr im Abfrageplan
vorhanden.
2024-09-28 16:16:31 +02:00
\begin{figure}[H]
2024-09-21 15:05:19 +02:00
\includegraphics[width=\linewidth]{gfx/chapter05_ExplainVisualize_with.png}
\caption{Visualisierung EXPLAIN with}
\label{fig:explain-visualize-with}
\end{figure}
2024-09-22 19:32:07 +02:00
Bei der Untersuchung der Abfrage zur \textit{Materialized View} ist direkt herausgekommen, dass hier keine Optimierung
2024-09-26 23:43:15 +02:00
mehr möglich ist, da durch die definierten Indexe bei den aktuell möglichen Sortierkriterien direkt ein
2024-09-22 19:32:07 +02:00
\textit{Index Scan} verwendet wird. Dies ist durch eine Überprüfung der Abfragepläne beweisbar, für diesen Fall wird
die Abfrage aus \autoref{lst:explain-search-document} verwendet.
2024-09-28 21:50:12 +02:00
\begin{lstlisting}[language=SQL,caption={Untersuchung searchdocument},label=lst:explain-search-document]
2024-09-22 19:32:07 +02:00
explain (analyze)
select sd.id, documentid, datetype, startyear, startmonth, startday
, startdatestatus , endyear, endmonth, endday, enddatestatus
, author, coauthors, addressees, city, documentcategory
, ispublishedindb, createdat, modifiedat, validuntil
from searchdocument sd
order by startyear desc, startmonth desc, startday desc
limit 400;
\end{lstlisting}
Der dazugehörige Abfrageplan ist in \autoref{lst:explain-search-document-output} zu sehen, hierbei ist die erste
2024-09-26 23:43:15 +02:00
Ausgabe mit dem erstellten Index. Vor der zweiten Ausgabe wurde dieser Index deaktiviert. Anhand der Ausgabe ist zu
2024-09-22 19:32:07 +02:00
sehen, dass bei der Verwendung des Index weniger Operation notwendig sind und damit auch die teure Sortierung
2024-09-26 23:43:15 +02:00
eingespart werden konnte. Dies liegt daran, dass der Index entsprechend des Sortierkriterien definiert wurde und
somit ist es möglich, direkt in dem Index die Elemente in der richtigen Reihenfolge zu ermitteln.
2024-09-28 21:50:12 +02:00
Somit ist durch den Index der schnellstmögliche Zugriff gegeben. Bei einem \textit{Seq Scan} ist die Ausgabe immer eine
2024-09-29 11:02:28 +02:00
unsortierte Liste und benötigt daher im Nachgang eine zusätzliche Sortierung.
2024-09-22 19:32:07 +02:00
2024-09-28 21:50:12 +02:00
\begin{lstlisting}[basicstyle=\scriptsize,caption={Abfrageplan searchdocument},label=lst:explain-search-document-output]
2024-09-22 19:32:07 +02:00
Limit (cost=0.28..144.92 rows=400 width=948) (actual time=0.035..0.660 rows=400 loops=1)
-> Index Scan Backward using idx_searchdocument_startdate on searchdocument sd (cost=0.28..1911.30 rows=5285 width=948) (actual time=0.033..0.593 rows=400 loops=1)
Planning Time: 0.199 ms
Execution Time: 0.732 ms
Limit (cost=747.69..748.69 rows=400 width=948) (actual time=2.128..2.146 rows=400 loops=1)
-> Sort (cost=747.69..760.90 rows=5285 width=948) (actual time=2.127..2.135 rows=400 loops=1)
Sort Key: startyear DESC, startmonth DESC, startday DESC
Sort Method: top-N heapsort Memory: 703kB
-> Seq Scan on searchdocument sd (cost=0.00..492.85 rows=5285 width=948) (actual time=0.006..0.943 rows=5285 loops=1)
Planning Time: 0.056 ms
Execution Time: 2.164 ms
\end{lstlisting}