## 4 Performance Evaluation  
The performance evaluation compares the execution results between the master-slave system structure proposed in this paper and an existing scheme. The compared existing scheme was a distributed SPARQL query processing-related scheme over the Spark environment. The existing scheme considered distributed storage of a large amount of RDF data, but it did not consider data communication and join costs. Table 1 shows an experimental environment for the performance evaluation. Four virtual nodes were built. One was used as a master, and the other three nodes were used as slaves. The performance was compared between the SPARQL query processing scheme [43] over the Spark environment, which is an in-memory environment, and the existing scheme. Figure 6: ETE algorithm operation: (**a**) step to select the optimal query path; (**b**) query processing order for each node. For the performance evaluation, LUBM dataset [49] and DBpedia dataset [50] were used. Approximately 230,000, 430,000, and 910,000 records of RDF graph from the LUBM dataset and 300,000 records of RDF graph from the DBpedia dataset were used, which were distributed and stored in the three slave nodes. For SPARQL queries, four queries from the LUBM dataset and three queries from the DBpedia dataset were used in accordance with the dataset used in this performance evaluation. Q1 and Q2 in the LUBM dataset had a very small number of intermediate results from the nodes, entailing that data transfer between nodes was small. Q3 was only considered when query processing was performed in nodes whose number of necessary data for query processing was two. Q4 had a large number of intermediate results from the nodes, and a large amount of data were transferred during data transfer. In addition, Q1, Q2, and Q3 from DBpedia had a different size of data used during query processing. Figure 7 shows the comparison results of performances of the proposed scheme and when grouping of subqueries is not considered during query decomposition (group) and when optimal query execution path is not considered in the query execution path (optimal query execution). The performance was also compared with four different queries at the same data size. The query processing time was compared according to queries without considering query decomposition and query execution path in the proposed scheme. The performance evaluation results showed that Q1 and Q2 had a relatively small size of intermediate data, resulting in a similar query processing time with that of the proposed scheme was revealed, while Q3 and Q4 exhibited a performance difference between the proposed and existing schemes according to the intermediate data size and the number of subqueries. When grouping was not considered in query decomposition, the intermediate data size and join cost was increased in the existing scheme compared to that of the proposed scheme. Similarly, when the optimal query execution path was not considered in the query execution path, the communication cost was increased in the existing scheme compared to that of the proposed scheme. \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline Processor & Intel(R) Core(TM) i5 \\ Memory & 64 GB \\ No. of nodes & Master 1, Slave 3 \\ Engine used & Spark 2.4.5 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Experimental environment. Figure 7: Performance difference by considering query decomposition and query execution path. Figure 8 shows the comparison results of query processing time between the existing and proposed schemes. Performances were compared through different queries while changing a data size through various datasets. The proposed scheme showed better performance results than the existing scheme as queries became more complex and more intermediate results were obtained through corresponding queries. In addition, as the number of nodes during query processing increased, performance improved. However, as the number of used nodes decreased, no significant difference in performance was found.