Strange times when debugging with Local Client vs QNA

Content Authoring
1

Can someone help me understand QNA evaluation times? There seems to be a discrepancy between the local client and the fixlet debugger. It would appear that the local client is reporting only partial time of a given evaluation as opposed to the complete time to evaluate a statement.

Here’s an example

  1. Query a database and return the results as strings:

((rows of statements "SELECT IssuedTime, IssuerName, ActionName FROM ACTION_HISTORY" of sqlite databases of files "ActionHistory.db" of folders "__Global" of data folders of clients) as string)

  1. Identical query, but now concatenate the results into a single string:

(concatenations of ((rows of statements "SELECT IssuedTime, IssuerName, ActionName FROM ACTION_HISTORY" of sqlite databases of files "ActionHistory.db" of folders "__Global" of data folders of clients) as string))

When these actions are evaluated through QNA/Local Fixlet Debugger, I get the results I expect i.e. the 2nd statement is slightly slower (after all, I’m taking results and manipulating them). Test time for statement 1 is ~3.700ms. Test time for statement 2 is ~3.800ms. Nice and sensible.

When these actions are evaluated through QNA/Local Client, I get results that don’t make sense to me i.e. the 2nd statement is significantly faster. Test time for statement 1 is ~8.900ms. Test time for statement 2 is ~0.062ms.

Tested using 9.5.13.130 as client and QNA debugger. Please note that the above is just an example statement. Now that I’ve observed it, it seems to hold true for other evaluations - the example just makes the timings more obvious. I’ve tried using different SQL queries to ensure there is no caching, but this can also happen for other complex queries e.g. reading log files etc.

Am I misunderstanding how the local client is meant to return timings? Should I always use the Local Fixlet Debugger and ignore the client? If so, does this throw into question other timings reported by the local client?

2

When you Evaluate using Local Client, you are sending the relevance directly to the BES Client itself, the same way it would receive it from a deployed Action. That means taking in to account CPU usage thresholds and placement in evaluation loops. The only reason you would need to use Local Client would be if your testing relevance that requires properties that need to take aspects of the environment into consideration. I would provide an example but I don’t have one handy; but not using the Local Client would result in an error.

1 Like
3

But why does that report shorter times for the more complex query? The fixlet debugger is reporting correctly - but the local client always reports a wrong time? CPU thresholds should only change the relative overall performance, but evaluating a more complex query cannot be faster than the simpler query especially when the initial data set is the same?

4

I cannot answer as that goes beyond my understanding. I know the Local Client sends it into the “queue” and perhaps that is the reason. I did dig up some relevance that requires context. This will error unless ran using Local Client, as local context is required.

distinguished name of local computer of active directory = "OU Name"

1 Like
5

Thanks - I realise that the local client sometimes need to be used as some inspectors are not visible/useable by the local fixlet debugger. I generally try and use the local fixlet debugger initially as the results tend to be more reliable.

The thrust of my question is trying to determine why the evaluation timings from the local client appear to be significantly incorrect. It can (and does) give a misleading impression that various queries are fast when in reality they are significantly slower than what is being reported. This make troubleshooting client performance issues very difficult.