AW - Slow Page Loading When Query Results Are Large

[mwojno-tsg]

Overview

• Active Wizard seems to be running all configured queries upon page loading within ACA. This noticeably degrades performance for the page load time when large query results are returned from these queries.

• For example, I have a query that will pull from a datalist that has around 7,000 entries. This along with a few other similar queries are ran when the page loads. It freezes the page and does not let the user click around. If the user starts clicking around, it could overwhelm the application and cause a failure.

• Also, this could cause timeout in a PaaS environment

Ideas for Solution

• Investigate why all queries are ran when the page loads. See if we have to perform those functions and if we could only run the necessary queries for that particular page.

[gsteimer]

Workaround to this issue would be to set up a "type three characters" type cascading question to limit the results that can come back in large result set queries.

For an example - see the TS Cascading Query page sets on edge1 and edge2, specifically the User Search page.

Per @dgrumieaux - this could still be an issue though when the user edits an existing form. Both scenarios should be tested.

[mwojno-tsg]

Upon further investigation there are some more details to provide concerning this:

• There doesn't seem to be an issue with query load time or all queries being ran when the page is first loaded. I have noticed that queries will only be ran if there are on the page being viewed. Also, the performance of returning the query shouldn't be any issue.
• With the specific customer, there is an interesting behavior where ~100 execute wizard query calls will be fired on a single page. The form is quite complex with multiple routes. However, each route tested behaves this way.
• The bombardment of wizard query calls happens at different pages depending on the route taken through the form but I have been able to reproduce on every route tested.
• The ~100 wizard query calls are the same exact query being ran as a duplication. Therefore, it seems like there could be some weird bug that is letting the listener fire so many queries off.
• I have traced the code to originate from the change:placeholders:none and those triggers.
• As a quick fix, I have placed a _.throttle around the effected area that triggers the event. This seemed to resolve the issue. However, a better solution could be achieved.

[newmanju]

Closed with SVN Revision 26456:

Added a stopListening call before attaching a listener to the event "change:placeholders:none:" to avoid duplicate listeners. duplicate listeners were being attached because the same page was being evaluated multiple times for different flow paths in the form. We were already doing similar logic with the listener for the event "change:placeholders:validity:".

CR: dgrumieaux, aking