diff --git a/chapters/thesis/appendix02_timing.sh b/chapters/thesis/appendix02_timing.sh index 3bfe33a..6ff1132 100644 --- a/chapters/thesis/appendix02_timing.sh +++ b/chapters/thesis/appendix02_timing.sh @@ -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 diff --git a/chapters/thesis/chapter04.tex b/chapters/thesis/chapter04.tex index 2b6ebe5..efe7e6c 100644 --- a/chapters/thesis/chapter04.tex +++ b/chapters/thesis/chapter04.tex @@ -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 diff --git a/chapters/thesis/chapter05.tex b/chapters/thesis/chapter05.tex index 2e6ec22..46c7bcf 100644 --- a/chapters/thesis/chapter05.tex +++ b/chapters/thesis/chapter05.tex @@ -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} } diff --git a/chapters/thesis/chapter06.tex b/chapters/thesis/chapter06.tex index ccad5f3..aff2967 100644 --- a/chapters/thesis/chapter06.tex +++ b/chapters/thesis/chapter06.tex @@ -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 diff --git a/thesis.pdf b/thesis.pdf index 811cca4..bcecbb0 100644 Binary files a/thesis.pdf and b/thesis.pdf differ