I’m looking at the query store configuration options, and I’d like to know a bit more about how it works and any important points we should be aware of to ensure accurate responses from the json-api.
In our case, for example, we will have an automated service watching for external events, and then exercising choices on the ledger in response. This means a contract of this template could be queried for, and then it could be archived and created with updates 0.3 seconds later, how will the query store react to this? The given choice may archive and create a couple of other related contracts, how heavy could the traffic be between the query store and the ledger in this sort of scenario? Could there be performance implications?
Given that this query store is recommended for production use cases it would be great to see more documentation than the small paragraph that is currently present.
This is an excellent set of questions @lashenhurst and certainly something we should have in more detail. I’ve split the questions up into separate threads so that each can be answered independently and more easily digested and responded to by others.
Based on that, you can see that for follow-up queries the performance depends on the number of events in the transactions between the last query and current ledger end so roughly the delta between the last ACS and the current ACS. So if you have a large ACS and relatively small changes, the database backend buys you quite a bit of performance since the JSON API won’t request the entire ACS on every query. You can in principle construct cases where you have very small ACS sizes and the ACS changes completely frequently where the query backend performs worse but in practice we haven’t seen that become an issue so far.