Anul 3 Semestrul 2

Anul 3/Semestrul 2/Licenta/Thesis/chapters/chapter6.tex

@@ -0,0 +1,83 @@
+\chapter{Results and Discussion}
+\label{chap:results}
+
+To rigorously validate the sustained performance and stability of the architecture, a 30-minute load test was conducted against the InventoryService. The test, orchestrated by Locust \cite{locust2025load}, simulated a continuous load of 10 concurrent users (\ref{fig:number_of_users}) making GET requests to the /inventory endpoint. The health and resource consumption of the service were closely monitored throughout the test using Grafana dashboards populated with data from Prometheus.
+
+
+\subsection{Results}
+\par The 30-minute sustained load test yielded the following key performance indicators from Locust:
+
+\begin{itemize}
+
+\item Requests per Second (RPS): After an initial ramp-up, the system achieved and maintained a remarkably stable throughput, averaging approximately 124 RPS. This rate was held consistently for the entire 30-minute duration, demonstrating the service's ability to handle a continuous load without degradation. Figure \ref{fig:rps}
+
+\begin{figure}
+\centering
+\includegraphics[width=0.8\textwidth]{figures/rps.png}
+\caption{Requests per Second (RPS) during the 30-minute load test.}
+\label{fig:rps}
+\end{figure}
+
+\item Response Times: The service exhibited excellent and predictable latency. The median (50th percentile) response time was stable at approximately 35ms, while the 95th percentile response time held steady at around 50ms. The absence of any upward trend in response times over the 30-minute period confirms the efficiency of the service. Figure \ref{fig:response_time}
+
+\begin{figure}
+\centering
+\includegraphics[width=0.8\textwidth]{figures/response_time.png}
+\caption{Response times during the 30-minute load test, showing median and 95th percentile latencies.}
+\label{fig:response_time}
+\end{figure}
+
+\item Failures: The system demonstrated high reliability, with zero failures recorded across the entire 30-minute test. This 100\% success rate under sustained load confirms the robustness of the service.
+
+\begin{figure}
+\centering
+\includegraphics[width=0.8\textwidth]{figures/number_of_users.png}
+\caption{Number of users during the 30-minute load test, showing a stable count of 10 concurrent users.}
+\label{fig:number_of_users}
+\end{figure}
+
+
+\end{itemize}
+
+The Grafana dashboard, capturing a 30-minute window, provided crucial insights into the behavior of the InventoryService pod within Kubernetes:
+
+\begin{itemize}
+
+
+\item CPU Usage: At the start of the test, the CPU usage of the primary inventoryservice pod rapidly climbed from its idle state to its configured limit of 0.20 cores (200m). The pod sustained this level of maximum CPU utilization for the entire test period.Figure \ref{fig:cpu_usage}
+
+\begin{figure}
+\centering
+\includegraphics[width=0.8\textwidth]{figures/cpu_usage.png}
+\caption{CPU usage of the InventoryService pod during the 30-minute load test, showing sustained maximum utilization.}
+\label{fig:cpu_usage}
+\end{figure}
+
+\item Memory Usage: Memory consumption remained exceptionally stable at approximately 97 MB. The graph shows a flat line, indicating no memory leaks or gradual resource exhaustion over the extended test duration. Figure \ref{fig:memory_usage}
+
+\begin{figure}
+\centering
+\includegraphics[width=0.8\textwidth]{figures/memory_usage.png}
+\caption{Memory usage of the InventoryService pod during the 30-minute load test, showing stable memory consumption.}
+\label{fig:memory_usage}
+\end{figure}
+
+\end{itemize}
+
+\subsection{Discussion}
+The results from this 30-minute load test provide strong evidence of the InventoryService's stability, performance, and the effectiveness of its cloud-native design.
+
+Sustaining 124 RPS with a median latency of 35ms for 30 minutes is a significant achievement. It proves that the service is not only fast but also efficient, without performance degradation over time. The flat memory usage graph is particularly noteworthy, as it confirms the absence of memory leaks, a common issue that plagues long-running services and often leads to crashes.
+
+The most critical insight is the interplay between the application's performance and the Kubernetes orchestration layer. The CPU utilization for the single inventoryservice pod was consistently pegged at its limit. This behavior under sustained load validates two core architectural tenets:
+
+\begin{enumerate}
+
+
+\item The Service is CPU-Bound: The performance of the service under this workload is primarily constrained by its available processing power. This is a predictable and desirable behavior, as it means performance can be directly influenced by resource allocation.
+
+\item Validation of the Horizontal Scaling Trigger: The Horizontal Pod Autoscaler (HPA) is configured to provision a new pod when the average CPU utilization exceeds 80\%. Since the pod's CPU was held at nearly 100\% of its limit, it continuously met the condition for scaling out. This test proves that under a real-world scenario with increasing load, the HPA would be correctly triggered to horizontally scale the service. This ensures the system can elastically adapt to demand, maintaining low response times by distributing the load across multiple instances.
+
+\end{enumerate}
+
+In summary, the 30-minute endurance test demonstrates more than just performance; it confirms the system's operational stability and resilience. The InventoryService has proven to be a robust, efficient, and well-behaved component of the architecture, whose behavior under load validates the core principles of the automated horizontal scaling strategy designed to ensure high availability and a seamless user experience.