162 lines
No EOL
6.7 KiB
TeX
162 lines
No EOL
6.7 KiB
TeX
|
|
\chapter{Konzept}
|
|
\label{ch:concept}
|
|
|
|
\section{Aufbau der Umfrage}
|
|
\label{sec:concept:poll}
|
|
|
|
|
|
Die Umfrage wird über 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}
|
|
|
|
% Untersuchung des Servers
|
|
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, 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.
|
|
|
|
\mytodos{Bespreibung der untersuchung von Glassfisch? oder lieber später}
|
|
|
|
\section{Das Vorgehen der Optimierung}
|
|
\label{sec:concept:optimizing}
|
|
|
|
\mytodos{Beschreibung der Untersuchung von Glassfisch? oder lieber später, oder doch eher umbennen in Ermittlung der Performance-Probleme}
|
|
|
|
% 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 erkentnis mss dann der Lösungsweg beschritten werden
|
|
% Beachten des Speicherverbrauchs!
|
|
|
|
\section{Aktueller Aufbau der Software}
|
|
\label{sec:concept:softwarestructure}
|
|
|
|
% Hier vielleicht nochmal ein Verweis auf die Grundlagen, oder direkt auf die MVC-Technik
|
|
|
|
\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}
|
|
\label{sec:concept:technologiecompare:aspnetcore}
|
|
|
|
\mytodos{Anpassen auf "Kernpunkte"?}
|
|
|
|
\noindent
|
|
Vorteile:
|
|
|
|
\begin{itemize}
|
|
\item Gute Entwicklungsumgebung
|
|
\item EntityFramework als \ac{ORM}
|
|
\item Große Auswahl an Erweiterungen durch NuGet-Pakete
|
|
\item Betriebssystem unabhängig
|
|
\end{itemize}
|
|
|
|
\noindent
|
|
Nachteile:
|
|
|
|
\begin{itemize}
|
|
\item
|
|
\end{itemize}
|
|
|
|
Beim Vergleich zu \ac{JSP} steht ASP.NET Core nicht hinten an. Im großen und ganzen ist der Funktionsumfang der gleiche
|
|
und mit EntityFramework gibt es ebenfalls einen sehr mächtigen \ac{ORM}. Hier sehe ich nur ebenfalls ein ähnliches
|
|
Problem beim Caching wie bei OpenJPA, dass diese zu Problemen führen kann, wenn der Speicher voll wird.
|
|
% Ersatz für EF?
|
|
|
|
C\# wird ebenfalls wie Java in einen Zwischencode übersetzt und erst bei der Ausführung auf die Zielplattform übersetzt.
|
|
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}
|
|
|
|
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. |