105 lines
4.4 KiB
TeX
105 lines
4.4 KiB
TeX
|
\section{\Glspl{Lasttest}}
|
||
|
|
|
||
|
|
\subsection{Einleitung}
|
||
|
|
|
||
|
|
\Glspl{Lasttest} sind sinnvoll, um das Verhalten eines Programmes unter großer Last
|
||
|
|
zu testen um somit dessen Belastungsgrenze zu erreichen.
|
||
|
|
Dadurch wird das Programm auf Stabilität getestet und man erhält
|
||
|
|
einen Eindruck davon, wie performant das Programm ist.
|
||
|
|
Auch kann durch die erhaltenen Ergebnisse abgeschätzt werden,
|
||
|
|
welche Hardware für den erwarteten Einsatzzweck benötigt wird.
|
||
|
|
|
||
|
|
\subsection{Verwendete Software}
|
||
|
|
|
||
|
|
Da der \Gls{podcast}synchronisationsserver ein Webserver ist und über HTTP
|
||
|
|
kommuniziert, wird das Tool \enquote{Apache JMeter} verwendet, um
|
||
|
|
die \Glspl{Lasttest} durchzuführen.
|
||
|
|
Mit diesem Tool kann mithilfe eines sogenannten Testplans
|
||
|
|
systematisch HTTP Anfragen an den Server gestellt werden.
|
||
|
|
Während dieser Testplan läuft, sammelt das Tool verschiedene Daten über die Performanz des Services,
|
||
|
|
wie zum Beispiel die Anzahl der Anfragen, die pro Sekunde bearbeitet werden.
|
||
|
|
Im Anschluss werden die Testergebnisse grafisch zur Verfügung gestellt.
|
||
|
|
|
||
|
|
\subsection{Tests}
|
||
|
|
Um zu testen, ob der Synchronisationsserver unter voller Belastung
|
||
|
|
fehlerfrei arbeitet, wurden alle Schnittstellen, die die \Gls{podcatcher} zur
|
||
|
|
Synchronisation nutzen, jeweils zum Testplan als eigene Threadgruppe
|
||
|
|
hinzugefügt.
|
||
|
|
Damit ist es möglich, alle relevanten Schnittstellen
|
||
|
|
über einen längeren Zeitraum kontinuierlich zu belasten.
|
||
|
|
So wird ausgeschlossen, dass es innerhalb des Programms zu gegenseitigen
|
||
|
|
Interferenzen kommt, wenn alle Bereiche zur selben Zeit ausgelastet werden.
|
||
|
|
Ein weiterer Vorteil des gleichzeitigen Belastens ist, dass
|
||
|
|
Engpässe, welche das Programm ausbremsen, leichter identifiziert werden können.
|
||
|
|
|
||
|
|
Um einen Performanzvergleich zwischen unterschiedlicher Hardware zu erhalten,
|
||
|
|
wurden die Tests in gleicher Konfiguration einmal auf einem System,
|
||
|
|
welches den im Pflichtenheft definierten Mindestanforderungen
|
||
|
|
(2 Kerne und 2GB RAM) entspricht und
|
||
|
|
einem besseren System (8 Kerne und 32GB RAM) getestet.
|
||
|
|
|
||
|
|
\newpage
|
||
|
|
|
||
|
|
\subsection{Testergebnisse}
|
||
|
|
\subsubsection{Genaue Testwerte}
|
||
|
|
\textit{2-Kern System:}
|
||
|
|
\begin{figure}[h]
|
||
|
|
\centering
|
||
|
|
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{assets/lasttest/minimumSpecsTable.png}
|
||
|
|
\end{figure}
|
||
|
|
|
||
|
|
\textit{8-Kern System:}
|
||
|
|
\begin{figure}[h]
|
||
|
|
\centering
|
||
|
|
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{assets/lasttest/goodSpecsTable.png}
|
||
|
|
\end{figure}
|
||
|
|
|
||
|
|
\subsection{Anfragen pro Sekunde}
|
||
|
|
|
||
|
|
Aus den Testdaten ist ersichtlich, dass die im Pflichtenheft für den Synchronisationsserver
|
||
|
|
als Musskriterium aufgeführte Eigenschaft, 50 Anfragen pro Sekunde bewältigen zu können,
|
||
|
|
nicht für jede Hardwarekonfiguration möglich ist.
|
||
|
|
Denn im Gegensatz zur 8-Kern CPU, welche durchschnittlich 88,93 Transaktionen pro Sekunde
|
||
|
|
verarbeitet, sind mit den Mindestanforderungen durchschnittlich nur 10,85 Anfragen
|
||
|
|
pro Sekunde möglich.
|
||
|
|
|
||
|
|
\newpage
|
||
|
|
\subsubsection{Application Performance Index}
|
||
|
|
|
||
|
|
\textit{2-Kern System:}
|
||
|
|
\begin{figure}[h]
|
||
|
|
\centering
|
||
|
|
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{assets/lasttest/minimumSpecsApdex.png}
|
||
|
|
\end{figure}
|
||
|
|
|
||
|
|
\textit{8-Kern System:}
|
||
|
|
\begin{figure}[h]
|
||
|
|
\centering
|
||
|
|
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{assets/lasttest/goodSpecsApdex.png}
|
||
|
|
\end{figure}
|
||
|
|
|
||
|
|
\newpage
|
||
|
|
|
||
|
|
Der Application Performance Index (kurz: \Gls{Apdex}) gibt an, wie benutzerfreundlich
|
||
|
|
eine Webseite bezüglich ihrer Antwortzeiten bei Anfragen ist.
|
||
|
|
Dabei stellt \enquote{1} die beste Nutzerfreundlichkeit dar und \enquote{0} die schlechteste.
|
||
|
|
|
||
|
|
Verglichen mit den genauen Testwerten, ist ersichtlich, dass ein System mit den Mindestanforderungen zwar eine akzeptable Leistung erbringt, allerdings die vom \Gls{Apdex} definierte Frustrationsgrenze überschreiten kann:
|
||
|
|
|
||
|
|
\textit{2-Kern System:}
|
||
|
|
\begin{figure}[h]
|
||
|
|
\centering
|
||
|
|
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{assets/lasttest/minimumSpecsResponse.png}
|
||
|
|
\end{figure}
|
||
|
|
|
||
|
|
\textit{8-Kern System:}
|
||
|
|
\begin{figure}[h]
|
||
|
|
\centering
|
||
|
|
\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{assets/lasttest/goodSpecsResponse.png}
|
||
|
|
\end{figure}
|
||
|
|
|
||
|
|
Bei Ausführung des Synchronisationsservers auf einem 2-Kern System kann somit
|
||
|
|
keine zufriedenstellende Nutzererfahrung garantiert werden, sobald der Server einer starken
|
||
|
|
Last ausgesetzt ist.
|
||
|
|
|
||
|
|
Um eine zufriedenstellende Erfahrung zu garantieren, ist bessere Hardware eine hinreichende Bedingung.
|