## 5 Results and Discussion
### Lightweight Performance  
In addition to accuracy, the advantages and disadvantages of log parsers can be evaluated based on their efficiency. In this section, lightweight performance is evaluated in terms of CPU usage, running time, and memory consumption. **CPU usage. ** As the computing capabilities of distributed devices increase, the burden on servers increases, which should be reduced. Thus, the log parsing methods were evaluated in terms of CPU resource consumption during operation. A relatively lightweight log parser is more suitable for deployment in large-scale distributed systems than a heavy log parser. We used the existing packages in the Python 3.9 environment to calculate the CPU usage at each moment and adopted the HDFS dataset containing 10 K log messages. The results obtained by the five methods are presented in Figure 6. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline  & & \multicolumn{3}{c}{**Train**} & \multicolumn{3}{c}{**Test**} \\ \hline  & & **Precision** & **Recall** & **F1** & **Precision** & **Recall** & **F1** \\ \hline \multirow{4}{*}{DT} & Drain & 0.99 & 0.99 & 0.99 & 1 & 0.98 & 0.99 \\  & IPLoM & 1 & 1 & 1 & 0.99 & 0.97 & 0.98 \\  & Spell & 1 & 1 & 1 & 1 & 0.99 & 0.99 \\  & MoLFI & 0.99 & 0.99 & 0.99 & 1 & 0.98 & 0.99 \\  & CFTL & 0.99 & 0.99 & 0.99 & 1 & 0.99 & 0.99 \\ \hline \multirow{4}{*}{SVM} & Drain & 0.96 & 0.99 & 0.98 & 0.84 & 0.98 & 0.90 \\  & IPLoM & 0.97 & 0.99 & 0.98 & 0.84 & 0.98 & 0.90 \\ \cline{1-1}  & Spell & 0.99 & 0.99 & 0.99 & 0.84 & 0.99 & 0.91 \\ \cline{1-1}  & MoLFI & 0.96 & 0.99 & 0.97 & 0.83 & 0.98 & 0.90 \\ \cline{1-1}  & CFTL & 0.96 & 0.99 & 0.97 & 0.83 & 0.99 & 0.91 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Performance of log parsing in anomaly detection. Figure 6: CPU usage of five log parsers. The blue part indicates the CPU usage while the program is running, and the light-blue part indicates the CPU usage before and after the program runs. The results show that the resource consumption of the log parser at runtime is not gradual and has a peak. This is because all log data have been read and calculations have started. After the log parser finishes running, it releases the occupied resources. The experimental results indicate that CFTL is a lightweight log parser suitable for deployment on large-scale distributed servers. **Running time. ** To more intuitively analyze the time efficiency of the different methods, six HDFS dataset sizes, namely, 1 kb, 10 kb, 100 kb, 1 mb, 10 mb, and 100 mb, were used to evaluate their running times. The times required by the methods to complete the entire parsing process were recorded and compared on a logarithmic scale. The results are presented in Figure 7.  
In general, the proposed CFTL algorithm requires less time than the comparison log parsers. For the other methods, MoLFI was slower than Drain, IPLoM, and CFTL regardless of the dataset size. This is because MoLFI applies an iterative evolutionary strategy, which is time-consuming. IPLoM was the most efficient log parser in this comparative experiment. The running times of CFTL, IPLoM, and Drain were almost identical when the dataset size was less than 1 MB. However, as the size increased, the runtime of CFTL increased and was significantly slower than that of Drain but faster than that of IPLoM. **Memory consumption. ** When handling large log files, the memory consumption of the log parser should be considered an important aspect of performance in addition to accuracy. If the log parser uses excessive memory, other important programs of the server will be affected in terms of timeliness. This will also lead to a series of problems that reduce the communication efficiency between the server and edge device. The same six HDFS dataset sizes were used to evaluate the memory consumption of the log parsing methods. The results are presented in Figure 8.  
In general, the proposed CFTL algorithm requires less memory than the comparison log parsers.