4 Replies Latest reply on Jun 10, 2011 6:33 AM by CS8

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

    viscous_1

      Summary

      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.

        • 1. Re: Chart-filled dashboard causing client script trigger slowdown on hosted solution
          TSGal

          srsa41:

           

          Thank you for your detailed post.

           

          Does this occur if you have the files hosted locally?  Are you able to narrow it down a bit further?  Instead of trying to replicate your scenario, is it possible to send us a sample file?  It will make testing and location of the cause much quicker.  I have sent you a private message (top of this page - right side - envelope icon just below the blue horizontal bar) with instructions where to send the file(s).

           

          TSGal

          FileMaker, Inc.

          • 2. Re: Chart-filled dashboard causing client script trigger slowdown on hosted solution
            viscous_1

            TSGal, thank you for the prompt response.  I have pulled the most recent backup off of the server and tried it locally on a Mac client--the same problem occurs.  Spinning wheel with delay as soon as the chart layout is opened.

             

            It will take me some time to set up the sample files to send over.  The data is confidential in nature and the solution is a bit crazy (built up by eight different devs over ten+ years) and complex, so would require some re-working to strip it down.  I would also have to send over a minimum of three files that are referenced with the data (data separation model in play).  Heavily indexed files too.

             

            I understand that it's obviously easier to see what's wrong with a sample file then to try to shoot in the dark to create a similar setup.  I'll try to have this over to you some time next week. Who knows, I might even be able to find the problem once I put more time into it. 

             

            -srs

            • 3. Re: Chart-filled dashboard causing client script trigger slowdown on hosted solution
              philmodjunk

              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.

               

              That may be a key clue. I've seen that occur on my systems when I have more than one window open and one of the background windows includes controls that need to update periodically as other users create and modify records. The background windows were not at all elaborate in their design. It appears that Filemaker is expending processor cycles to keep these background windows updated even though the user can't see them. When I use code to close or hide the other windows, performance improves.

               

              Sound familiar?

              • 4. Re: Chart-filled dashboard causing client script trigger slowdown on hosted solution
                CS8

                I am experiencing exactly the same problem on a solution displaying a bar chart in one window and then launching a long script in another window that reads and writes one record at a time.

                Without the chart dashboard window open the script performs under one second. With the chart dashboard open it can be as slow as 20 seconds with CPU usage spiking to 100 %. (this is on am Intel Dual Core 2 Duo CPU Macbook Pro and SSD).

                Oddly, a complex script on the same window and file of the chart dashboard executes without delay. It seems the issue arises only in referenced files while the chart window open in the background.

                Also, hiding the chart in a separate tab panel does not change anything.

                I'm wondering if there are any known solutions to this problem and whether example files could help.