\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.