diff --git a/chapters/thesis/appendix05_Provider.java b/chapters/thesis/appendix05_Provider.java index 158d2b8..ae3739f 100644 --- a/chapters/thesis/appendix05_Provider.java +++ b/chapters/thesis/appendix05_Provider.java @@ -20,7 +20,7 @@ public class PerfStatisticsImpl implements PerfStatistics { StoreCache cache = openJPAEntityManagerFactory.getStoreCache(); CacheStatistics st = cache.getStatistics(); - return String.format("{ \"ReadCount\": %d, \"HitCount\": %d, \"WriteCount\": %d }", st.getReadCount(), st.getHitCount(), st.getWriteCount()); + return st != null ? String.format("{ \"ReadCount\": %d, \"HitCount\": %d, \"WriteCount\": %d }", st.getReadCount(), st.getHitCount(), st.getWriteCount()) : "{}"; } @Override @@ -30,6 +30,9 @@ public class PerfStatisticsImpl implements PerfStatistics { EntityManagerFactory emf = openJPAEntityManagerFactory; EntityManager em = emf.createEntityManager(); Cache cache = emf.getCache(); + if (cache == null) + return "{}"; + for(EntityType entityType : em.getMetamodel().getEntities()) { Class cls = entityType.getBindableJavaType(); res.append(String.format("\"%s\", ", cls.getCanonicalName())); diff --git a/chapters/thesis/chapter05.tex b/chapters/thesis/chapter05.tex index abf3813..56474e7 100644 --- a/chapters/thesis/chapter05.tex +++ b/chapters/thesis/chapter05.tex @@ -298,9 +298,17 @@ OpenJPA"=Cache nicht mehr verwendet wird. Zusätzlich steigt der Speicherverbrau \section{Caching in EJB} \label{sec:performance-investigation-application:caching-ejb} -Die Cache-Einstellungen des \ac{EJB} sind in der Admin-Oberfläche des Payara-Servers zu erreichen. Hier +Die Cache-Einstellungen des \ac{EJB} sind in der Admin-Oberfläche des Payara-Servers zu erreichen. Unter dem Punkt +Configurations $\Rightarrow$ server!=config $\Rightarrow$ EJB Container werden zum einem die minimalen und maximalen +Größen des Pools definiert werden. Ebenso wird an dieser Stelle die maximale Größe des Caches und die Größe der +Erweiterung definiert. -\mytodos{Cache config noch definieren} +Anhand der Auswertung der \autoref{tbl:measure-ejb-cache-active} ist ersichtlich, dass der \ac{EJB}"=Cache keine +Auswirkung auf die Performance hat. Und es ist ersichtlich, dass die Anzahl der Datenbankabfragen nicht reduziert +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} \begin{table}[h!] \centering @@ -311,10 +319,12 @@ Die Cache-Einstellungen des \ac{EJB} sind in der Admin-Oberfläche des Payara-Se \hline \# & min & avg & max & \#"=avg & avg & start & stop & diff & min & avg & max & min & avg & max \\ \hline - 1 & 416 & 554 & 1269 & 12237 & 840.31 & 998.07 & 157.76 \\ - 2 & 299 & 394 & 749 & 12080 & 973.20 & 1101.37 & 128.17 \\ - 3 & 293 & 324 & 382 & 12080 & 1092.00 & 1192.87 & 100.87 \\ - 4 & 281 & 318 & 398 & 12080 & 1191.25 & 1305.29 & 114.04 \\ + %- & 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 - \hline \end{tabular} } @@ -479,9 +489,11 @@ Der größte Nachteil dieser Sichten ist, dass sie zyklisch oder bei Datenänder läuft der Datenbestand der Sicht und der zugrundeliegenden Abfrage auseinander. Da die Hauptarbeiten auf der Webseite die Abfrage der Daten ist, und nicht das editieren, kann dieser Nachteil bei entsprechender Optimierung ignoriert werden. -In diesem Test, wurde zusätzlich zur normalen Abfragen noch die nachfolgenden einzelabfragen als Sub-Selects -hinzugefügt, wie in \autoref{lst:sql-materialized-view} zu sehen. Somit können die nachfolgenden einzelnen Abfragen -eingespart werden. Dies wiederrum geht aber auf die Performance der Erstellung der Sicht und ihrer Aktualisierung. +In diesem Test wurde die von Herrn Holstein bereitgestellte Materialized View inklusive der Trigger und der +\textit{SearchDocument}"=Klasse verwendet. Wie in \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 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. \begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view] CREATE MATERIALIZED VIEW searchdocument AS @@ -564,8 +576,8 @@ FROM document d LEFT JOIN sitecity sc ON sc.id = d.city_id; \end{lstlisting} -Zusätzlich werden noch einige Indexe hinzugefügt, für eine bessere Performance bei der Abfrage, wie in -\autoref{lst:sql-materialized-view-index} zu sehen. +Zusätzlich zur View, werden noch die Indexe aus \autoref{lst:sql-materialized-view-index} erstellt. Diese werden für +für eine bessere Performance der Abfrage benötigt. \begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view-index] CREATE INDEX idx_searchdocument_documentid @@ -589,6 +601,9 @@ CREATE INDEX idx_searchdocument_documentcategory ON searchdocument (documentcategory); \end{lstlisting} +Für die Darstellung wurden die aktuell vorhandenen Elemente die die Liste der Dokumente anzeigt kopiert und auf die +neue SearchDocument"=Klasse angepasst. + % document, first/last, documentaddresseeperson, documentcoauthorperson, documentfacsimile und count % document, count, first/last \begin{table}[h!] @@ -619,8 +634,8 @@ nur noch vier statt der 6 Abfragen an die Datenbank gestellt werden, da einzelab und der Koautoren komplett entfallen. Nach dem der Quellcode nochmal untersucht wurde, konnte man festellen, dass bei jeder Anfrage die gleiche Bedingung -benötigt wurde. Da die Sicht nun explizit für dies Anfrage geschaffen wurde, wurde die Bedingungen nun direkt in Sicht -mit integriert. Dies bedeutet eine Erweiterung der Sicht aus \autoref{lst:sql-materialized-view} um +benötigt wurde. Da die Sicht nun explizit für dies Anfrage geschaffen wurde, wurde die Bedingungen nun direkt in die +Sicht mit integriert. Dies bedeutet eine Erweiterung der Sicht aus \autoref{lst:sql-materialized-view} um \autoref{lst:sql-materialized-view-ext} und das entfernen der Parameter aus dem SQL-Anfragen im Java-Code. \begin{lstlisting}[language=SQL,caption={SQL Materialized View Erweiterung},label=lst:sql-materialized-view-ext] @@ -656,10 +671,10 @@ können hier eigene Zeitmessungen für die zwei Schritte eingebaut werden. Hierf \textit{map}"=Aufruf und der \textit{map}"=Aufruf gemessen. Für den ersten Aufruf, wurde ein \textit{SearchDocument} Objekt erzeugt und immer diese Objekt zurückgegeben. Damit wurde erst mal überprüft, wie lange das ermitteln der Daten und das durcharbeiten der Ergebnisse bestimmt. Hierbei lagen die Zeiten bei circa 1 ms für das reine Datenladen und 3 ms -für den Aufruf der \textit{map}"=Funktion. Sobald mal innerhalb der \textit{map}"=Funktion pro Eintrag ein Objekt +für den Aufruf der \textit{map}"=Funktion. Sowie innerhalb der \textit{map}"=Funktion pro Eintrag ein Objekt erzeugt, noch ohne eine Konvertierung der ermittelten Daten in das Objekt, steigt die Laufzeit schon auf 54 ms. Wenn man nun noch die Konvertierung der Daten wieder einbaut, steigt die Laufzeit nochmal auf nun 82 ms. -Dies zeigt, alleine das erzeugen der Objekt kostet die meiste Zeit. +Dies zeigt, alleine das erzeugen der Objekt und der Json"=Parse Aufruf kostet die meiste Zeit. Bei der Verwendung des Hints \textit{openjpa.""FetchPlan.""FetchBatchSize} kann die Abfrage enorm verschlechtern. Wenn dieser Wert zu klein oder groß definiert ist, wird die Laufzeit verschlechtert. Bei einem zu großen Wert wird die diff --git a/thesis.pdf b/thesis.pdf index 5a5b274..07dc529 100644 Binary files a/thesis.pdf and b/thesis.pdf differ