VAI is slow for simple queries and seems to not use any kind of caching on the sever-side.
Eg. Queries running to get an individual device's location name take about 40 milliseconds, and on subsequent queries for the same device's location take another 40 milliseconds. There are no API methods for pulling data(location name) or properties for a set of devices in bulk in order to reduce the server load. Client side caching is not an answer for this poor of a read performance, a standard relational db has better read performance. It is also not a good design pattern, in this scenario because there is no pub/sub pattern for client to subscribe to, so they are given no choice but to repeatedly query the server to get updates. Imagine if we are trying to do dynamic groups based on AP macs...we would be querying the server every other second for the data. This would put unnecessary load on the server and effect normal voice services.
There needs to be some kind of server side caching for repeated queries. And another API for a pub/sub system that pushes updates to subscribers. You can also add pagination to your query API as a way to increase read time. I sincerely hope that the 6.0 platform was not a lift and shift for the VAI, else it is borderline useless for anything serious or real-time.
Guest
