## 3 Methods
### Performance Metrics  
The performance metrics we focused on include response time, CPU usage, and memory usage. These metrics can be calculated after each run for each database, providing insights into performance during runtime. While we plan to use the aforementioned application for measurement, other methods are also available. One alternative is to gather runtime information through the monitoring features of a cloud database service. The local approach, utilizing the application, is particularly beneficial when the database is hosted on the same machine that acts as the server, as it allows for real-time monitoring of resource usage during the algorithm's execution. Conversely, the cloud approach is more advantageous when the database is located on a different machine than the one running the tests, and when accessing resource usage is not feasible in the same way.  
The SQL Server database was hosted on the same machine as the server, while the Neo4j database was located on the AuraDB cloud platform, which runs Neo4j version 5. This choice was primarily driven by the unique characteristics of each database, which necessitated different methods for calculating performance metrics. SQL Server operates directly on the host machine, whereas Neo4j runs through Java Virtual Machine (JVM), leading to variations in CPU usage and memory structure. According to the Neo4j knowledge base [16], memory is organized into two main regions: off-heap and on-heap. On-heap memory refers to the JVM heap, which is responsible for storing runtime data, managing graph transactions, and executing queries. In contrast, off-heap memory includes page-cache memory, which holds graph data, as well as direct memory that contains buffers and internal JVM resources. Attempts to use Neo4j locally did not yield significant results for all performance metrics.  
Memory usage displayed a consistent linear pattern, while CPU usage appeared to exceed 100% capacity when the same methods were employed.  
The method for measuring time is consistent across both databases and is conducted on the server. We use the C# Stopwatch variable to calculate the difference between the start time--when the user's request reaches the server--and the finish time--when the result is returned from the database. For memory usage, particularly with SQL Server, we utilized the System.Diagnostics library [17] in C# to retrieve the amount of memory used by the database during the query execution. In the case of Neo4j, AuraDB provides the capability to monitor the heap memory utilized during query execution.  
To compute CPU usage, a more complex formula is required since calling a function from System.Diagnostics alone is insufficient. We employed the PerformanceCounter class from System.Diagnostics to obtain the percentage of total time during which all processes utilize the CPU. Subsequently, we selected all processes associated with the desired database using the Process class, also from System.Diagnostics, and computed the total time for these processes. The final CPU usage percentage was calculated using Equation (1). This method was applied only to SQL Server. For Neo4j, since the database is hosted on a cloud platform, it was not feasible to perform calculations on the test machine, and the results were obtained directly from AuraDB.  
\[\text{cpu\_%usage}=\frac{\text{execution\_time}\times\text{processes\_ total\_time}}{\text{interest\_processes\_time}} \tag{1}\]