Daily CheckIn

This commit is contained in:
marcodn 2024-09-10 23:33:57 +02:00
parent fe6592bfa2
commit 058472d1b4
5 changed files with 175 additions and 6 deletions

View file

@ -562,6 +562,30 @@ 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
\ref{lst:sql-materialized-view-index} zu sehen.
\begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view-index]
CREATE INDEX idx_searchdocument_documentid
ON searchdocument (documentid);
CREATE INDEX idx_searchdocument_author_surname_firstname
ON searchdocument ((author->>'surname'), (author->>'firstname'));
CREATE INDEX idx_searchdocument_startdate
ON searchdocument (startyear, startmonth, startday);
CREATE INDEX idx_searchdocument_addressees_first_entry
ON searchdocument
(((addressees->0->>'surname')::text), ((addressees->0->>'firstname')::text));
CREATE INDEX idx_searchdocument_city
ON searchdocument (city);
CREATE INDEX idx_searchdocument_documentcategory
ON searchdocument (documentcategory);
\end{lstlisting}
% document, first/last, documentaddresseeperson, documentcoauthorperson, documentfacsimile und count
% document, count, first/last
\begin{table}[h!]
@ -601,8 +625,6 @@ WHERE d.validuntil > NOW()
AND d.ispublishedindb = true;
\end{lstlisting}
\mytodos{Die Indizies noch mit aufnehmen!}
Nach dem Anpassungen haben sich dann die Werte aus \ref{tbl:measure-materialized-view-ext} ergeben.
\begin{table}[h!]
@ -628,6 +650,11 @@ Nach dem Anpassungen haben sich dann die Werte aus \ref{tbl:measure-materialized
\mytodos{prüfen ob ms oder msec die richtige SI-Einheit ist}
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
Laufzeit der Datenbankanfrage auf circa 20 ms verlängert. Wenn der Wert zu gering gewählt ist, dann wird zwar die
Laufzeit der Datenbankanfrage minimal verkürzt, aber die \textit{map}"=Funktion wird dadurch verlängert.
Da bei der Materialized View das laden der Daten und das wandeln in die Java"=Objekte getrennt programmiert wurde,
können hier eigene Zeitmessungen für die zwei Schritte eingebaut werden. Hierfür wird die Zeit vor dem
\textit{map}"=Aufruf und der \textit{map}"=Aufruf gemessen. Für den ersten Aufruf, wurde ein \textit{SearchDocument}
@ -638,10 +665,78 @@ erzeugt, noch ohne eine Konvertierung der ermittelten Daten in das Objekt, steig
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.
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
Laufzeit der Datenbankanfrage auf circa 20 ms verlängert. Wenn der Wert zu gering gewählt ist, dann wird zwar die
Laufzeit der Datenbankanfrage minimal verkürzt, aber die \textit{map}"=Funktion wird dadurch verlängert.
Nun wird noch geprüft, welche Performance das parsen der Json-Informationen im Server benötigt. Im ersten Schritt wird
die Parse-Funktion auskommentiert und die Seite nochmal aufgerufen. Durch diese Umstellung fällt die Laufzeit der
Datenermittlung auf circa 4 ms ab. Nun muss noch geprüft werden, welche Zeit nun der Client zum parsen der
\ac{Json}"=Daten benötigt. Hierfür werden die Daten in einem versteckten \textbf{span}"=Element hinterlegt, wie es im
Beispiel \ref{lst:jsf-datatable-json} zu sehen ist. Die hinterlegte \ac{CSS}"=Klasse ist zum auffinden der Elemente
für den späteren Javascript. Das \textbf{ajax}"=Element im Beispiel ist notwendig, damit bei einem Seitenwechsel die neu
übertragenen Elemente in eine lesbare Form gebracht werden.
\begin{lstlisting}[language=xml,caption={DataTable mit Json},label=lst:jsf-datatable-json]
<p:ajax event="page" oncomplete="convertJsonData()"/>
<p:column id="author" headerText="#{lang.List_Docs_Author}" sortable="true" sortBy="#{myObj.surname}">
<h:outputText styleClass="json-convert" style="display: none;" value="#{myObj.authorJson}"/>
</p:column>
<p:column id="Addressee"
headerText="#{lang.List_Docs_Addressee}"
sortable="true"
sortBy="#{(myObj.addresseePersonSet!=null and myObj.addresseePersonSet.size() > 0)?myObj.addresseePersonSet[0].addresseePerson:''}">
<h:outputText styleClass="json-convert" style="display: none;" value="#{myObj.adresseeJson}" data="abc"/>
</p:column>
\end{lstlisting}
Um nun die übertragenen \ac{Json}"=Daten in eine darstellbare Form zu bringen, benötigt man noch eine
JavaScript"=Funktion. Diese Funktion \ref{lst:jsf-datatable-json-convert} wird ermittelt erst alle versteckten Elemente,
parsed den Inhalt und erstellt neue \ac{HTML}"=Elemente mit dem darzustellenden Inhalt. Zusätzlich wird noch eine
Zeitmessung mit eingebaut, um die Laufzeit am Client für das Rendern in der Konsole anzuzeigen. Die Funktion wird nun
direkt nach dem die Webseite fertig geladen wurde gerufen.
\begin{lstlisting}[language=javascript,caption={Wandeln von Json nach Html},label=lst:jsf-datatable-json-convert]
function isEmpty(str) {
return (str === null) || (str === undefined) || (typeof str === "string" && str.length === 0);
}
function convertJsonData() {
let $jsonObj = $(".json-convert")
, start = new Date()
;
$.each($jsonObj, function() {
let json = this.innerHTML
, strEmpty = (json === null) || (typeof json === "string" && json.length === 0)
, jsonDat = strEmpty ? null : JSON.parse(json)
;
if(!strEmpty) {
let res = ""
, $that = $(this)
, $par = $that.parent()
;
$.each(jsonDat, function() {
let hasOnlyOne = isEmpty(this.surname) || isEmpty(this.firstname)
, pseudonymExists = !isEmpty(this.pseudonym)
, namePart = "<span>" + (hasOnlyOne ? this.surname + this.firstname : this.surname + ", " + this.firstname) + "</span><br/>"
, pseudoPart = pseudonymExists ? "<span class='w3-small w3-text-dark-gray'>" + this.pseudonym + "</span><br/>" : ""
;
res += namePart + pseudoPart;
});
$par.append(res);
}
});
let end = new Date()
, diff = (end - start)
;
console.log(Math.round(diff) + " ms");
}
$(document).ready(function() {
convertJsonData();
});
\end{lstlisting}
Da nun am Client Code ausgeführt wird, nachdem die Daten übertragen wurden, kann nicht mehr alles über das Script
durchgeführt werden. Daher werden nun die Laufzeiten am Server und am Client zusammenaddiert. Im Schnitt benötigt der
Aufruf auf der Serverseite nun 70 ms und am Client sind es circa 13 ms. Dies bedeutet addiert kommt man mit dieser
Lösung auf eine kürzere Laufzeit und weniger Last am Server.
%\mytodos{hier noch darauf eingehen, dass die Hauptarbeit nicht beim editieren sondern bei der Anzeige ist}
\mytodos{Hier könnte man auch den Query-Cache nochmal verwenden, da die anfragen nun fix wären}

View file

@ -30,6 +30,7 @@
\acro{GB}{Gigabyte}
\acro{SQL}{Structured Query Language}
\acro{JVM}{Java Virtual Machine}
\acro{JSON}{JavaScript Object Notation}
\end{acronym}
\cleardoublepage

Binary file not shown.

View file

@ -36,6 +36,7 @@
%lorem ipsum \lstinline|code| lorem ipsum
\input{tools/yaml_syntax_highlighting.tex}
\input{tools/javascript_syntax_hightlighting.tex}
%*************************************************************************

View file

@ -0,0 +1,72 @@
\lstdefinelanguage[ECMAScript2015]{JavaScript}[]{JavaScript}{
morekeywords=[1]{await, async, case, catch, class, const, default, do,
enum, export, extends, finally, from, implements, import, instanceof,
let, static, super, switch, throw, try},
morestring=[b]` % Interpolation strings.
}
\lstdefinelanguage{JavaScript}{
morekeywords=[1]{break, continue, delete, else, for, function, if, in,
new, return, this, typeof, var, void, while, with},
% Literals, primitive types, and reference types.
morekeywords=[2]{false, null, true, boolean, number, undefined,
Array, Boolean, Date, Math, Number, String, Object},
% Built-ins.
morekeywords=[3]{eval, parseInt, parseFloat, escape, unescape},
sensitive,
morecomment=[s]{/*}{*/},
morecomment=[l]//,
morecomment=[s]{/**}{*/}, % JavaDoc style comments
morestring=[b]',
morestring=[b]"
}[keywords, comments, strings]
\lstalias[]{ES6}[ECMAScript2015]{JavaScript}
\definecolor{mediumgray}{rgb}{0.3, 0.4, 0.4}
\definecolor{mediumblue}{rgb}{0.0, 0.0, 0.8}
\definecolor{forestgreen}{rgb}{0.13, 0.55, 0.13}
\definecolor{darkviolet}{rgb}{0.58, 0.0, 0.83}
\definecolor{royalblue}{rgb}{0.25, 0.41, 0.88}
\definecolor{crimson}{rgb}{0.86, 0.8, 0.24}
\lstdefinestyle{JSES6Base}{
backgroundcolor=\color{white},
basicstyle=\ttfamily,
breakatwhitespace=false,
breaklines=false,
captionpos=b,
columns=fullflexible,
commentstyle=\color{mediumgray}\upshape,
emph={},
emphstyle=\color{crimson},
extendedchars=true, % requires inputenc
fontadjust=true,
frame=single,
identifierstyle=\color{black},
keepspaces=true,
keywordstyle=\color{mediumblue},
keywordstyle={[2]\color{darkviolet}},
keywordstyle={[3]\color{royalblue}},
numbers=left,
numbersep=5pt,
numberstyle=\tiny\color{black},
rulecolor=\color{black},
showlines=true,
showspaces=false,
showstringspaces=false,
showtabs=false,
stringstyle=\color{forestgreen},
tabsize=2,
title=\lstname,
upquote=true % requires textcomp
}
\lstdefinestyle{JavaScript}{
language=JavaScript,
style=JSES6Base
}
\lstdefinestyle{ES6}{
language=ES6,
style=JSES6Base
}