mdn/bachelor-thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Daily CheckIn

Browse source
This commit is contained in:
marcodn 2024-09-24 00:08:33 +02:00
parent 7ae5b1ce95
commit 76f548484c
5 changed files with 63 additions and 61 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
chapters/thesis/appendix02_timing.sh
View file

@ -96,8 +96,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/listsearch.xhtml"
#"$hostname/view/document/list.xhtml"
"$hostname/view/document/listsearch.xhtml"
)
#print_process

9
chapters/thesis/chapter04.tex
View file

@ -122,7 +122,11 @@ EXPLAIN (ANALYZE, VERBOSE, BUFFERS, SUMMARY)
select * from document;
\end{lstlisting}
\mytodos{hier noch die Typen der Knoten erklären?}
Die zwei bekanntesten Knotentypen sind \textit{Seq Scan} und \textit{Index Scan}. Beim \textit{Seq Scan} wird die
Tabelle Zeile für Zeile gelesen und wenn vorhanden nach den Bedingungen gefiltert, hierbei entsteht eine unsortierte
Liste, entsprechend sind die Startkosten niedrig. Die bessere Alternative ist der \textit{Index Scan}, bei dem der
Index nach den Kriterien durchsucht wird, was meist durch den Aufbau des Index als BTree (Multi"=Way Balanced Tree)
sehr schnell geht.
Eine weitere Optimierungsmöglichkeiten sind die Verwendung von Indexe. Diese sind aber mit bedacht zu wählen, da bei
mehreren Indexen die sehr ähnlich sind, nicht immer der gewünschte Index bei der Abfrage verwendet wird. Auch bedeutet
@ -144,7 +148,8 @@ Zusätzlich kann über die Systemtabelle \textit{pg\_statistic} oder die lesbare
aktuelle statistischen Informationen über eine Tabelle und deren Spalten ermittelt werden. In dieser Tabelle werden
durch das \textit{ANALYZE} beziehungsweise \textit{VACUUM ANALYZE} Kommando die Informationen zum Anteil der
\textit{NULL}"=Werte (null\_frac), Durchschnittlichen Größe (avg\_width), unterschiedlicher Werte (n\_distinct) und
weitere gesammelt und für die Erstellung der Abfragepläne verwendet \citep{PostgreS39:online}.
weitere gesammelt und für die Erstellung der Abfragepläne verwendet \citep{PostgreS39:online}. Diese Information
sollte vor dem erstellen eines Index betrachtet werden.
Diese Informationen können noch durch das Kommando \textit{CREATE STATISTICS} erweitert werden, für einen besseren
Abfrageplan. Das aktivieren der zusätzlichen Statistiken sollten immer in Verbindung mit dem überprüfung des

94
chapters/thesis/chapter05.tex
View file

@ -3,8 +3,6 @@
\chapter{Performance-Untersuchung der Anwendung}
\label{ch:performance-investigation-application}
\mytodos{Sortierung nochmal überlegen, sinnvoller wäre doch anhand der Schichten aus Kapitel 2}
Nun werden die unterschiedlichen Schichten betrachtet und möglichen Performance"=Verbesserungen untersucht und deren
Vor"= und Nachteile herausgearbeitet.
@ -111,20 +109,6 @@ zu laden, und in die Java-Objekte umzuformen.
\label{tbl:measure-without-cache-docker}
\end{table}
\section{Umgestalten der Datenbanktabellen}
\label{sec:performance-investigation-application:new-table}
\mytodos{Sollte das nicht auch in die Evaluierung?}
Hierfür wurde die aktuelle Datenstruktur untersucht um zu prüfen, ob eine Umgestaltung der Tabelle einen Verbesserung
bringen würden. Die typische Optimierung ist die Normalisierung der Tabellenstruktur. Die Tabellenstruktur ist aktuell
schon normalisiert, daher kann hier nichts weiter optimiert werden.
Eine weitere Optimierungsstrategie besteht in der Denormalisierung, um sich die Verknüpfungen der Tabellen zu sparen.
Dies ist in diesem Fall nicht anwendbar, da nicht nur 1:n Beziehungen vorhanden sind, sondern auch auch n:m Beziehungen.
Dadurch würden sich die Anzahl der Dokumentenliste erhöhen. Eine weitere Möglichkeit wäre es, die Duplikate auf der
Serverseite zusammenzuführen.
\section{Caching im OpenJPA}
\label{sec:performance-investigation-application:caching-openjpa}
@ -245,11 +229,11 @@ mit \ac{JPQL} oder mit der Criteria API abfragt.
\hline
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
\hline
1 & 409 & 771 & 2660 & 1222.4 & xxx & 850.4 & 982.8 & 132.4 & 366 & 633 & 2019 & 254 & 364 & 758 \\ % 12224 - 332 ms (168+ 63+ 44+ 32+21+ 4) (#1,3-6,10)
2 & 336 & 387 & 504 & 1208.0 & xxx & 982.9 & 1113.0 & 130.1 & 310 & 374 & 433 & 221 & 268 & 345 \\ % 24304 -
3 & 312 & 373 & 422 & 1208.0 & xxx & 1114.0 & 1221.0 & 107.0 & 295 & 401 & 658 & 216 & 320 & 570 \\ % 36384 -
4 & 288 & 363 & 471 & 1208.0 & xxx & 1239.0 & 1474.0 & 235.0 & 269 & 356 & 486 & 200 & 279 & 405 \\ % 48464 -
5 & 325 & 398 & 535 & 1208.0 & xxx & 1474.0 & 1666.0 & 192.0 & 280 & 466 & 804 & 208 & 390 & 725 \\ % 60544 -
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)
\hline
\end{tabular}
}
@ -257,8 +241,6 @@ mit \ac{JPQL} oder mit der Criteria API abfragt.
\label{tbl:measure-cached-queries}
\end{table}
\mytodos{Queryzeiten fehlen nocht}
\section{Caching mit Ehcache}
\label{sec:performance-investigation-application:caching-ehcache}
@ -275,7 +257,10 @@ in der \textit{ehcache.xml}.
Anhand der Auswertung von \ref{tbl:measure-ehcache-active} sieht man, dass der Ehcache einen starke Performance
Verbesserung aufbringt. Über die Performance"=Statistik"=Webseite kann beobachtet werden, dass bei gleichen Aufruf
der Webseite nur die Treffer in Cache steigen, aber die Misses nicht. Ebenfalls erhöht sich die Anzahl der Objekte
im Cache nicht. Zusätzlich steigt in diesem Fall der Speicherverbrauch nur gering bis gar nicht.
im Cache nicht. Zusätzlich steigt in diesem Fall der Speicherverbrauch nur gering bis gar nicht. Zusätzlich zeigt sich,
das sich die Abfragezeiten in der Datenbank nur gering verkürzt wurden, aber die Laufzeit der Webseite sich starkt
verbessert hat. Dies lässt auch hier den Schluss zu, dass die Erstellung der Objekte im OpenJPA die meiste Zeit
benötigt.
% document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile
\begin{table}[h!]
@ -288,11 +273,11 @@ im Cache nicht. Zusätzlich steigt in diesem Fall der Speicherverbrauch nur geri
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
\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)
1 & 156 & 488 & 2820 & 135.2 & xxx & 981.6 & 1006.0 & 24.4 & 147 & 490 & 2809 & 39 & 175 & 1186 \\ % 1352 -
2 & 135 & 144 & 166 & 6.0 & xxx & 1006.0 & 1007.0 & 1.0 & 124 & 136 & 157 & 33 & 38 & 47 \\ % 1412 -
3 & 121 & 129 & 136 & 6.0 & xxx & 1008.0 & 1009.0 & 1.0 & 113 & 121 & 126 & 32 & 34 & 33 \\ % 1472 -
4 & 116 & 123 & 133 & 6.0 & xxx & 1008.0 & 1016.0 & 8.0 & 108 & 116 & 125 & 31 & 33 & 34 \\ % 1532 -
5 & 111 & 118 & 127 & 6.0 & xxx & 1016.0 & 1012.0 & -4.0 & 104 & 111 & 119 & 32 & 34 & 38 \\ % 1592 -
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)
\hline
\end{tabular}
}
@ -300,7 +285,6 @@ im Cache nicht. Zusätzlich steigt in diesem Fall der Speicherverbrauch nur geri
\label{tbl:measure-ehcache-active}
\end{table}
\section{Caching in EJB}
\label{sec:performance-investigation-application:caching-ejb}
@ -314,8 +298,7 @@ Auswirkung auf die Performance hat. Und es ist ersichtlich, dass die Anzahl der
wurden. Dies ist dadurch zu erklären, dass im \ac{EJB} die Provider gelagert werden, die über Dependency Injection
den Controller bereitgestellt werden. Die Objekt selbst werden nicht im \ac{EJB}"=Cache hinterlegt.
\mytodos{Messzeiten fehlen noch}
% document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile
\begin{table}[h!]
\centering
\resizebox{\textwidth}{!}{
@ -325,12 +308,11 @@ den Controller bereitgestellt werden. Die Objekt selbst werden nicht im \ac{EJB}
\hline
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
\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)
1 & 364 & 741 & 2962 & 1222.1 & xxxx & 880.6 & 991.7 & xxx & 353 & 725 & 2902 & 248 & 366 & 689 \\ % 12221 -
2 & 318 & 378 & 460 & 1208.0 & xxxx & 992.4 & 1099.0 & xxx & 310 & 370 & 451 & 225 & 275 & 362 \\ % 24301 -
3 & 314 & 397 & 528 & 1208.0 & xxxx & 1109.0 & 1308.0 & xxx & 306 & 388 & 519 & 227 & 307 & 434 \\ % 36381 -
4 & 334 & 371 & 420 & 1208.0 & xxxx & 1308.0 & 1528.0 & xxx & 326 & 363 & 412 & 246 & 289 & 333 \\ % 48461 -
5 & 304 & 392 & 562 & 1208.0 & xxxx & 1518.0 & 1662.0 & xxx & 297 & 385 & 555 & 229 & 311 & 478 \\ % 60541 -
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)
\hline
\end{tabular}
}
@ -455,12 +437,13 @@ Abfragen in den Java-Objekten fast identisch sind. Und in der Datenbank sind die
\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 \\
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
\hline
1 & 396 & 572 & 1535 & 12173 & 796.59 & 970.10 & 173.51 \\
2 & 333 & 366 & 397 & 12080 & 982.28 & 1064.12 & 81.84 \\
3 & 286 & 339 & 554 & 12080 & 1048.12 & 1162.92 & 114.80 \\
4 & 293 & 317 & 388 & 12080 & 1150.43 & 1263.77 & 113.34 \\
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)
\hline
\end{tabular}
}
@ -614,13 +597,13 @@ vorhanden Elemente die die Liste der Dokumente anzeigt kopiert und auf die \text
\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 \\
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
\hline
1 & 203 & 315 & 808 & 17.8 & 3.0 & 851.4 & 883.9 & 32.5 \\ % 178 - 30 ms (19+11+0) (#2,4,8)
2 & 154 & 172 & 187 & 9.0 & 2.2 & 883.2 & 887.0 & 3.8 \\ % 268 - 52 ms (33+18+1) (#2,3,8)
3 & 145 & 151 & 163 & 9.0 & 2.8 & 887.7 & 895.3 & 7.6 \\ % 358 - 80 ms (52+27+1) (#2,3,8)
4 & 132 & 143 & 152 & 9.0 & 2.8 & 896.0 & 900.0 & 4.0 \\ % 448 - 108 ms (70+37+1) (#2,3,8)
5 & 121 & 125 & 132 & 9.0 & 2.4 & 900.6 & 901.0 & 0.4 \\ % 538 - 132 ms (85+46+1) (#2,3,8)
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)
\hline
\end{tabular}
}
@ -644,7 +627,8 @@ WHERE d.validuntil > NOW()
AND d.ispublishedindb = true;
\end{lstlisting}
Nach dem Anpassungen haben sich dann die Werte aus \autoref{tbl:measure-materialized-view-ext} ergeben.
Nach dem Anpassungen haben sich dann die Werte aus \autoref{tbl:measure-materialized-view-ext} ergeben. Diese Werte
zeigen nur minimale Unterschiede in den Zeiten, was auf Messtoleranzen zurückzuführen ist.
\begin{table}[h!]
\centering
@ -655,11 +639,11 @@ Nach dem Anpassungen haben sich dann die Werte aus \autoref{tbl:measure-material
\hline
\# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\
\hline
1 & 241 & 348 & 859 & 16.8 & xxx & 896.0 & 932.4 & 36.4 & 232 & 331 & 803 & 132 & 174 & 334 \\ % 168 -
2 & 164 & 194 & 225 & 9.0 & xxx & 933.3 & 935.9 & 2.6 & 154 & 185 & 215 & 79 & 99 & 117 \\ % 258 -
3 & 147 & 161 & 179 & 9.0 & xxx & 935.8 & 938.8 & 3.0 & 139 & 152 & 167 & 68 & 77 & 86 \\ % 348 -
4 & 135 & 145 & 183 & 9.0 & xxx & 939.4 & 936.0 & -3.4 & 127 & 137 & 174 & 70 & 73 & 75 \\ % 438 -
5 & 126 & 137 & 154 & 9.0 & xxx & 936.1 & 939.1 & 3.0 & 118 & 129 & 143 & 66 & 72 & 79 \\ % 528 -
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)
\hline
\end{tabular}
}

17
chapters/thesis/chapter06.tex
View file

@ -22,6 +22,18 @@ Zusätzlich war noch eine Befragung unter den Benutzer und den Entwicklern gepla
Personen zur Verfügung stehen ist dies nicht zielführend. Daher ist die einzig sinnvolle Alternative, welche gewählt
wurde, ein rein technischer Ansatz.
\section{Umgestalten der Datenbanktabellen}
\label{sec:evaluation:new-table}
Hierfür wurde die aktuelle Datenstruktur untersucht um zu prüfen, ob eine Umgestaltung der Tabelle einen Verbesserung
bringen würden. Die typische Optimierung ist die Normalisierung der Tabellenstruktur. Die Tabellenstruktur ist aktuell
schon normalisiert, daher kann hier nichts weiter optimiert werden.
Eine weitere Optimierungsstrategie besteht in der Denormalisierung, um sich die Verknüpfungen der Tabellen zu sparen.
Dies ist in diesem Fall nicht anwendbar, da nicht nur 1:n Beziehungen vorhanden sind, sondern auch auch n:m Beziehungen.
Dadurch würden sich die Anzahl der Dokumentenliste erhöhen. Eine weitere Möglichkeit wäre es, die Duplikate auf der
Serverseite zusammenzuführen.
\section{Statische Webseiten}
\label{sec:evaluation:static-website}
@ -100,7 +112,8 @@ Standardkonfiguration jede Klasse ihren eigenen Cache besitzt. Diese können ein
werden, um diese genau auf die jeweiligen Bedürfnisse der Objekte anzupassen.
Im Falle der Verwendung des Caches, ist auch hier gut zu sehen, dass der Speicheranstieg bei der Verwendung des Caches
sehr gering ist, was den Schluss zulässt, dass der Cache nur zu einem kleinen \mytodos{hier fehlt was}
sehr gering ist, dies deutet ebenfalls darauf hin, dass die Speicherproblematik beim Erstellen von Objekten innerhalb
des OpenJPA Framework liegen muss.
Durch die effizienter Verwendung des Speichers, ist der Ehcache die bessere Alternative zum OpenJPA"=Cache. Dieser ist
auch schon für kleinere Serverkonfigurationen gut verwendbar. Hierbei ist nur abzuwägen, mit welcher Größe der Cache
@ -168,7 +181,7 @@ für jede Datenzeile einzeln durchgeführt wird.
Zusätzlich konnte dies nochmal beschleunigt werden, in dem das parsen der \textit{Json}"=Daten vom Server auf den Client
verlagert wurde. Hiermit konnte zum einen Last vom Server genommen werden und die gesamte Ausführungszeit nochmals
optimieren. Die Wandlung der Daten in \textit{HTML}"=Objekte ist eine Kernkompetenz von JavaScript und damit auch bei
schwächeren Clients in kurzer Zeit durchzuführen. \mytodos{durchführbar?}
schwächeren Clients in kurzer Zeit durchführbar.
Zusammenfassend ist zu sagen, dass die \textit{Materialized View} eine gute Wahl sind, um die Listendarstellungen
zu optimieren. Mit dieser Technik können zum einen die Abfragezeiten optimiert werden, wodurch gleichzeit die

BIN
thesis.pdf
View file

Binary file not shown.