Any tips or diagnostic software to check slow Jiwa?

[DannyC]

We have a client who has been complaining of slow Jiwa for a few weeks. As an example, entering a single line on sales order entry can take 4 minutes!

I have pretty much ruled out SQL Server as I've done several tweaks (all have helped to a degree) which haven't significantly improved the user experience.

With ruling out SQL Server as the bottleneck I want to now concentrate on the network and/or workstation. This client's network/IT team have been in and done their own investigating and they can't find anything but I am wondering, do you know of any diagnostic software which can be installed on some workstations to assist? Maybe something which exploits the functionality of perfmon but gives some suggestions and tips when issues are detected? Or a packet sniffing tool which also does various analyses and gives suggestions on where issues may be?
Or other software which can detect issues which Jiwa is having trying to execute various commands?

And just to add, the workstations appear to have sufficient hardware - they're reasonably new i5 or i7 quad cores, at least 8Gb RAM, some have 16Gb RAM.

Cheers

[Scott.Pearce]

Does the slowness occur in demo data on the same server as live?

Does the slowness occur if a copy of the live database is used with all plugins disabled?

Does a SQL trace for only that user reveal long running queries?

Does the slowness occur for other Jiwa users using the same workstation?

My money is on a plugin doing something.

[DannyC]

My money is on a plugin doing something.

I was thinking similar as there is at least 1 plugin firing when lines are added to a sales order. But I can enter lines on an order without too much impact, so if the plugin(s) is causing 1 PC to be slow I'd expect it to impact all PCs doing the same thing.

I'll do some targetted plugin investigating and see how we go.

[Mike.Sheen]

Or other software which can detect issues which Jiwa is having trying to execute various commands?

Try fuslogvw.exe.

The fact the slowness only occurs for some machines / users might indicate an assembly resolution problem. Fuslogvw will log how Fusion (The bit in .NET which finds assemblies) located an assembly.

Also procmon might reveal something, but be prepared for massive amounts of log information. This shows file and registry accesses which might help.

I recall sometime back in 1999/2000 -I had my Windows 98 machine being really slow to bring up context menus - anywhere - file explorer, applications, the works. After installing the predecessor to procmon, I discovered what was happening was I had installed Winzip from a network share, and that hooked into the context menus to add the helpful option to right click on a file or folder and choose "Add to zip..." - but the problem was the network share was no longer present, so any context menu trying to display for some reason was trying to find the original install location - and as it did not exist it would wait until a timeout failed (silently) before displaying the context menu. This meant a good 30 seconds before ANY context menu loaded.

And it was procmon or whatever it used to be called which I used to find out what that issue was. Now, this might not be the cause of your problem here, but it illustrates how tools like these can sometimes reveal issues.

[DannyC]

I'll do some targetted plugin investigating and see how we go.

Yep, that was it.
I disabled a plugin and the user could enter lines without issue. When plugin is enabled the workstation was slow.

What the plugin does is check an inventory custom field for a certain value, and if that value is found, it displays a messagebox to the user.
In order to check inventory custom fields, I am instantiating a full inventory object as the entity doesn't have custom fields. I'm using this code (version 7.2.1)

Code: Select all

JiwaFinancials.Jiwa.JiwaApplication.Manager manager = salesOrder.Manager;
JiwaFinancials.Jiwa.JiwaInventory.Inventory Inventory = manager.BusinessLogicFactory.CreateBusinessLogic<JiwaFinancials.Jiwa.JiwaInventory.Inventory>(null);
Inventory.Read(item.InventoryID);


This raises a few questions:
1. Is there a better way rather than

Code: Select all

Inventory.CustomFieldValues.get_ItemFromSettingName("MyCustomField").Contents

Maybe I could just execute a SQL SELECT statement to pull the value from the database instead of instantiating an inventory object and using the above property?

2. Why would only this particular workstation exhibit slowness, but others seem to run OK? When the same user does a terminal server session, there's no delay. It doesn't seem to be a hardware issue. Would installing some obscure software help? Or is the a Windows component which mightn't be installed and should be? Or vice-versa, i.e. something else installed which is interfering?

[Scott.Pearce]

I disabled a plugin and the user could enter lines without issue.

What do I win?

In order to check inventory custom fields, I am instantiating a full inventory object

Which version of Jiwa? There are some helper functions I can point you to depending on version. Alternatively you could hit the custom settings table directly from within the plugin.

[Mike.Sheen]

Is there a better way rather than

Code: Select all

Inventory.CustomFieldValues.get_ItemFromSettingName("MyCustomField").Contents

Note in terms of performance when using the business logic, no. There are more friendly / readable helper methods to get custom setting contents, but they won't help with performance.

Actually there is a static method we have to do a quick and dirty read of custom field methods. Scott's going to give you some guidance on how to use that, it all depends on the version.

Maybe I could just execute a SQL SELECT statement to pull the value from the database instead of instantiating an inventory object and using the above property?

Yes, that would be the best solution.

Why would only this particular workstation exhibit slowness, but others seem to run OK? When the same user does a terminal server session, there's no delay. It doesn't seem to be a hardware issue. Would installing some obscure software help? Or is the a Windows component which mightn't be installed and should be? Or vice-versa, i.e. something else installed which is interfering?

As I mentioned in my earlier post, if you want to diagnose this try fuslogvw and procmon to begin analysis of exactly what is going on on the system when that particular workstation is trying to read the inventory item.

[Scott.Pearce]

From 07.02.00.00 SR3 onwards you can use:

Code: Select all

string myCustomField = JiwaFinancials.Jiwa.JiwaApplication.CustomFields.CustomFieldValueCollection.ReadCustomFieldValue(salesOrder.Manager,"IN_CustomSettingValues","InventoryID","SettingID", "SettingID","IN_CustomSetting",item.InventoryID, "MyCustomField" );

ReadCustomFieldValue() was bugged in versions before that - it only read from IN_CustomSettings. Let me know your version.

[DannyC]

Let me know your version

7.2.1

Using that helper function, I don't need to instantiate a full inventory object?
EDIT: Never mind, I've just hunted down that function in JustDecompile and I can see what it does.

[Scott.Pearce]

Using that helper function, I don't need to instantiate a full inventory object?

If you are just trying to get that custom field value, then no, you don't need to instantiate a full inventory object. The ReadCustomFieldValue() function is a shared function (meaning you do not have to instantiate an object to use it), that simply does a direct table query. More efficient than instantiating a big heavy business logic object, and then populating ALL data, even what you are not interested in.