[MongoDB Persistence] Performance decline with number of entries in repositories

[sirchnik]

Description

Adding more entries to the repositories causes endpoints for singular entries to have increasing response time.

CRUD operations are singular AAS operations. Submodel update is an update the a TimeSeries Model.

Run with:

faaast-version: 1.2.0
mongodb-version: 6.19
config.requestHandlerThreadPoolSize: 2
CPU: 8
RAM: 4GiB -> 2GiB JVM

When create the AAS I noticed high CPU usage on the MongoDB. I did run this test multiple times with similar results.

Additional Context

• I heard that this AAS-Implementation focuses on Edge-Devices and won't handle very much AAS in numbers. But I wanted to test this anyways.
  Additionally the number of AAS suitable for FA³ST-Service isn't documented anywhere.
• I am reporting this issue solely for testing purposes, as I am currently verifying which AAS implementations are functioning. Therefore, I don't need a fix at this time.

[mjacoby]

Thank you for the feedback and test results.
Indeed, FA³ST Service is not intended nor designed for high-scalability on cloud-level but focuses on edge-level deployments and asset synchronization. Therefore, scalability has not been our primary focus.
If you are interested to improve the performance of the MongoDB implementation feel free to make a PR.

Looking at your graph I wonder if you are working on a paper on evaluating different AAS implementations? If yes, we would be really interested in your findings and would appreciate a ping once your research is published.

[sirchnik]

I unfortunately don't have the time for analyzing the problem.
Thanks for the info about the focus of this project but this week I also found your paper on FA³ST-Service :).

I am just writing my bachelor thesis on the topic of AAS scalability. Dunno if there will be a paper.