164 lines
No EOL
8.5 KiB
TeX
164 lines
No EOL
8.5 KiB
TeX
|
|
\chapter{Konzept}
|
|
\label{ch:concept}
|
|
|
|
Das folgende Kapitel enthält die im Rahmen dieser Arbeit entstandenen Konzepte, um die aktuellen Probleme aufzuzeigen.
|
|
Hierbei sind verschiedene Vorgehen zu verwenden, da die Anwendung aktuell noch nicht als produktive Anwendung
|
|
freigegeben ist. Zum einen werden die aktuelle Mitarbeiter befragt, zu anderen wird der Produktionsserver selbst
|
|
ü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 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.
|
|
|
|
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.
|
|
|
|
Die Anfrage wird im Anhang \ref{ch:Umfrage} dargestellt.
|
|
|
|
\section{Allgemeine Betrachtung des Systems}
|
|
\label{sec:concept:viewsystem}
|
|
|
|
Für die Untersuchung des Systems wird der direkte Zugang zum Server benötigt. Hierbei werden zuerst die im Kapitel
|
|
\ref{sec:basics:services} beschriebenen Einstellungen überprüft.
|
|
|
|
Zuerst wird am PostgreSQL"=Server die Konfiguration der Speicher mit der Vorgabe für Produktivsystem abgeglichen.
|
|
Hierunter fallen die Einstellungen für die \textit{shared\_buffers}, der bei einem Arbeitsspeicher von mehr als 1 GB
|
|
ca. 25\% des Arbeitsspeicher definiert sein soll \cite{PostgresC20.4:2024}.
|
|
|
|
\mytodos{die anderen Speicher abarbeiten?}
|
|
|
|
Dann wird mit dem Systemtools, wie den Konsolenanwendungen \textit{htop} und \textit{free}, die Auslastung des Servers
|
|
überprüft. Hierbei ist die CPU-Leistung, der aktuell genutzte Arbeitsspeicher, sowie die Zugriffe auf die Festplatte
|
|
die wichtigen Faktoren zur Bewertung.
|
|
|
|
Die CPU-Leistung sollte im Schnitt nicht die 70\% überschreiten, für kurze Spitzen wäre dies zulässig. Da sonst der
|
|
Server an seiner Leistungsgrenze arbeitet und dadurch es nicht mehr schafft die gestellten Anfragen schnell genug
|
|
abzuarbeiten.
|
|
|
|
Da unter Linux der Arbeitsspeicher nicht mehr direkt freigegeben wird, ist hier die Page-Datei der wichtigere Indikator.
|
|
Wenn dieses in Verwendung ist, dann benötigt die aktuell laufenden Programme mehr Arbeitsspeicher als vorhanden ist,
|
|
wodurch der aktuell nicht verwendete in die Page-Datei ausgelagert wird. Hierdurch erhöhen sich die Zugriffszeiten auf
|
|
diese Elemente drastisch.
|
|
|
|
Die Zugriffsgeschwindigkeit, die Zugriffszeit sowie die Warteschlange an der Festplatte zeigt deren Belastungsgrenze auf.
|
|
Hierbei kann es mehrere Faktoren geben. Zum einem führt das Paging des Arbeitsspeicher zu erhöhten Zugriffen. Ein zu
|
|
klein gewählter Cache oder gar zu wenig Arbeitsspeicher erhöhen die Zugriffe auf die Festplatte, da weniger
|
|
zwischengespeichert werden kann und daher diese Daten immer wieder direkt von der Festplatte geladen werden müssen.
|
|
|
|
\section{Untersuchung der Anwendung}
|
|
\label{sec:concept:softwarestructure}
|
|
|
|
Wie im Kapitel \ref{ch:basics} dargestellt, besteht die eigentliche Anwendung aus mehreren Schichten. Hierbei ist jede
|
|
Schicht einzeln aber auch im ganze zu betrachten.
|
|
|
|
\mytodos{angenfangen bei jeder Schicht, kurz beschreiben und was da getan wird um dort etws zu untersuchen}
|
|
|
|
\mytodos{Zum enden dann den gesammten Server untersucht, durch automatisiert Test über shell-Skripte die jede Seite mehrfach
|
|
aufrufen und die Messung dazu protokolieren sowie die min und max werte (Skript als Listening in den Anhang?)}
|
|
|
|
% Anhand der Umfragen werden die verschiedenen Seiten ermittelt und mit den Tools überprüft
|
|
% Während dessen kann über ein Script die Seite automatisiert abgefragt und das Trace aktiv sind
|
|
% je nach Erkenntnis muss dann der Lösungsweg beschritten werden
|
|
% Beachten des Speicherverbrauchs!
|
|
|
|
\section{Vergleich mit anderen Technologien}
|
|
\label{sec:concept:technologiecompare}
|
|
|
|
% Vergleich mit AspNetCore und vielleicht VueJS oder Konsorten, wobei hier der Serverteil fehlt
|
|
|
|
Damit eine Umsetzung mit einer anderen Technologie umgesetzt werden kann, muss dies den kompletten Aufbau unterstützen,
|
|
wie dies die \ac{JSP} unterstützen. Daher fallen reine FrontEnd"=Bibliotheken wie VueJS oder React aus der Betrachtung
|
|
heraus.
|
|
|
|
\subsection{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
|
|
gleiche und mit 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,
|
|
die hier in der Standardelementen von Webseiten, wie \ac{HTML}, \ac{CSS} und Javascript definiert werden. Zusätzlich
|
|
existiert noch ein spezifischer Syntax um die Daten dynamisch in die Seiten einzufügen.
|
|
|
|
Das System selbst ist in Schichten, auch Middleware genannt, aufgebaut \citep{AspNetCore:2024:Middleware}. Hierbei
|
|
übernimmt jede Middleware ihre entsprechende Aufgabe oder gibt die Anfrage an die nächste Middleware weiter und wartet
|
|
auf deren Antwort um diese and den Client zurückzugeben.
|
|
Diese Konzept wird direkt vom Standard umgesetzt und somit sind die unterschiedlichen Verarbeitungen getrennt
|
|
implementiert worden, was zu besserer Wartbarkeit des Programmcodes führt. Und die eigene Anwendung kann dadurch
|
|
je nach Bedarf die Middleware aktivierten, die wirklich benötigt wird.
|
|
|
|
Zusätzlich können über eine Vielzahl an vorhandenen NuGet-Paketen das Programm erweitert werden. Oder Komponenten
|
|
komplett ersetzt werden, wie z.B. das EntityFramework durch eine einfachere leichtere Version eines reinen \ac{ORM}
|
|
zu ersetzt.
|
|
|
|
C\# ist wie Java durch die neue .NET Runtime, aktuell in der Version 8 verfügbar, für die meisten Betriebssystem verfügbar.
|
|
Bei der Übersetzung hat C\# einen Vorteil gegenüber von Java, da hier der Code wie bei Java zuerst in eine Zwischencode
|
|
\ac{IL} kompiliert wird und zur Laufzeit über einen \ac{JIT} Compiler dann direkt in optimierten Maschinencode übersetzt wird.
|
|
Hierbei haben die meistens Test gezeigt, dass das .NET Framework hier um einiges effizienter und schneller arbeitet als
|
|
die Java Runtime. Zusätzlich wird bei ASP.NET Core nicht noch ein zusätzlicher Server benötigt um die Anwendung aktiv
|
|
zu halten.
|
|
|
|
\subsection{Golang}
|
|
\label{sec:concept:technologiecompare:go}
|
|
|
|
\noindent
|
|
Vorteile:
|
|
|
|
\begin{itemize}
|
|
\item schnelle und einfache Entwicklung
|
|
\item Native Übersetzung der Anwendung (hohe Performance)
|
|
\item Betriebssystem unabhängig
|
|
\item Gut geeignet für Microservices
|
|
\end{itemize}
|
|
|
|
\noindent
|
|
Nachteile:
|
|
|
|
\begin{itemize}
|
|
\item Neue Programmiersprache, noch wenige Programmierer
|
|
\end{itemize}
|
|
|
|
Die grundlegenden Ziele bei der Entwicklung von Go sind eine optimiert und vereinfachte Programmiersprache zu entwickeln.
|
|
Hierdurch ist es sehr einfach und effizient eine Anwendung mit Go zu entwickeln.
|
|
|
|
Schnelle und einfache Entwicklung durch das grundsätzliche Konzept der neuen Sprache
|
|
Ist wiederrum aber der nachteil dass es noch nicht viele können.
|
|
Ist aber wiederrum sehr schnell und effizient und für Microservices gedacht.
|
|
Reiner \ac{ORM} vorhanden, ohne weitere Caching und halten von Daten.
|
|
|
|
\subsection{PHP}
|
|
\label{sec:concept:technologiecmopare:php}
|
|
|
|
\noindent
|
|
Vorteile:
|
|
|
|
\begin{itemize}
|
|
\item Text-Editor reicht
|
|
\end{itemize}
|
|
|
|
\noindent
|
|
Nachteile:
|
|
|
|
\begin{itemize}
|
|
\item Script-Sprache
|
|
\end{itemize}
|
|
|
|
\subsection{Fazit}
|
|
\label{sec:concept:technologiecompare:summary}
|
|
|
|
\mytodos{Noch entscheiden, ob der Compare direkt bei der Technologie gemacht \\ wird, oder allgemein am ende}
|
|
|
|
PHP fällt aufgrund der Script-Sprache raus, da dies nicht verteilbar ist und an den Uni keine Entwickler zu finden sind.
|
|
Bei Go sind es ebenfalls hauptsächlich die nicht vorhandenen Entwickler an der Uni
|
|
ASP.NET Core ist im Vergleich zu JSP identisch, aber auch hier werden aktuell die Entwickler fehlen, da Java in den
|
|
Vorlesungen dran genommen wird. |