# Vnode: Low-Overhead Transparent Tracing of Node.js-Based Microservice Architectures
## 5 Results
### Discussion  
The outcomes of the experiments depicted in Figure 10(a) show that the response times of the application executed using our method incurred a low overhead on the system compared to the uninstrumented application. The average response time for the \"get user\" operation was 4.7 ms (standard deviation: 1.33) when no instrumentation was conducted, 5.1 ms (standard deviation: 1.18) when distributed tracing was employed, 5.35 ms (standard deviation: 1.05) when the Rbinder strategy was employed, and 5.07 ms (standard deviation: 1.23), when our strategy (Vnode) was employed.  
In the second scenario, experiments were conducted by initiating POST requests for the \"user add\" operation. The obtained response times are depicted in Figure 10(b). It is clear that the supplementary cost associated with tracing, on average, was consistently of a comparable magnitude, similar to the preceding scenario. The mean response time for the untraced program was 4.1 ms (standard deviation: 1.33), 4.29 ms (standard deviation: 1.37) when using distributed tracing, 4.6 ms (standard deviation: 1.46) when using Rbinder, and 4.3 ms with Vnode. An examination of the overhead resulting from tracing using our approach reveals that it is comparable to state-of-the-art approaches, incurring only a 5% cost on the traced system. Figure 10(c) illustrates the central processing unit (CPU) utilization in the scenario when the application was executed without any tracing. Comparing the aforementioned data with those in Figure 10(d), which illustrates the CPU utilization while employing our proposed methodology, a slight increase in resource use was observed.  
Given that the execution time of the analyses required to build the model is strongly dependent on the number of events contained in the trace, it is important to measure the time required on various trace file sizes. Figure 10(e),f, respectively, depict the CPU utilization and time to run the analysis according to the trace sizes. For different sizes of the trace, the needed time is presented. The experiments show that our technique is optimized to run with very good times. This is due to the nature of the data structure (SHT) used, enabling access in logarithmic time.  
The LTTng tracer had a minimal impact on the system, as the activation of a tracing point incurred a nanosecond-level overhead. LTTng is the fastest software tracer available ([PERSON] et al., 2018). The evaluation of the collection and analysis infrastructure using our approach demonstrates all the advantages it offers. Firstly, the induced overhead was relatively low on the system in terms of CPU and memory usage. In the first case, this can be justified by the tracer used and the optimization of the inserted tracepoints. In the second case, memory usage was not significantly impacted despite the size of the trace files, which can contain millions and billions of events, simply because the data structure constructed was disk-based. It depends primarily on disk write speed, especially during model construction.  
In the case of distributed tracing, the tracing overhead is acceptable, but using this strategy requires an understanding of the application's source code for instrumentation. This involves additional human costs and alters the application's behavior. To spare developers from these instrumentation efforts, an approach based on a \"proxy envoy\", called Rbinder, has been proposed. However, while it offers the advantage of transparently tracing the application, it still requires developers to invest significant time in setting up the collection's infrastructure, especially in configuring the proxies. In contrast to these approaches, our approach enables transparent tracing without any developer intervention. Developers are not required to establish the collection's infrastructure. Only the images of Node.js containers are replaced with instrumented images and deployed seamlessly, without modifying the development pipeline procedures.  
Figure 11: Experimental results and impact on physical resources.