4 Replies Latest reply on Apr 18, 2011 12:44 PM by BTimm

    Performance Fix: Layout / Portal Overload



      Performance Fix: Layout / Portal Overload


      I am trying to fix an all-in-one layout that was designed for client with 4 or 5 tabs and about 10-12 portals based on different relationships.  Each of the portals has its own pre-set sorts for this layout.   all of the portals are different paths to the same table in another FM database, but based on different relationships that were built pre-FM 11. 

      Issue: The whole thing is sluggish. Any change you make to a portal record anywhere on this layout takes a few seconds to commit. Enough to be major drag for users using this layout regularly.  In addition, I've been able to confirm that the performance drag also occurs if you are working in a second window making changes on another layout, but also have this layout in the background still.

      100% confident I've narrowed the issue down to this layout, and pretty sure it is because of the many portals present. Suspicion is that any single change is updating the record order on all of these separate portal displays. Unstored calcs or fields are not an issue. 

      So, my first solution was going to be a multi-layout adventure to separate all the portals, but then just use simulated tab headers and nav links to simulate the whole thing as one layout experience for the end user.

      New thought today, though: if the problem is not because of the # of portals but the fact that they are all based on separate relationships (designed pre-11), could I take advantage of the filtered portal option, reset all the portals to work from one or two relationships, and the use filters for all the different displays thereof.

      Interested in any input here before I go too far experimenting. Not sure either one is a shorter path to re-develop. Main goals are to maintain single layout "experience" for user, but develop new layout architecture that solves the performance issue and is not too demanding to maintain for future layout changes. 

        • 1. Re: Performance Fix: Layout / Portal Overload

          I'd be interested to hear what happens if you take a copy of this file and delete the multi-tab layout, then test to see if you still have the same performance delays. I'm not sure that just having the layout in the database, but not currently visible can have any affect on performance here. If you have fields used in portal sorting schemes, however, I'd take a closer look at them and see if they are truly needed.

          • 2. Re: Performance Fix: Layout / Portal Overload

            I don't need to delete it to make performance issues go away. I just need to make it not visible.

            Ex: I have MultiPortal Layout open. From there I click a portal record that launches a 2nd window, which is a like a small popup for managing single records.  Any change I make on the popup take extra long to commit before I can exit fields.

            However, a successful workaround presently goes like this:

            I have MultiPortal Layout open, launch the single record popup. But before I make any record changes, I go back to the first window and just navigate to any other layout on the same table. Then, I can go back to my still-open popup and make changes with no speed issue at all. That seems to definitively point to some display issue: any change to a record forces extended refresh on the multiportal layout.

            • 3. Re: Performance Fix: Layout / Portal Overload

              That's what I expected to hear. It's the time taken to update the layout that's at issue here.

              What happens if you hide all the portals inside tab controls? (Make a tab that has no portal, give it an object name and use go to object to select it when you pop up the floating window.) I would expect that to also eliminate the update delays if the portals inside the tab control are the cause of the slow down.

              • 4. Re: Performance Fix: Layout / Portal Overload

                That's interesting. I'll have to try the hide-all test, but I already have all but 2 of these portals behind tabs.