3 Replies Latest reply on Oct 27, 2016 5:43 PM by Vaughan

    Master record list can negatively impact performance?

    BillisSaved

      Good afternoon everyone,

       

      I hope your day is going well. I was recently watching the Under the Hood: Server Performance presentation from FileMaker Devon 2016, presented by Jon Thatcher, and I'd like to find more information on a particular topic that he mentioned during his talk. Assuming I understood him correctly, which may not be the case, there is a Master Record List consisting of a small amount of data representing each record of a layout's underlying table. This information is moved from the server to the client when a layout is loaded, even if the layout is empty. Jon mentioned that viewing a layout based on a table with say one million records could have a dramatic negative impact on performance. Does anyone know of a knowledgebase article or white paper that explains this FileMaker attribute/process in detail? Thanks in advance for any assistance and/or advice you are willing to provide!

       

      God bless,

       

      Bill

        • 1. Re: Master record list can negatively impact performance?
          electon

          Not sure it there's a white paper on this.

           

          It basically comes down to this:

           

          If the layout is associated with a table, at the moment the layout loads the client will ask the server for the Master Record Table of that particular table.

          This master records table contains record id's of all the records.

          Those are internal to FileMaker and have nothing to do with any primary keys you defined yourself.

          You can find this out with Get ( RecordID ) function.

           

          Each record ID is 1 Bit in size ( at least what was said in the video ).

          Data is sent in chunks ( around 1500 bytes per chunk ) which makes up for one round trip.

          The more records in the table the more data ( record id's ) need to be downloaded from the server.

           

          Depending on the network speed and latency ( remember round trips, packets need to go back and forth ) it takes time to complete the process.

          A round trip could be:  Server Sends Data, client accepts and sends Acknowledgment back to server.

          The latter could be a small bite size but if latency is high, the server will wait longer until it hears back from client, the client will wait longer for new data to come in.

           

          I'll omit the fact that packet acknowledgment can be bundled up which helps a bit...

           

          Therefore it is in general better on startup to go to a layout which has few records or none at all.

          Eventually one might want to go to that layout and it will need to be downloaded, but it's more about the perceived "Solution Startup" speed that clients might find annoying.

          Once they're in you can make further decisions on that to do next.

           

           

          HTH

          Thomas.

          1 of 1 people found this helpful
          • 2. Re: Master record list can negatively impact performance?
            BillisSaved

            Good evening Thomas,

             

            I hope your day is going well. Thanks so much for your detailed reply! So, in a production solution the ideal situation, from a performance perspective, would be to create a table with no fields and load a layout based on that table first? Thanks and have a great evening!

             

            God bless,

             

            Bill

            • 3. Re: Master record list can negatively impact performance?
              Vaughan

              The issue is more about perception of speed, and doing things only when needed.

               

              If the solution has a little-used table of thousands of records, don't touch any layouts associated with this table until it's needed.

               

              I've seen a couple of solutions that display a splash screen, then change to each table and show all records, then go to the home screen. The rationale for this may have been that there were saved found sets in some tables, and this process clears them.

               

              Knowing that changing to a layout causes the master record list to be pulled down, it can be seen that the process of going to each table and showing all records is a resource-intensive action and on a slow network will be painful.

               

              A better way would be to keep track of which layouts have been visited and show all records only when necessary.

               

              The best method is to set up a script that does this process when the file is closed (not opened) if and only if the file is opened locally and not hosted in FMS. That's because the found sets are only saved when the file isn't hosted.