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-20 01:21:04 +02:00
parent 7950816084
commit d25b366493
3 changed files with 34 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
chapters/thesis/appendix05_Provider.java
View file

@ -20,7 +20,7 @@ public class PerfStatisticsImpl implements PerfStatistics {
StoreCache cache = openJPAEntityManagerFactory.getStoreCache(); StoreCache cache = openJPAEntityManagerFactory.getStoreCache();
CacheStatistics st = cache.getStatistics(); 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 @Override
@ -30,6 +30,9 @@ public class PerfStatisticsImpl implements PerfStatistics {
EntityManagerFactory emf = openJPAEntityManagerFactory; EntityManagerFactory emf = openJPAEntityManagerFactory;
EntityManager em = emf.createEntityManager(); EntityManager em = emf.createEntityManager();
Cache cache = emf.getCache(); Cache cache = emf.getCache();
if (cache == null)
return "{}";
for(EntityType<?> entityType : em.getMetamodel().getEntities()) { for(EntityType<?> entityType : em.getMetamodel().getEntities()) {
Class<?> cls = entityType.getBindableJavaType(); Class<?> cls = entityType.getBindableJavaType();
res.append(String.format("\"%s\", ", cls.getCanonicalName())); res.append(String.format("\"%s\", ", cls.getCanonicalName()));

45
chapters/thesis/chapter05.tex
View file

@ -298,9 +298,17 @@ OpenJPA"=Cache nicht mehr verwendet wird. Zusätzlich steigt der Speicherverbrau
\section{Caching in EJB} \section{Caching in EJB}
\label{sec:performance-investigation-application:caching-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!] \begin{table}[h!]
\centering \centering
@ -311,10 +319,12 @@ Die Cache-Einstellungen des \ac{EJB} sind in der Admin-Oberfläche des Payara-Se
\hline \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 \hline
1 & 416 & 554 & 1269 & 12237 & 840.31 & 998.07 & 157.76 \\ %- & 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 & 299 & 394 & 749 & 12080 & 973.20 & 1101.37 & 128.17 \\ 1 & 364 & 741 & 2962 & 1222.1 & xxxx & 880.6 & 991.7 & xxx & 353 & 725 & 2902 & 248 & 366 & 689 \\ % 12221 -
3 & 293 & 324 & 382 & 12080 & 1092.00 & 1192.87 & 100.87 \\ 2 & 318 & 378 & 460 & 1208.0 & xxxx & 992.4 & 1099.0 & xxx & 310 & 370 & 451 & 225 & 275 & 362 \\ % 24301 -
4 & 281 & 318 & 398 & 12080 & 1191.25 & 1305.29 & 114.04 \\ 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 \hline
\end{tabular} \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 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. 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 In diesem Test wurde die von Herrn Holstein bereitgestellte Materialized View inklusive der Trigger und der
hinzugefügt, wie in \autoref{lst:sql-materialized-view} zu sehen. Somit können die nachfolgenden einzelnen Abfragen \textit{SearchDocument}"=Klasse verwendet. Wie in \autoref{lst:sql-materialized-view} zu sehen, wurden zur
eingespart werden. Dies wiederrum geht aber auf die Performance der Erstellung der Sicht und ihrer Aktualisierung. 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] \begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view]
CREATE MATERIALIZED VIEW searchdocument AS CREATE MATERIALIZED VIEW searchdocument AS
@ -564,8 +576,8 @@ FROM document d
LEFT JOIN sitecity sc ON sc.id = d.city_id; LEFT JOIN sitecity sc ON sc.id = d.city_id;
\end{lstlisting} \end{lstlisting}
Zusätzlich werden noch einige Indexe hinzugefügt, für eine bessere Performance bei der Abfrage, wie in Zusätzlich zur View, werden noch die Indexe aus \autoref{lst:sql-materialized-view-index} erstellt. Diese werden für
\autoref{lst:sql-materialized-view-index} zu sehen. für eine bessere Performance der Abfrage benötigt.
\begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view-index] \begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view-index]
CREATE INDEX idx_searchdocument_documentid CREATE INDEX idx_searchdocument_documentid
@ -589,6 +601,9 @@ CREATE INDEX idx_searchdocument_documentcategory
ON searchdocument (documentcategory); ON searchdocument (documentcategory);
\end{lstlisting} \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, first/last, documentaddresseeperson, documentcoauthorperson, documentfacsimile und count
% document, count, first/last % document, count, first/last
\begin{table}[h!] \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. und der Koautoren komplett entfallen.
Nach dem der Quellcode nochmal untersucht wurde, konnte man festellen, dass bei jeder Anfrage die gleiche Bedingung 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 benötigt wurde. Da die Sicht nun explizit für dies Anfrage geschaffen wurde, wurde die Bedingungen nun direkt in die
mit integriert. Dies bedeutet eine Erweiterung der Sicht aus \autoref{lst:sql-materialized-view} um 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. \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] \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} \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 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 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. 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. 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 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 dieser Wert zu klein oder groß definiert ist, wird die Laufzeit verschlechtert. Bei einem zu großen Wert wird die

BIN
thesis.pdf
View file

Binary file not shown.