I’m doing some performance troubleshooting in relation to some BAQ queries that are impacting our server. One thing I noticed is that a whole second of work is needed just to prepare for a BAQ query. There is something that keeps showing up in the SQL profiler when we are running BAQ queries and it is one of the things that consumes the highest CPU (more than any of the work done by our customized query itself):
It looks like meta-data information (Ice.Column, Ice.Table, Ice.ZDataField).
Can someone tell me why this would take a whole second? Is there some kind of .Net CLR function that is doing a ton of work? Is there a bad index in use?
Another question is related to BAQ performance as well. I’ve noticed that we can submit these BAQ queries via REST. I have tried to execute them concurrently for the same user (different Bearer Tokens). But for some reason it quickly restricts the number of queries that can be done in parallel. It takes about 95 seconds for 100 REST queries to be run sequentially, and only drops down to about 85 seconds if I’m running them concurrently on 10 different threads. There is no resource that appears to reach capacity (either on the SQL side or on the appserver) so I’m guessing that there is some concurrency restriction that is preventing multiple queries to run simultaneously. I haven’t checked yet to see if the restriction is removed by using multiple user accounts.
Does anyone know of a configuration that affects the number of concurrent BAQ queries that can execute simultaneously?
If I could solve either issue (the one second meta-data overhead or the concurrency restriction on queries) then my stuff would run a lot faster. Again, even when we fire off some greedy BAQ queries, there is still lots of unused capacity on our servers.