# Dynamic Storage Optimization for Communication between AI Agents
## 5 Results  
Here, we present the experimental findings assessing the replication environments in terms of their suitability for the proposed model and their optimal parameter configurations. The experiments assessed the dependence of the latencies on the four types of parameters mentioned in the previous section for both retrieving and persisting concepts within the underlying environments.  
We present the outcomes for 360 distinct experimental configurations. The configuration parameters that were used to obtain the results are specified in Tables 1-3. Each experiment consisted of five warm-up iterations and ten execution iterations, with time limits of 10 s and 30 s, respectively. The results were first averaged over the ten execution runs. However, to provide a better overview of the high-level behavior related to the architectures and configuration parameters, we averaged the results over concept sizes without losing critical information (see Figure 3). Similar relationships between concept sizes and latencies also held for the other architectures and configurations and thus are not shown. The values from the 64 h of nonstop simulation were averaged to obtain the results.  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Values** \\ \hline Topology (peers count) & 2 \(|\)\(4\)\(|\)\(8\) \\ \hline Concept size (properties count) & \(10^{2}\)\(|\)\(10^{3}\)\(|\)\(10^{4}\) \\ \hline Operation & Read \(|\) Write \\ \hline Block size & Half \(|\) Double \\ \hline Transaction pool & Half \(|\) Double \\ \hline Datastore engine & GolevelDB \(|\) CouchDB \\ \hline Warm-up iterations & 5 (each running for 10 s) \\ \hline Execution iterations & 10 (each running for 30 s) \\ \hline \hline \end{tabular}
\end{table}
Table 3: Hyperledger Fabric simulation parameters.  
**Observation 2:** As demonstrated by the results for the IPFS configuration in Figure 4a, depending on the storage engine, the optimized version of the model achieved a read performance improvement of 30% to 40% compared to the full version. But for persisting the data, as shown in Figure 4b, the optimized model's improvement was smaller, ranging from 20% to 25%.  
**Observation 3:** Another notable observation from Figure 4 is that, despite IPFS providing a linear relationship between concept size and latency, it was observed that various storage engines responded differently to both the optimized and full versions of the model.  
**Observation 4:** Figure 5 shows the results for Tendermint Cosmos, and it can be seen that the proposed model behaved predictably and stably for both read and write use cases across all configurations. As expected, retrieving information was, on average, three times faster than persisting it.  
**Observation 5:** As demonstrated by the results for the Tendermint configuration in Figure 5a, the optimized version of the model achieved improvements of 30% to 35% in reading concepts compared to the full version, whereas the improvement for persisting the data ranged from 55% to 59% (see Figure 5b).  
**Observation 6:** Figure 6 summarizes the results for the tested Hyperledger Fabric configuration parameters. The proposed model was stable and behaved predictably across all measured configurations, with a slight improvement observed for the Couch DB storage configuration. Also, the measured latencies for writing were less than 20% slower than those for reading.  
**Observation 7:** As demonstrated by the results for the Hyperledger Fabric configuration in Figure 6a, the optimized version of the model achieved improvements of only 9% to 12% in reading compared to the full version. The improvement for persisting the data was even less, at just 5% (see Figure 6b).