# New Model for Defining and Implementing Performance Tests
## 4 Experiment and Discussion
### Scenario 1  
In the first case, an example of the use of the model bypassing the Network Layer is demonstrated, i.e., \(\{L_{1},L_{3}\}\). The performance test model without a network layer is useful in scenarios where the objective is to directly evaluate the performance of a server or application (let's denote this as \(a_{7}\)). In order to achieve the objective, it was decided to run the following types of tests (elements of the \(T\) set):  
* \(t_{0}\)--The Connections per Second test (CPS) provides a rough performance metric and allows for determining how well the server can accept and handle new connections. The test aims to establish the maximum number of connections (without transactions) required to maximize CPU resource utilization.
* \(t_{1}\)--The throughput test determines the maximum throughput of a server. It should be noted, however, that this refers to the throughput of the application layer and not to a general measurement of throughput as the total number of bits per second transmitted on the physical medium. In addition, the following elements of the sets \(G,C\) were defined:
* For \(t_{0}\): \(g_{1}\)--TCP/UDP Packet Generators, \(c_{0}\)--Servers: Web, Database; \(c_{1}\)--OS Built-in Monitoring Tools.
* For \(t_{1}\): \(g_{1}\), \(g_{2}\)--HTTP Request Generators, \(c_{0}\), \(c_{1}\). The test notation for the scenario 1 target is as follows: \[a_{7}=t_{0}\{L_{1}(g_{1}),L_{3}(c_{0},c_{1})\}+t_{1}\{L_{1}(g_{1},g_{2}),L_{3 }(c_{0},c_{1})\}\]In this example, the test object was an html page. It was hosted on an Apache 2.4 server. Services such as DNS, SSL, or firewall (possible bottlenecks) were also disabled. The system was hosted on a server with the following parameters: OS: Debian 12; RAM: 8 GB; Hard disc: 800 GB; CPU: Intel Pentium i5. The topological pattern of the test is shown in Figure 6. In addition, all data were collected on a dedicated desktop computer which acted as DATA COLECTOR (DC) and DATA ANALYZER (DA) (see Figure 3).  
During the test, TCP connections were attempted and http requests were sent using the GET method to an example resource on the server--in this case, it was a website on the server called index.html (size: 340 bytes). The web page was almost completely devoid of content. As can be seen in Figure 6, the system is devoid of any additional devices--communication takes place directly on the traffic generator--server line. Network traffic takes place via a 1 Gbit/s network interface. The built-in resource usage monitor of the Debian 12 was used as the monitoring agent.  
Test \(t_{0}\). Below (Figure 7) is a graph of the dependence of the number of connections per second on time and a report (Figure 8) for the CPS test (\(t_{0}\)).  
As can be read from Figure 7, the web server was able to handle 30,000 connections per second with a success rate of 92.57% (3,887,403 transactions out of 4,199,327 total attempts were made)--Figure 8. Such results mean that a limit has been reached on the number of connections that the web server is still able to make without a complete communication breakdown. These results are within expectations.  
Test \(t_{1}\). In the next step, the support of maximum throughput was tested (the throughput test).  
Figure 6: Template of the test topology for scenario 1.  
Figure 7: Graph of the dependence of the number of connections per second on time on the test web server.  
As can be seen in Figure 9, almost the entire 1 Gb communication bandwidth was used on the test server, maintaining almost 100% communication correctness (1,123,294 transactions out of 1,123,473 total attempts (Figure 10). These results are within expectations.  
Figure 8: Report on http client-server communication for test \(t_{0}\) in Scenario 1.  
Figure 9: Throughput vs. time graph on test web server for test \(t_{1}\) in Scenario 1.