Skip to main content

Hi Community,

 

I've recently finished a project which includes a view holding a picker control. The picker control is used to find a users Department Head from AD, and the data source is configured appropriately. A problem occurs when I execute the update or load method on the view, it takes between 2-3 minutes for the method to execute. I found that by changing this picker control to a text box or removing the picker control I could reduce the execution time of these methods to under 2 seconds, and I can't imagine why this is the case. I have individually enabled/disabled each rule on the form to try and isolate the problem, and the only solutions are when I remove the picker control, change it to another control type or disable the "when the picker is resolving" rule.

 

I encountered a similar problem on a different project and I found that by remaking the view from scratch the problem did not reoccur, even though when i checked all of the rules were configured the same way, so I tried to remake this view and the problem did not happen on the new view.

 

When the update method is executed, I have checked the database and found all of the values to have been saved within the first few seconds, however the form will continue loading for two minutes or more.

 

Has anyone came across a similar problem, and if so is there a solution other than re-creating the whole view?

 

Thanks,

 

Simon

 

 

The next time it occurs, you might check to see if this value gets changed. The picker should load async to avoid locking up the UI while it loading. That is what it sounds like happens based on your accounting. Cannot say for certain but worth checking the next time around.

 

14893i2989D45CF45717FA.png

 

S.

Hi Scott,

 

I've ensured that the picker is being populated asynchronously even though the symptoms indicate otherwise.

 

The finished(slow) view rules:

14490i2E20B3B23B882D55.png

 

This rule(when disabled) accelerates the execution time of the update and load methods drastically for the existing view, but the new view remains unaffected.

 

 

 

 

 

It seems the performance is also related to some drop down lists I am using, as when I remove the filter from them the method execution time increases drastically as well as by removing the picker control.

I  have run into this problem also.  We traced it all down to AD performance and how K2 handles the query to AD.

We fought this for a good while and our conculsion was to replicate AD information into a SQL database.  All queries and lookups became lightnight fast and all performance problems simply went away.

I think this is an instance where K2 might be allowing us to do things we really shouldn't (such as have each form query AD).  In AD it was very difficult to trace the actual calls being made and try and troubleshoot and tune the performance.  Compare that with a SQL table and there are many tools that will show you the exact SQL K2 is useing.

 

I don't like to post radically different solutions in the forums, but we were totally in your same boat and really did fight it for a good couple weeks before we changed.  In the end we spend three days moving to SQL and if we had just done that first, we would have saved a ton of time.

Nathan

Thanks Nathan!

 

We'll have a look at the solution you suggested and i'll update here if it works for us

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings