# VidBlock: A Web3.0-Enabled Decentralized Blockchain Architecture for Live Video Streaming
## 4 Experiment and Evaluation
### Performance Test
#### 4.2.2 Memory Performance Evaluation for VidBlock Under Concurrent Requests
* **Total private dirty memory:** This metric represents the amount of memory that has been modified by the application and is exclusively private to it. Unlike shared memory pages, private dirty memory pages are not accessible by other processes, making this memory wholly dedicated to the application. High values in private dirty memory indicate that the application is consuming a significant amount of unique memory resources, which can contribute to memory pressure on the system. Monitoring private dirty memory is essential for assessing an application's exclusive memory footprint, as it highlights the memory that the application alone is responsible for, without shared or system-wide allocation. Efficient management of private dirty memory is particularly important in a resource-constrained environment, as high values could lead to reduced system performance and increased likelihood of memory-related issues, such as system swapping or app termination. The experimental results, as shown in the table, indicate that VidBlock demonstrates consistent memory usage patterns across varying connection loads, with only marginal increases observed as the number of concurrent connections grows:  
* **Total PSS and total RSS:** Across all scenarios, from 5 to 250 concurrent requests, the total PSS and total RSS values exhibit only slight increases. For example, total PSS grows from 253,978 KB (at 0 s for 5 requests) to 358,532 KB (at 180 s for 250 requests), and total RSS grows from 343,844 KB to 455,272 KB. This minimal increase indicates efficient memory handling within the VidBlock application, even under increased load, and suggests that the application's memory management strategy effectively mitigates excessive memory usage. Figure 8: Comparison of memory performance by number of concurrent requests (measured for 180 s at 60 s intervals). * **Native heap usage and allocation:** The native heap metric used shows stable values, increasing slightly with the number of requests. For instance, the native heap used metric reaches approximately 121,020 KB under 250 requests after 180 s, compared to 75,480 KB under only 5 requests at 0 s. This gradual increase reflects efficient allocation as the application scales the memory usage proportionally rather than excessively. VidBlock appears to utilize native resources sparingly, which enhances its scalability without imposing a significant memory burden. * **Dalvik heap usage and allocation:** Similarly, Dalvik heap usage remains stable across different connection loads, demonstrating VidBlock's effective handling of managed memory within the Android runtime. The Dalvik heap allocated metric shows minor growth across scenarios, reaching up to 9550 KB under the highest load. The stability of the Dalvik heap metrics underscores VidBlock's optimized runtime management, suggesting that the application maintains performance without excessive use of managed memory resources. * **Total private dirty memory:** Total private dirty memory remains consistently low across all scenarios, indicating that the memory utilized is efficiently handled without generating excessive private memory modifications. For instance, total private dirty memory under 5 requests reaches a maximum of 299,876 KB after 180 s, while under 250 requests, it only slightly increases to 259,472 KB. This low private dirty memory usage reflects VidBlock's efficient memory footprint, implying that even under high concurrent connection requests, the application does not impose a heavy memory load on the device. The experimental evidence substantiates that VidBlock maintains a low and stable memory overhead, regardless of the number of concurrent P2P connections. The minimal increase in total PSS and RSS, along with the stability in native and Dalvik heap metrics, demonstrates VidBlock's capability to scale effectively without imposing additional memory demands on the system.