# Ransomware-Resilient Self-Healing XML Documents
## 5 Performance Evaluation  
In this section, we evaluate the proposed approach in terms of several performance metrics. To conduct our experiments, we use a repository of 500.odt files collected from different sources, with different sizes ranging from 10 KB to 30 MB. All experiments were conducted on a Ubuntu 18.0 machine with a Core i5-1.8 GHz Intel processor and 4 GB RAM. Creating a protected version of each file was achieved by running a shell script that included all the steps outlined in the proposed framework discussed in Section 4. We performed multiple experiments to measure the performance of the proposed SH-VARR framework. SH-VARR uses zip/unzip for file compression/decompression as it is the default compression/decompression algorithm used in connection with XML documents. Meanwhile, SH-VARR still has the flexibility of operating with any other compression algorithm. Therefore, different compression algorithms were investigated (zip, gzip, and bzip2) under our experimental set up. In this effort, we evaluate our proposed SH-VARR framework opposite storage overhead, time requirement, CPU utilization, and memory usage. Creating a protected version of a file (i.e., a snapshot) represents a major step in our framework which results in extra storage requirements. Hence, our objective is to quantify the amount of the resulting storage. This overhead depends mainly on the compression algorithm used to create the snapshot. Figure 6a-c show how the storage overhead increases with the original file size for the cases when using the zip, gzip, and bzip2 compression algorithms. Figure 6d illustrates all cases together for the purpose of comparison. Generally, by increasing the file size, the size of the resulting snapshot increases proportionately. With that said, the size of the resulting file remains smaller than that of the original file. It is quite evident from the comparison that the bzip2-based SH-VARR slightly outperforms the other two versions. However, it consumes more time, as we will discuss next. This would also imply that there is a trade-off between time and storage overhead. Meanwhile, given the lower storage costs involved in today's technologies, the time required to create a protected snapshot may play out as a more pronounced factor. The proposed SH-VARR framework involves several steps to create a protected snapshot for each file version. Therefore, it is important to measure the amount of time required to perform such an operation. Figure 7a-c show how the time requirement increases with the original file size for creating the snapshot in the proposed SH-VARR approach when leveraging the zip, gzip, and bzip2 compression algorithms, respectively. Figure 7d illustrates all cases together for comparison purposes. Creating a protected version for small files (e.g., less than 1 MB) takes a negligible amount of time that would, on average, not exceed 120 ms. However, for larger file sizes exceeding 10 MBs, more time is required to create the protected version. It can be observed that the amount of time varies as file compression depends on the amount of redundancy in each file and the type of content (e.g., text, images, etc.) contained in each file. It is evident from the outcomes of using both the zip and the gzip algorithms that the results are fairly comparable and they are seen to offer much better results than when using the bzip2 algorithm. In fact, the bzip2 is observed to consume considerable amounts of time to create the protected version, especially when the file sizes involved are quite large. Figure 6: Storage overhead by SH-VARR snapshot based on three compression algorithms. (**a**) Using zip algorithm; (**b**) Using gzip algorithm; (**c**) Using bzip2 algorithm; (**d**) All algorithms. Figure 8a-c show how the CPU utilization varies against the original file size for creating the snapshot in the proposed SH-VARR schema when leveraging the zip, gzip, and bzip2 compression algorithms, respectively. Figure 8d illustrates all cases together for the purpose of comparison.