# New Model for Defining and Implementing Performance Tests
## 4 Experiment and Discussion
### Scenario 2
As can be seen in Figure 15, around the 40 th second there is a 10% increase in RAM usage (approximately 13 GB) due to the increase in concurrent connections, but while the overall resource usage on the Moodle machine does not exceed 50%, for the database VM the CPU usage from around the 40 th second is 100% and the disk usage around 75-80% (Figure 16). Figure 14: Report on http client-server communication for test \(t_{0}\) in Scenario 2 (maximum possible CPS). Figure 13: Graph of the number of concurrent connections versus time on e-learning platform. Taking this into account, the \(t_{0}\) test was repeated, but this time limiting the number of generated connections to 400 per second to determine the maximum CPS value at which the server still maintained 100% correct communication. The limit of 400 connections per second was chosen based on the observation that the database VM's CPU usage reached 100% and RAM usage increased significantly during the initial test. By reducing the connection rate, we aimed to identify the threshold at which the server could handle the load efficiently without reaching critical resource limits. Additionally, this approach allowed us to verify whether the performance issues consistently occur above 400 CPS or if this value was an anomaly. Figure 16: Dependence graph of resource load of the virtual machine with the database on time for test \(t_{0}\) in Scenario 2 (maximum possible CPS). Figure 15: Graph of the dependence of the resource load on the Moodle virtual machine on time for test \(t_{0}\) in Scenario 2 (maximum possible CPS). At this point, it should be noted that the \(t_{0}\) test was performed with different call values for the \(g_{1}\) generator, which was defined as TCP/UDP Packet Generators. It is possible to define more precisely the generator used along with its call parameters, e.g., \(g_{6}\)--TCP/UDP Packet Generators (without CPS limit), \(g_{7}\)--TCP/UDP Packet Generators (whit limitations 400 CPS) in which case the test description could be written as follows:  
\[ \begin{array}{c}a_{8}=t_{0}\{L_{1}(g_{6},g_{7}),L_{2}(n_{0}),L_{3}(c_{0},c_{ 3})\}\\ \hskip 14.226378 pt+t_{1}\{L_{1}(g_{1},g_{2}),L_{2}(n_{0}),L_{3}(c_{0},c_{3})\} \\ \hskip 14.226378 pt+t_{2}\{L_{1}(g_{1}),L_{2}(n_{0}),L_{3}(c_{0},c_{3})\}\end{array} \]  
The level of detail in describing a given testing process depends on the requirements defined by the project team. Figure 17 shows a graph of the time dependence of the CPS for the repeated test--400 CPS i.e., as assumed before, while the number of concurrent connections (Figure 18), although lower than in the first test, is still relatively high, which means that the server load is extremely close to saturation of resources and, although 100% correct packet transmission was obtained, there are already delays (hence the relatively high number of concurrent connections). Admittedly, Admittedly, Figure 19 shows a 100% success rate for 250,007 HTTP requests, and an analysis of resource usage on the Moodle virtual machine (see Figure 20) shows that the server still has a significant amount of free computing resources, but Figure 21 also shows that CPU usage on the database VM is fluctuating around 95%. In summary, 400 connections per second is the extreme value that the server is able to handle without packet loss. Figure 19: Report on http client-server communication for test \(t_{0}\) in Scenario 2 (CPS limited to 400). Figure 20: Graph of the dependence of the resource load on the Moodle virtual machine on time for test \(t_{0}\) in Scenario 2 (CPS limited to 400). Test \(t_{2}\). The CC test was performed as the next step. As can be seen in Figure 22, the maximum number of concurrent connections obtained is approximately 2200. RAM consumption increased (Figure 23) by approximately 10 per cent (13 GB), but this is once again significantly lower than expected. Analyzing Figure 24, it can be seen that the CPU consumption on the database VM has again reached 100%. Test \(t_{1}\).