# New Model for Defining and Implementing Performance Tests
## 4 Experiment and Discussion
### Scenario 2  
Scenario 2 demonstrates an example of the use of a model that considers all three layers, i.e., \(\{L_{1},L_{2},L_{3}\}\). This model of performance testing is useful in scenarios where the goal (\(a_{8}\)) is to assess the resilience of the system to operate under heavy load. In order to meet the objective, it was decided to run the following types of tests (elements of the \(T\) set):  
* \(t_{0}\)--Described in scenario 1. * \(t_{1}\)--Described in scenario 1. * \(t_{2}\)--The concurrent connection (CC) test allows you to determine the maximum number of active simultaneous TCP sessions that the server is able to maintain. In other words, it provides an answer to the question of how many concurrently active sessions the server is able to maintain before it runs out of memory. In addition, the following elements of the sets \(G,C,N\) were defined (only those elements of the sets that were not defined in scenario 1 will be described):  
* For \(t_{0}\): \(g_{1}\), \(n_{0}\)--Routers, Switches, Firewalls, \(c_{0},c_{3}\)--Data Analysis Tools: Grafana,
* For \(t_{1}\): \(g_{1}\), \(g_{2}\), \(n_{0}\), \(c_{0},c_{3}\)
* For \(t_{2}\): \(g_{1}\), \(n_{0}\), \(c_{0},c_{3}\)  
The test notation for the scenario 2 target is as follows:  
\[ \begin{array}{l}a_{8}=t_{0}\{L_{1}(g_{1}),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} \]  
Figure 10: Report on http client-server communication for test \(t_{1}\) in Scenario 1. Including the network layer in the performance test model allows for a more realistic simulation of actual system operating conditions. Such a model takes into account the impact of network devices and network topology on server and application performance. In the second scenario, the test object was again the web server, but this time a much more complex system, as it was a working e-learning platform. In order to best replicate real-life conditions, the tests were performed with a DNS server and an implemented SSL certificate. The web server functions are implemented by two virtual machines. The machines are implemented on a server hosted by the ESXi hypervisor. The first machine hosts the Moodle platform, while the second hosts the PostgreSQL database associated with Moodle. The pattern of the test topology for scenario 2 is shown in Figure 11.  
As can be seen in Figure 11, the system is much more complex than the previous one, because the system chosen for testing is as close as possible to real systems. This time, network traffic is not generated directly to the server, but instead passes through an intermediate network layer (a real campus network loaded with normal user traffic). Test \(t_{0}\). Below (Figure 12) is a graph showing the dependence of the number of CPS connections on time, which was generated by the IxLoad software. Test on the e-learning platform showed (see Figure 12) that the maximum number of connections per second the server is able to handle is around 450-500 connections per second (this value stabilizes after approximately 40 s). These results are well below expectations. In addition, it can be seen in Figure 13 that after about 40 s there is a sharp increase in the number of concurrent connections, which is a sign of abnor  
Figure 11: Template of the test topology for scenario 2. Figure 12: Graph of the dependence of the CPS on time on e-learning platform. As can be read from Figure 14, out of 280,665 http requests, a correct response was received for 10,486 attempts (2 xx), while 270,177 requests were rejected with an error (5 xx abort). This error usually means that the server's resources have been exhausted. The CPU, RAM, and disk usage percentages on the virtual machines with Moodle and the database are shown below.