AnsweredAssumed Answered

Chart-filled dashboard causing client script trigger slowdown on hosted solution

Question asked by viscous_1 on May 27, 2010
Latest reply on Jun 10, 2011 by CS8


Chart-filled dashboard causing client script trigger slowdown on hosted solution

Description of the issue

FileMaker Product(s) involved:FileMaker Pro Advanced 11.0v1, FileMaker Server Advanced 11.0 (on Server 10.6.3 Nehalem Xserve)Operating System(s) involved:Mac 10.6.3 Mac 10.6.3 ServerMac 10.5.8Win 7Win XP SP3Detailed description of the issue: We have 80 files hosted by FMSA11.  We recently added charts to some of our databases, and things have been working flawlessly for the most part.  We also recently created a business prospects dashboard in one particular sales database that contains 14 separate charts (4 line charts, 2 pie, 8 bar).  Data for these charts are all pulled from within this file.  This layout opens up fine (takes about 15secs on gigabit LAN) and renders everything as we would like it to.  It's a fairly intensive layout that has mostly current-record delimited charts compiled through relationships/scripts and also one primary chart that is done through the current found set and sorted for summary grouping.  We have another database file that tracks companies and contacts.  There is one layout that has the related sales prospects listed in a portal.  Prior to opening the sales dashboard, this layout can perform a script trigger-assisted find rather quickly -- in a matter of a few seconds.  The vehicle to help perform finds on this layout is a global text field with an OnObjectSave script trigger.  Once the sales dashboard is opened this layout will take 60+ seconds to perform the same find and show the hour glass/spinning ball for prolonged periods of time.  On the FMSA console, the statistics also jump up.  Elapsed time/call spikes upward.  This is while we have about 20 light to moderate users connect to the databases (they are not in the sales database).   With the script debugger enabled, we can tell that the slowdown/delay is taking place before the first script step can be displayed in the debugger.  When using the quick find toolbar or going into find mode in a field, the finds are fast. Once this sales dashboard is opened, the slow script-assisted finds persist.  When the the dashboard layout is closed, the slow finds still persist. The only way that we've found to resolve the issue is to quit FM and relaunch and avoid opening the sales dashboard. When connecting from another computer, there is no apparent performance hit when using the scripted find (unless they too open the sales dashboard).   Exact steps to reproduce the issue: not sure if this would reproduce it...1. Host a bunch of databases2. Create a layout on an interface-only file that puts a lot of related data together into one layout with portals.  This file would have data sources and TO's based on data in other files. 3. Create a complex charting layout in one of the files.  Open it. 4. Attempt to do object-level script trigger find with a global field back in the other interface file. Expected Result:Successful find operation completed within a few seconds. Actual Result:Spinning ball or hour-glass delays for over 30 seconds followed by successful completion of find operation. Exact text of any error message(s) that appeared:No errors appear. Any additional configuration information/troubleshooting that is relevant to the issue:Object level scripts triggered on non-global fields for searches have no latency problems.Reconfiguring the global field's script for OnObjectExit also exhibits the same delay.Typing in the global field in browse mode (no keystroke trigger enabled) is noticeably slower to display typed text after the sales dashboard is opened. It feels as if FMP is suddenly too busy.Clients running FMP11 on different OSes all exhibit the same problem.Global field with script trigger in the sales dashboard file itself is oddly not slowed down. Other clients do not have any apparent performance issues. Any workarounds that you have found:None yet.