Daily CheckIn
This commit is contained in:
marcodn
parent
fe6592bfa2
commit
058472d1b4
5 changed files with 175 additions and 6 deletions
|
|
@ -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}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue