Slow Api

[redpoint]

Hi,

We are trying to connect Jiwa with Woocommerce. Jiwa API is taking almost 16 second to deny connection and almost 32 second for successful authentication. Why API is too slow or is this a issue from our end?

[Mike.Sheen]

Hi,

We are trying to connect Jiwa with Woocommerce. Jiwa API is taking almost 16 second to deny connection and almost 32 second for successful authentication. Why API is too slow or is this a issue from our end?

Most likely you have plugins which are failing to compile, and as a result every login is trying to compile them.

You can check which plugins have issues with the PluginExceptions route - for example: https://api.jiwa.com.au/Queries/PluginE ... AsRJznB_Ok

You can also get a breakdown of where the time is being spent on authentication with the StartupLog route eg : https://api.jiwa.com.au/Queries/Startup ... AsRJznB_Ok

Post the results of the StartupLog route here and I can tell you what you should look at next.

[redpoint]

Here is the result (please check attached csv file)

[Mike.Sheen]

Here is the result (please check attached csv file)

Thanks - I can see there are some plugins which are being compiled - you shouldn't be seeing this on authentication every time - only if the plugin has changed or did not compile previously - and this would be gobbling up some time.

Now please show me the output of the /Queries/PluginExceptions route - this should show the exception text if plugins were encountering issues compiling.

[redpoint]

Hello Mike,

Thanks, please check this file.

Please explain what we have to fix?

Thanks

[Mike.Sheen]

Hello Mike,

Thanks, please check this file.

Please explain what we have to fix?

Thanks

Run the following script against your database:

Code: Select all

DELETE FROM SY_PluginReference WHERE AssemblyFullName = 'Microsoft.SqlServer.Smo, Version=14.100.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'
DELETE FROM SY_PluginReference WHERE AssemblyFullName = 'Microsoft.SqlServer.Dac, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'


Then restart your API service and then check the /Queries/PluginExceptions - it should be empty now.

The script just side-steps the problem - and the problem is that the SQL components SMO and DAC are not correctly deployed to the machine the API service is running on - but the plugins don't need to have a reference to those components, and that is what the script does - remove the references to those components. The plugins only had the reference to these in the first place, as when a plugin is created we - in an effort to be helpful - add to the new plugin the references that the JiwaApplication.dll has, because any plugin will need at least *some* of those references to be functional - and rather than have an explicit list of default references we just use the same references as found in JiwaApplication.dll.

[redpoint]

Thanks,

Just to confirm if I run this query, will it going to have any functional impact on our Jiwa?

Thanks

[Mike.Sheen]

Thanks,

Just to confirm if I run this query, will it going to have any functional impact on our Jiwa?

Thanks

Without having access to all those plugins which someone custom-made for you, I can't be 100% sure, but it's going to be a fairly safe bet it won't cause any problems... It removes references which are not needed - and even if they are needed the reference can't be used anyway because those SQL components are not properly installed.

If anything does go wrong I promise I will help you fix it, but there is another method if you're wanting to avoid running the script... and that is to get those SQL components properly installed / registered so you wouldn't need to run the script to remove references to them, and the plugins would find them and happily compile.

I suspect after Jiwa was installed, those components were removed. So, repairing the Jiwa installation on that machine - or uninstalling Jiwa and re-installing should fix that. That may actually be a riskier option than running the SQL Script - depending on the environment... it could be you have other applications which might break as a result - it's hard to say.

I can't promise anything other than I'll help you to get to a working state - but it may mean something breaks along the way.

[twofatmonkeys]

Run the following script against your database:

Thanks Mike, I've just taken this issue over, the key piece of info missing here was that the API in this instance is running under IIS, those referenced libraries were missing from the %API_install_path%\Bin folder.

Added the missing .dlls and all is good!

Thanks again, Dirk