How cache handling affects MKS9.6 API command execution response time?
Using MKS 9.6 and its respective MKS API, we have observed that sometimes command execution can take up an unreasonable amount of time. Running the same command sequentially have a wide range of execution time. Wide range meaning for example in case of an "si projects" command sometimes the execution time is less than 3 seconds, but we have seen 11 mins long times as well. These absurd differences are observed on the exact same machine, when directly looped for testing purposes. (Also, no recognizable pattern in the execution time.)
The measurement is done only for the command mksResponse response = mksCmdRunnerExecCmd(cmdrunner, actcmd, INTERIM_CACHE); in case of using the C API. (We have observed the same problems using the JAVA API as well.)
When the absurdly long executions happened, we have seen log lines like destruction of cache (for user moldovanyi) - moldovanyi being the user during our tests of course , probably that has something to do with the problem?
We tried changing the INTERIM paramater to INTERIM_NO_CACHE with moderate success. We haven't met the ridiculous 11 mins running times anymore, but it still executes for 90+ seconds sometimes (once again, no pattern). It is important that in all cases the command execution was successful, no exceptions were thrown, and afterwards reading through the results were fine.
The problem is that the whole interim concept should be working with 'instant' execution, and possible slowing down during the result processing phase, as MKS pumps data into the structures. Sadly, this is not what's happening in our case.
Re: How cache handling affects MKS9.6 API command execution response time?
I don't have a solution for you, but I am curious to know if you ran the command with NO_INTERIM, and what the times were for those results.
There are obviously a number of factors involved, including database latency, number of projects in Source Integrity, network performance between client and server, etc., etc., BUT a variance on the order of 2200 seems excessive to me as well. In this situation, my recommendation would be to open a case with PTC Integrity Lifecycle Manager Technical Support to investigate this further, preferably with the results of NO_INTERIM testing as well. Please ask them to follow-up in this thread with the general results of the investigation, for future reference.
Kind Regards, Kael Lizak
Senior Technical Support Engineer PTC Integrity Lifecycle Manager