Umbauen nach Gespräch mit Herrn Hollstein
This commit is contained in:
marcodn
parent
d2837189e1
commit
edc2b5e15f
13 changed files with 247 additions and 60 deletions
46
.vscode/settings.json
vendored
46
.vscode/settings.json
vendored
|
|
@ -1,6 +1,6 @@
|
|||
{
|
||||
"cSpell.language": "de-de,en",
|
||||
"cSpell.words": [
|
||||
"cSpell.words": [
|
||||
"autovacuum",
|
||||
"editionswissenschaftlich",
|
||||
"EFFW",
|
||||
|
|
@ -8,13 +8,57 @@
|
|||
"freigeschalten",
|
||||
"Galster",
|
||||
"Glassfish",
|
||||
"JPQL",
|
||||
"Konsolenanwendungen",
|
||||
"Multifunktionalität",
|
||||
"Persistenzkontext",
|
||||
"Planerstatistiken",
|
||||
"Plantypen",
|
||||
"SFSB",
|
||||
"unterlagerte",
|
||||
"Wallstein",
|
||||
],
|
||||
"cSpell.ignoreRegExpList": [],
|
||||
"cSpell.overrides": [
|
||||
{
|
||||
"filename": "*.sql",
|
||||
"languageId": "sql"
|
||||
}
|
||||
],
|
||||
"cSpell.ignoreWords": [
|
||||
"Alwas",
|
||||
"Backmatter",
|
||||
"Classname",
|
||||
"Datasource",
|
||||
"Frontmatter",
|
||||
"JNDI",
|
||||
"Laravel",
|
||||
"Latexmk",
|
||||
"Mainmatter",
|
||||
"Nautsch",
|
||||
"Payara",
|
||||
"Poolname",
|
||||
"Postgresql",
|
||||
"Ressources",
|
||||
"Symfony",
|
||||
"american",
|
||||
"asadmin",
|
||||
"classicthesis",
|
||||
"downto",
|
||||
"ferniunithesis",
|
||||
"fmtutil",
|
||||
"gpasswd",
|
||||
"javax",
|
||||
"jdbc",
|
||||
"maxint",
|
||||
"ngerman",
|
||||
"pacman",
|
||||
"payara",
|
||||
"payra",
|
||||
"postgresql",
|
||||
"println",
|
||||
"texlive",
|
||||
"wedekind",
|
||||
"xsep"
|
||||
],
|
||||
}
|
||||
|
|
@ -77,11 +77,11 @@ zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizie
|
|||
\node (fitClient) [fit=(browser)] {};
|
||||
\node [left] at (fitClient.west) {Client};
|
||||
|
||||
\node (JSP) [block,below of=browser,node distance=7em] {Java Server Pages};
|
||||
\node (EJB) [block,below of=JSP] {Enterprise Java Beans};
|
||||
\node (JSF) [block,below of=browser,node distance=7em] {Java Server Faces};
|
||||
\node (EJB) [block,below of=JSF] {Enterprise Java Beans};
|
||||
\node (JPA) [block,below of=EJB] {Java Persistance API};
|
||||
\node (openJPA) [block, below of=JPA] {OpenJPA Cache};
|
||||
\node (fitGlassfish) [fit=(JSP) (EJB) (JPA) (openJPA)] {};
|
||||
\node (fitGlassfish) [fit=(JSF) (EJB) (JPA) (openJPA)] {};
|
||||
\node [left] at (fitGlassfish.west) {Glassfish};
|
||||
|
||||
\node (memoryBuffers) [block, below of=openJPA] {Memory Buffers};
|
||||
|
|
@ -93,8 +93,8 @@ zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizie
|
|||
\node (fitServer) [fit=(fitGlassfish) (fitPostgreSQL),inner xsep=5em] {};
|
||||
\node [left] at (fitServer.west) {Server};
|
||||
|
||||
\draw[lineArrow] (browser)--(JSP);
|
||||
\draw[lineArrow] (JSP)--(EJB);
|
||||
\draw[lineArrow] (browser)--(JSF);
|
||||
\draw[lineArrow] (JSF)--(EJB);
|
||||
\draw[lineArrow] (EJB)--(JPA);
|
||||
\draw[lineArrow] (JPA)--(openJPA);
|
||||
\draw[lineArrow] (openJPA)--(memoryBuffers);
|
||||
|
|
@ -249,7 +249,7 @@ Nun wird die EJB-Schicht überprüft und die aufgerufen Funktionen betrachtet, o
|
|||
Aufgaben übernehmen und dadurch schlecht optimiert werden können. Solche Funktionen sollten dupliziert werden und auf
|
||||
die jeweilige Aufgabe spezifisch zugeschnitten und optimiert werden.
|
||||
|
||||
Abschließend ist die JSP-Schicht zu betrachten, welche noch logische Anpassungen für die Optimierungen zulässt,
|
||||
Abschließend ist die \ac{JSF}-Schicht zu betrachten, welche noch logische Anpassungen für die Optimierungen zulässt,
|
||||
wie das Einfügen von Paging. Damit kann die ermittelnde Datenmenge verringert werden, dies führt zu schnelleren
|
||||
Abfragen, weniger Daten die im Cache vorgehalten werden müssen, den Aufbau der Seite zu beschleunigen und damit auch
|
||||
die Datenmenge die an den Browser übermittelt wird zu reduzieren.
|
||||
|
|
|
|||
|
|
@ -33,11 +33,11 @@ zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizie
|
|||
\node (fitClient) [fit=(browser)] {};
|
||||
\node [left] at (fitClient.west) {Client};
|
||||
|
||||
\node (JSP) [block,below of=browser,node distance=7em] {Java Server Pages};
|
||||
\node (EJB) [block,below of=JSP] {Enterprise Java Beans};
|
||||
\node (JSF) [block,below of=browser,node distance=7em] {Java Server Faces};
|
||||
\node (EJB) [block,below of=JSF] {Enterprise Java Beans};
|
||||
\node (JPA) [block,below of=EJB] {Java Persistance API};
|
||||
\node (openJPA) [block, below of=JPA] {OpenJPA Cache};
|
||||
\node (fitGlassfish) [fit=(JSP) (EJB) (JPA) (openJPA)] {};
|
||||
\node (fitGlassfish) [fit=(JSF) (EJB) (JPA) (openJPA)] {};
|
||||
\node [left] at (fitGlassfish.west) {Glassfish};
|
||||
|
||||
\node (memoryBuffers) [block, below of=openJPA] {Memory Buffers};
|
||||
|
|
@ -49,8 +49,8 @@ zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizie
|
|||
\node (fitServer) [fit=(fitGlassfish) (fitPostgreSQL),inner xsep=5em] {};
|
||||
\node [left] at (fitServer.west) {Server};
|
||||
|
||||
\draw[lineArrow] (browser)--(JSP);
|
||||
\draw[lineArrow] (JSP)--(EJB);
|
||||
\draw[lineArrow] (browser)--(JSF);
|
||||
\draw[lineArrow] (JSF)--(EJB);
|
||||
\draw[lineArrow] (EJB)--(JPA);
|
||||
\draw[lineArrow] (JPA)--(openJPA);
|
||||
\draw[lineArrow] (openJPA)--(memoryBuffers);
|
||||
|
|
@ -61,7 +61,7 @@ zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizie
|
|||
\label{fig:webrequest}
|
||||
\end{figure}
|
||||
|
||||
\section{Glassfish - Enterprise Java Beans}
|
||||
\section{Glassfish - Enterprise Kirsten.Ritzmann@gmx.netJava Beans}
|
||||
\label{sec:basics:ejb}
|
||||
|
||||
In den Java"=EE"=Anwendungen wird der \textit{Persistenzkontext} für die Anfragen vom \textit{Application"=Server}
|
||||
|
|
|
|||
|
|
@ -8,24 +8,6 @@ freigegeben ist. Zum einen werden die aktuelle Mitarbeiter befragt, zu anderen w
|
|||
überprüft. Danach wird die Anwendung an sich untersucht und zum Schluss wird eine Neuentwicklung mit Hilfe anderer
|
||||
Frameworks diskutiert.
|
||||
|
||||
\section{Aufbau der Umfrage}
|
||||
\label{sec:concept:poll}
|
||||
|
||||
Die Umfrage wird per Email an die \mytodos{XX} Personen verschickt. Als Basis für die Umfrage wird der aktuelle Prototyp
|
||||
unter \href{https://briefedition.wedekind.h-da.de} verwendet. Hierbei wird die gleiche Umfrage für Bearbeiter
|
||||
und Benutzer versendet.
|
||||
|
||||
Die erste Frage ist zur Unterscheidung ob die Antworten von einen Bearbeiter oder von einem Benutzer kommt. Dies ist
|
||||
nur notwendig, um bei der Nachstellung zu unterscheiden welche Zugriffsrechte aktiv sind und diese zu unterschiedlichen
|
||||
Performance-Problemen führt.
|
||||
|
||||
Die weiteren Fragen sind aufeinander aufgebaut. Hierbei wird zuerst überprüft, bei welchen Aktionen eine längere
|
||||
Wartezeit auftritt. Zusätzlich soll noch dazu angegeben werden, wie häufig dies auftritt, also ob dies regelmässig
|
||||
auftritt oder immer nur zu bestimmten Zeitpunkten. Des Weiteren wird die Information nachgefragt, ob die Probleme
|
||||
immer bei der gleichen Abfolge von Aktionen auftritt, oder die vorherigen Aktionen irrelevant sind.
|
||||
|
||||
Die Umfrage wird im Anhang \ref{ap:opinion-poll} dargestellt.
|
||||
|
||||
\section{Allgemeine Betrachtung des Systems}
|
||||
\label{sec:concept:viewsystem}
|
||||
|
||||
|
|
@ -59,9 +41,40 @@ zwischengespeichert werden kann und daher diese Daten immer wieder direkt von de
|
|||
\section{Untersuchung der Anwendung}
|
||||
\label{sec:concept:softwarestructure}
|
||||
|
||||
Bei der Performance-Untersuchung der Anwendung, wird sich im ersten Schritt auf die Dokumentenliste beschränkt. Anhand
|
||||
dieser können die Optimierungen getestet und überprüft werden. Im Nachgang können die daraus gewonnen Kenntnisse auf
|
||||
die anderen Abfragen übertragen werden.
|
||||
|
||||
Die Dokumentenliste zeigt direkte und indirekte Informationen zu einem Dokument an. Hierzu gehört die Kennung des
|
||||
Dokumentes, das Schreibdatum, der Autor, der Adressat, der Schreibort und die Korrespondenzform. Nach jeder dieser
|
||||
Information kann der Bediener die Liste auf"= oder absteigend sortieren lassen. Zusätzlich wird die Liste immer nach
|
||||
dem Schreibdatum sortiert, um die Ergebnisse bei gleichen Werten der zu sortierenden Informationen, wie dem Schreibort,
|
||||
immer in einer chronologisch aufsteigenden Form zu darzustellen.
|
||||
|
||||
Aktuell verwenden die Editoren die Dokumentenliste um die Briefe eines Adressaten zu filtern und diese in
|
||||
chronologische Reihenfolge aufzulisten und zu untersuchen wie Kommunikation zwischen den Wedekind und dem Adressat
|
||||
abgelaufen ist. Ebenso wird nach Standorten sortiert, um zu prüfen mit welchen Personen sich an den ...
|
||||
|
||||
\mytodos{Hier noch mehr INfos dazu, für was genau die Editoren diese tun}
|
||||
|
||||
Da die Daten in der 3. Normalform in der Datenbank gespeichert werden, sind einige Relationen für die Abfragen
|
||||
notwendig. Dies wird durch die generische Abfrage in \autoref{lst:documentlist} gezeigt. Zusätzlich wird für jedes
|
||||
dargestellte Dokument eine zusätzliche Abfrage durchgeführt, die in \autoref{lst:documentlist_sub} zeigt, dass auch hier
|
||||
weitere Relationen notwendig sind.
|
||||
|
||||
\includecode[SQL]{chapters/thesis/chapter03_documentlist.sql}{lst:documentlist}{Generische Abfrage der Dokumentenliste}
|
||||
\includecode[SQL]{chapters/thesis/chapter03_documentlist_sub.sql}{lst:documentlist_sub}{Sub-Abfrage pro Dokument}
|
||||
|
||||
Nach aktuellem Stand beinhaltet die Datenbank ca. 5400 Briefe, für die jeweils 2-7 eingescannte Faksimile gespeichert
|
||||
werden. Diese Graphik-Dateien werden im TIFF-Format abgespeichert und benötigen zwischen 1 und 80 MB Speicherplatz.
|
||||
Dadurch kommt die Datenbank aktuell auf ca. 3,8 GB.
|
||||
|
||||
\mytodos{Die unteren Punkte nochmal untergliedern in Performance-messen und Statistiken prüfen, dann kann mit den
|
||||
Performance-messen die unterschiedlichen Aktionen durchgeführt werden in Kapitel 4}
|
||||
|
||||
Wie im Kapitel \ref{ch:basics} dargestellt, besteht die eigentliche Anwendung aus mehreren Schichten. Die
|
||||
PostgreSQL"=Schicht wurde schon im vorherigen Kapitel betrachtet. Daher gehen wir nun weiter nach in den Schichten vom
|
||||
Glassfish"=Server.
|
||||
PostgreSQL"=Schicht wurde schon im vorherigen Kapitel betrachtet. Daher gehen wir nun weiter nach oben in den Schichten
|
||||
vom Glassfish"=Server.
|
||||
|
||||
Die OpenJPA Cache Schicht wird nun einzeln untersucht. Hierfür werden die zuerst die Cache"=Statistik für Object"=Cache
|
||||
und Query"=Cache aktiviert \citep[315]{MüllerWehr2012}. Die somit erfassten Werte, werden über eine Webseite
|
||||
|
|
@ -88,9 +101,9 @@ emf.getCache().print();
|
|||
% \mytodos{\url{https://eclipse.dev/eclipselink/api/2.1/org/eclipse/persistence/jpa/JpaCache.html#getObject(java.lang.Class,%20java.lang.Object)}}
|
||||
|
||||
Die Schicht \ac{EJB} besitzt keine Möglichkeit um eine sinnvolle Messung durchzuführen, daher wird hierfür keine
|
||||
weiteren Messungen eingefügt.
|
||||
direkte Messungen eingefügt.
|
||||
|
||||
Bei den \ac{JSP} wird eine Zeitmessung eingefügt. Hierfür müssen die Seiten so erweitert werden, dass zum einen die
|
||||
Bei den \ac{JSF} wird eine Zeitmessung eingefügt. Hierfür müssen die Seiten so erweitert werden, dass zum einen die
|
||||
Zeit gemessen wird um die Daten zu ermitteln. Zum anderen wird die Zeit gemessen wie lange es dann noch dauert um die
|
||||
Seite mit den Daten zu rendern um diese an den Client auszuliefern. Diese 2 Zeiten sollen dann im Footer direkt auf der
|
||||
Seite mit dargestellt werden. Somit kann der Benutzer auch direkt sehen, wenn das laden länger gedauert hat, an welcher
|
||||
|
|
@ -100,6 +113,8 @@ Zum Schluss soll die gesamte Anwendung noch automatisiert getestet werden. Hierf
|
|||
automatisiert alle URLs der Webseite mehrfach abfragt. Die Dauer der Aufrufe der Webseiten werden gemessen und
|
||||
statistisch ausgewertet. Für einen späteren Vergleich werden diese Informationen gesichert und mit einem erneuten Aufruf
|
||||
nach den Optimierungen verglichen. Hierdurch kann auch festgestellt werden, ob die Optimierungen erfolgreich waren.
|
||||
Um die Netzwerklatenz ignorieren zu können, wird das Skript auf dem gleichen Computer aufgerufen, auf dem die Webseite
|
||||
gestartet wurde.
|
||||
Das zugehörige Script ist im Anhang \ref{ap:timing} angehängt.
|
||||
|
||||
\section{Vergleich mit anderen Technologien}
|
||||
|
|
@ -108,13 +123,13 @@ Das zugehörige Script ist im Anhang \ref{ap:timing} angehängt.
|
|||
\mytodos{Noch tiefer eingehen?}
|
||||
|
||||
Damit eine Umsetzung auf eine andere Technologie umgestellt werden kann, muss dies den kompletten Technologie"=Stack
|
||||
besitzen, wie dies von der \ac{JSP} unterstützt wird. Daher fallen reine FrontEnd"=Bibliotheken wie VueJS oder React aus
|
||||
besitzen, wie dies von der \ac{JSF} unterstützt wird. Daher fallen reine FrontEnd"=Bibliotheken wie VueJS oder React aus
|
||||
der Betrachtung heraus, da sie zusätzlich noch einen Backend für die Anwendungslogik (englisch business logic) benötigt.
|
||||
|
||||
\subsection{C\# - ASP.NET Core MVC}
|
||||
\label{sec:concept:technologiecompare:aspnetcore}
|
||||
|
||||
Beim Vergleich zu \ac{JSP} steht ASP.NET Core MVC in nichts nach. Im großen und ganzen ist der Funktionsumfang der
|
||||
Beim Vergleich zu \ac{JSF} steht ASP.NET Core MVC in nichts nach. Im großen und ganzen ist der Funktionsumfang der
|
||||
gleiche und mit dem EntityFramework gibt es ebenfalls einen sehr mächtigen \ac{ORM}. Hierbei wird die Programmierung anhand
|
||||
des \ac{MVC}"=Entwurfsmuster implementiert \citep{AspNetCore:2024:MVC}. Dieses Muster erleichtert die Trennung der
|
||||
Benutzeranforderungen, welche durch die Controller mithilfe der Modelle abgearbeitet werden, von der Bedienoberfläche,
|
||||
|
|
|
|||
61
chapters/thesis/chapter03_documentlist.sql
Normal file
61
chapters/thesis/chapter03_documentlist.sql
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
SELECT DISTINCT
|
||||
-- document
|
||||
t0.id, t0.createdat, t0.modifiedat, t0.validuntil, t0.envelope_id
|
||||
, t0.firstprint_id, t0.followsdocument_id, t0.iscomplete
|
||||
, t0.isdispatched, t0.ispublishedindb, t0.isreconstructed
|
||||
, t0.location_id, t0.numberofpages, t0.numberofsheets
|
||||
, t0.parentdocument_id, t0.reviewer_id, t0.signature, t0.bequest_id
|
||||
, t0.city_id, t0.documentcategory, t0.documentcontentteibody
|
||||
, t0.datetype, t0.enddatestatus, t0.endday, t0.endmonth, t0.endyear
|
||||
, t0.startdatestatus, t0.startday, t0.startmonth, t0.startyear
|
||||
, t0.documentdelivery_id, t0.documentid, t0.documentstatus
|
||||
-- historical person
|
||||
, t4.id, t4.createdat, t4.modifiedat, t4.validuntil, t4.firstname
|
||||
, t4.surname, t4.title, t4.birthdatetype, t4.birthstartdatestatus
|
||||
, t4.birthstartday, t4.birthstartmonth, t4.birthstartyear
|
||||
, t4.birthendstatus, t4.birthendday, t4.birthendmonth, t4.birthendyear
|
||||
, t4.deathdatetype, t4.deathstartdatestatus, t4.deathstartday
|
||||
, t4.deathstartmonth, t4.deathstartyear, t4.deathendstatus
|
||||
, t4.deathendday, t4.deathendmonth, t4.deathendyear, t4.dnbref
|
||||
, t4.gender, t4.isinstitution, t4.personid, t4.pseudonym, t4.wikilink
|
||||
-- extended biography
|
||||
, t5.id, t5.createdat, t5.modifiedat, t5.validuntil
|
||||
-- sitecity birth
|
||||
, t6.id, t6.createdat, t6.modifiedat, t6.validuntil
|
||||
, t6.extendedbiography_id, t6.city, t6.country, t6.dnbref, t6.region
|
||||
, t6.sitecityid, t6.wikilink, t6.zipcode
|
||||
-- sitecity death
|
||||
, t7.id, t7.createdat, t7.modifiedat, t7.validuntil
|
||||
, t7.extendedbiography_id, t7.city, t7.country, t7.dnbref, t7.region
|
||||
, t7.sitecityid, t7.wikilink, t7.zipcode
|
||||
-- sitecity
|
||||
, t8.id, t8.createdat, t8.modifiedat, t8.validuntil
|
||||
, t8.extendedbiography_id, t8.city, t8.country, t8.dnbref, t8.region
|
||||
, t8.sitecityid, t8.wikilink, t8.zipcode
|
||||
-- appuser
|
||||
, t9.id, t9.createdat, t9.modifiedat, t9.validuntil, t9.activated
|
||||
, t9.emailaddress, t9.firstname, t9.institution, t9.lastlogindate
|
||||
, t9.loggedin, t9.loggedinsince, t9.loginname, t9.password
|
||||
, t9.registrationdate, t9.salt, t9.surname, t9.title
|
||||
-- appuserrole
|
||||
, t10.id, t10.createdat, t10.modifiedat, t10.validuntil
|
||||
, t10.description, t10.userrole
|
||||
FROM public.Document t0
|
||||
LEFT OUTER JOIN public.DocumentCoAuthorPerson t1 ON t0.id = t1.document_id
|
||||
LEFT OUTER JOIN public.DocumentAddresseePerson t2 ON t0.id = t2.document_id
|
||||
LEFT OUTER JOIN public.historicalperson t3 ON t0.authorperson_id = t3.id
|
||||
LEFT OUTER JOIN public.historicalperson t4 ON t0.authorperson_id = t4.id
|
||||
LEFT OUTER JOIN public.sitecity t8 ON t0.city_id = t8.id
|
||||
LEFT OUTER JOIN public.appuser t9 ON t0.editor_id = t9.id
|
||||
LEFT OUTER JOIN public.extendedbiography t5 ON t4.extendedbiography_id = t5.id
|
||||
LEFT OUTER JOIN public.sitecity t6 ON t4.sitecity_birth_id = t6.id
|
||||
LEFT OUTER JOIN public.sitecity t7 ON t4.sitecity_death_id = t7.id
|
||||
LEFT OUTER JOIN public.appuserrole t10 ON t9.appuserrole_id = t10.id
|
||||
WHERE (t0.validuntil > NOW()
|
||||
AND t0.ispublishedindb = true
|
||||
AND (t1.validuntil > NOW() OR t1.id IS NULL)
|
||||
AND (t2.validuntil > NOW() OR t2.id IS NULL)
|
||||
AND 1 = 1
|
||||
)
|
||||
ORDER BY t0.startyear DESC, t0.startmonth DESC, t0.startday DESC
|
||||
LIMIT 400
|
||||
30
chapters/thesis/chapter03_documentlist_sub.sql
Normal file
30
chapters/thesis/chapter03_documentlist_sub.sql
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
SELECT
|
||||
-- document coauthor person
|
||||
t0.id, t0.createdat, t0.modifiedat, t0.validuntil, t0.document_id
|
||||
, t0.status
|
||||
-- historical person
|
||||
, t1.personid, t1.pseudonym, t1.wikilink, t1.id, t1.createdat
|
||||
, t1.modifiedat, t1.validuntil, t1.comments, t1.firstname, t1.surname
|
||||
, t1.title, t1.birthdatetype, t1.birthstartdatestatus
|
||||
, t1.birthstartday, t1.birthstartmonth, t1.birthstartyear
|
||||
, t1.birthendstatus, t1.birthendday, t1.birthendmonth, t1.birthendyear
|
||||
, t1.deathdatetype, t1.deathstartdatestatus, t1.deathendstatus
|
||||
, t1.deathstartday, t1.deathstartmonth, t1.deathstartyear
|
||||
, t1.deathendday, t1.deathendmonth, t1.deathendyear
|
||||
, t1.dnbref, t1.gender, t1.isinstitution
|
||||
-- extended biography
|
||||
, t2.id, t2.createdat, t2.modifiedat, t2.validuntil, t2.description
|
||||
-- sitecity birth
|
||||
, t3.id, t3.createdat, t3.modifiedat, t3.validuntil
|
||||
, t3.extendedbiography_id, t3.city, t3.country, t3.dnbref, t3.region
|
||||
, t3.sitecityid, t3.wikilink, t3.zipcode
|
||||
-- sitecity death
|
||||
, t4.id, t4.createdat, t4.modifiedat, t4.validuntil
|
||||
, t4.extendedbiography_id, t4.city, t4.country, t4.dnbref, t4.region
|
||||
, t4.sitecityid, t4.wikilink, t4.zipcode
|
||||
FROM public.DocumentCoAuthorPerson t0
|
||||
LEFT OUTER JOIN public.historicalperson t1 ON t0.authorperson_id = t1.id
|
||||
LEFT OUTER JOIN public.extendedbiography t2 ON t1.extendedbiography_id = t2.id
|
||||
LEFT OUTER JOIN public.sitecity t3 ON t1.sitecity_birth_id = t3.id
|
||||
LEFT OUTER JOIN public.sitecity t4 ON t1.sitecity_death_id = t4.id
|
||||
WHERE t0.document_id = ?
|
||||
|
|
@ -2,29 +2,63 @@
|
|||
\chapter{Performance-Untersuchung}
|
||||
\label{ch:performance-checking}
|
||||
|
||||
\section{Auswertung der Umfrage}
|
||||
\label{sec:performance-checking:poll}
|
||||
|
||||
% Auswerten ob es einen Zusammenhang zwischen bestimmten Zeiten gibt oder ob es
|
||||
% eine bestimmte Reihenfolge gibt, bei der die Probleme auftreten
|
||||
|
||||
\section{Auswertung des Systems}
|
||||
\label{sec:performance-checking:system}
|
||||
|
||||
% Hier die Auswertung des Produktionsservers unterbringen
|
||||
|
||||
\section{Einbau und Aktivieren von Performance-Messung}
|
||||
\label{sec:performance-checking:performance-measure}
|
||||
|
||||
%
|
||||
\mytodos{Hier die Auswertung des Produktionsservers unterbringen}
|
||||
|
||||
\section{Statistiken im PostgreSQL auswerten}
|
||||
\label{sec:performance-checking:postgresql-statistics}
|
||||
|
||||
% Logs auswerten, am besten vom Produktionsserver. Ebenfalls sollte man die Webseite
|
||||
% prüfen, die den Cache von OpenJPE auswerten
|
||||
\mytodos{Logs auswerten, am besten vom Produktionsserver. Ebenfalls sollte man die Webseite
|
||||
prüfen, die den Cache von OpenJPE auswerten}
|
||||
|
||||
\section{Überprüfung des PostgreSQL und Servers}
|
||||
\label{sec:performance-checking:postgresql-checking}
|
||||
|
||||
% Konfiguration vom Produktionsserver prüfen
|
||||
\mytodos{Konfiguration vom Produktionsserver prüfen}
|
||||
|
||||
\section{Einbau und Aktivieren von Performance-Messung}
|
||||
\label{sec:performance-checking:performance-measure}
|
||||
|
||||
\mytodos{Einbau der Messungen direkt in die Webseite bzw. in ein Log}
|
||||
|
||||
\section{Untersuchung der Anwendung}
|
||||
\label{sec:performance-checking:investigation-application}
|
||||
|
||||
Nun werden die unterschiedlichen Schichten betrachtet und möglichen Performance-Verbesserungen untersucht und deren
|
||||
Vor"= und Nachteile herausgearbeitet.
|
||||
|
||||
\subsection{Caching im PostgreSQL}
|
||||
\label{sec:performance-checking:investigation-application:caching-postgresql}
|
||||
|
||||
\subsection{Caching im OpenJPA}
|
||||
\label{sec:performance-checking:investigation-application:caching-openjpa}
|
||||
|
||||
\subsection{Caching im \ac{JPA}}
|
||||
\label{sec:performance-checking:investigation-application:caching-jpa}
|
||||
|
||||
\subsection{Caching in \ac{EJB}}
|
||||
\label{sec:performance-checking:investigation-application:caching-ejb}
|
||||
|
||||
\subsection{Abfragen Native}
|
||||
\label{sec:performance-checking:investigation-application:query-native}
|
||||
|
||||
\subsection{Abfragen JPQL}
|
||||
\label{sec:performance-checking:investigation-application:query-jpql}
|
||||
|
||||
\subsection{Abfragen Criteria API}
|
||||
\label{sec:performance-checking:investigation-application:query-criteria-api}
|
||||
|
||||
\subsection{materialized views}
|
||||
\label{sec:performance-checking:investigation-application:materialized-views}
|
||||
|
||||
\subsection{cached queries}
|
||||
\label{sec:performance-checking:investigation-application:cached-query}
|
||||
|
||||
\subsection{Umgestalten der Datenbanktabellen}
|
||||
\label{sec:performance-checking:investigation-application:new-table}
|
||||
|
||||
\subsection{Verkleinerung der Abfragen}
|
||||
\label{sec:performance-checking:investigation-application:smaller-query}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
|
||||
\chapter{Optimierung}
|
||||
\chapter{???Optimierung???}
|
||||
\label{ch:optimizing}
|
||||
|
||||
\mytodos{Muss noch entsprechend der Auswertungen aus der Performance-Untersuchungen angeapasst werden}
|
||||
|
||||
\section{Ermittlung der Performance-Probleme}
|
||||
\label{sec:optimizing:performance}
|
||||
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
\chapter{Evaluierung}
|
||||
\label{ch:evaluation}
|
||||
|
||||
\mytodos{Hier noch darauf verweisen, dass eine Befragung unter den Benutzer und Entwickler nicht zielführend gewesen wäre, da zu wenige Anwender, 4 Stück}
|
||||
|
||||
\section{Befragung der Benutzer und Entwickler}
|
||||
\mytodos{Hier noch darauf verweisen, dass eine Befragung unter den Benutzer und Entwickler nicht zielführend gewesen wäre, da zu wenige Anwender, 4 Stück,
|
||||
daher ist der rein technische Ansatz die einzige sinnvolle Wahl}
|
||||
\mytodos{Zusätzlich beschreiben welche Möglichkeiten man genau genutzt hat und warum bzw. warum nicht}
|
||||
|
||||
\section{Erneute Laufzeitanalyse starten}
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
% Insert your acronyms here (Das Kürzel mit der längsten Bezeichnung sollte in den eckigen Klammern eingetragen werden)
|
||||
\begin{acronym}[API]
|
||||
\acro{EJB}{Enterprise Java Beans}
|
||||
\acro{JSP}{Java Server Page}
|
||||
\acro{JSF}{Java Server Faces}
|
||||
\acro{ORM}{Object Relational Mapping}
|
||||
\acro{MVC}{Model-View-Controller}
|
||||
\acro{HTML}{HyperText Markup Language}
|
||||
|
|
|
|||
|
|
@ -50,8 +50,9 @@
|
|||
%\PassOptionsToPackage{spanish,es-lcroman}{babel}
|
||||
\usepackage{babel}
|
||||
|
||||
% Damit dies Funktioniert, muss in der "classicthesis.sty" die Zeile 153 einkommentiert werden, damit der Fehler "Black ist nicht bekannt" mehr auftritt
|
||||
% Damit dies Funktioniert, muss in der "classicthesis.sty" die Zeile 153 einkommentieren, damit der Fehler "Black ist nicht bekannt" mehr auftritt
|
||||
\usepackage{pgfplots} % External TikZ/PGF support (thanks to Andreas Nautsch)
|
||||
\pgfplotsset{compat=1.18}
|
||||
\usetikzlibrary{external,shapes.geometric, arrows, fit, arrows.meta}
|
||||
% Notwendig, damit die Fehlermeldung "Black ist nicht bekannt" gelöst ist
|
||||
% Kopiert aus "classicthesis.sty" - Zeile 153
|
||||
|
|
|
|||
BIN
thesis.pdf
BIN
thesis.pdf
Binary file not shown.
|
|
@ -94,7 +94,7 @@
|
|||
%\renewcommand{\thechapter}{\alph{chapter}}
|
||||
\cleardoublepage
|
||||
\part{Appendix}
|
||||
\include{chapters/thesis/appendix01}
|
||||
%\include{chapters/thesis/appendix01}
|
||||
\include{chapters/thesis/appendix02}
|
||||
%\include{chapters/examples/appendix02}
|
||||
%*************************************************************************
|
||||
|
|
@ -135,7 +135,7 @@
|
|||
% 2. Bei Before Lunch "Build artifact" hinzufügen und "WedekindJSF.war" auswählen
|
||||
% 3. Unter Deployment "Artifact" "WedekindJSF.war" hinzufügen
|
||||
|
||||
% Konfiguration Glassfisch/Payara (Muss scheinbar nach jedem neustart des Rechners gemacht werden)
|
||||
% Konfiguration Glassfish/Payara (Muss scheinbar nach jedem neustart des Rechners gemacht werden)
|
||||
% 1. Payara-Server starten, damit man an die Admin-Oberfläche kommt unter http://localhost:4848/
|
||||
% 2. Unter Ressources\JDBC\JDBC Connection Pools einen neuen Anlegen:
|
||||
% 2.1. Poolname vergeben
|
||||
|
|
|
|||
Loading…
Reference in a new issue