Daily CheckIn
This commit is contained in:
marcodn
parent
7950816084
commit
d25b366493
3 changed files with 34 additions and 16 deletions
|
|
@ -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()));
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
BIN
thesis.pdf
BIN
thesis.pdf
Binary file not shown.
Loading…
Reference in a new issue