8 Replies Latest reply on Oct 15, 2014 2:14 AM by NickLightbody

    Design principles for performance

    NickLightbody

      Here is a summary of my views on how to design for performance - with which I have no doubt that there will be many differing opinions.

       

      Mine are just based on my 16 years of working almost constantly with FileMaker - specifically for knowledge workers - as opposed to widget sellers - and particularly the past 3 years when I have been completely focused on developing WAN performance and simplicity - many others will have spent longer at this particular coal face. Some of the principles I believe are important may not be as important if you operate in the world of inventory control and selling widgets where priorities may differ.

       

      So I invite everyone who in interested is getting the best - performance wise - out of their FileMaker Apps / Solutions to disagree with and/or add to this thread with the object of establishing a set of authoritative principles. In the event of your agreeing with at least some of what I propose - that will be good too.

       

      1 - simplify - simplify - simplify (see https://fmdev.filemaker.com/message/159332)

       

      use Omnigraffle or a similar tool to help you design a single file solution which will reside on the server - work out your wireframes, core relationships and workflows all before you start building your solution - especially

      if you want to use WebDirect

      if you want your development cycle to be reasonably short

      think about user access rights from day 1

      design a user access hierarchy

      order your tables layouts and scripts according to what level of user will have access

      name them accordingly so that access control is easy to administer

      only include what 80% of users require

      supress that ego - don’t include everything you can create!

      only use simple Ui elements

      use shadows and gradients very sparingly - skeuomorphism is unnecessary, slower and distracting

      ensure that any pngs are optimised for your purpose

      give users an efficient method of record "list management" - so it is easy to create and display sub-sets of records

      avoid permiting users to "show all"

       

       

      2 - create efficient relationships (see https://fmdev.filemaker.com/message/160877)

       

      ensure no unstored calcs are used in any relationships

      use auto-enter - with replace existing

      with efficient relationships portal filters are also efficient - use them (see https://fmdev.filemaker.com/thread/78666)

      avoid anything that can display very many records - portals done right are more efficient than lists

      consider using a relationship based method of only showing users the records to which they require access - so FileMaker has many fewer records to deal with over WAN for each user

       

       

      3 - reduce FM caching

       

      understand the how, what and why of FM caching

      design isolated purpose orientated table occurence groups

      eg startup, record creation/deletion, browse, report etc

      control and reduce indexing

      stop indexing of all fields except those that require indexing

      use as few fields as possible in any table

      think carefully before adding more fields

      ensure that you do not permit indexing to occur unless necessary

      find through efficient relationships - try not to use find mode

       

       

      4 - use server side scripting (sss)

       

      use sss for record creation, deletion and manipulation

      this will typically take about 1/20th - 1/50th of the time it takes to run locally

      build scripts that you can run either locally or sss

      this should be automatic so they run sss when possible unless the file resides locally or you want it to run locally

      develop locally then switch to run sss

      build an event logging system to help debug sss

       

       

      5 - use Themes effectively

       

      create a layout containing all the types of layout object you plan to use

      set each to appear as you wish using the default style fo that object - i.e. change the default style to suit your needs

      then create variations of the default styles for other purposes

      name your styles consistently

      remove all styles you don’t require

      remove all local styles

      use a tool to identify and remove local styles

      be aware that new local styles will be created by the automatic insertion of field labels

       

       

      6 - deliver user interface language efficiently - (see https://fmdev.filemaker.com/message/160098)

       

      you need to be able to edit your ui language without editing every screen

      use global variables to display the Ui language on layouts and in dialogues - don’t use global fields

      the only place you are stuck with fixed language is in record validation messages

      build a language table to contain all the language items

      publish the contents of this table to global variables on user startup

      this makes it easy to build multiple language versions if required

      use repeating fields within your language table to facilitate multiple languages

       

       

      7 - manage your development professionally

       

      include a version history table in every file

      create new version history records at least every day during active development work

      save a copy of every version

      so you can revert if necessary

      save copies of your Theme regularly named with version numbers

      so you can revert if necessary - for example if a Theme becomes corrupted

       

      8 - manage a secure, effective and efficient deployment (this section contributed by Wim Decorte)

       

      understand all the FMS configurations options and their implications. Especially around security and performance

      understand how to interpret the FMS logs

      understand the FMS best practices, document why and where the deployment deviates from them

      understand how to set up and interpret FMS performance monitoring

      establish a baseline of performance data after each new version of the solution is deployed --> it will give you something to measure against

      be platform agnostic; learn the ins and outs of what your customer's chosen technology is

      set up and enforce procedures (backup restore testing, FMS installation and configuration,...)

      do periodic reviews of the logs, the configuration and the performance monitoring to see how the machine holds up and what the projected growth is (solution complexitiy, # of users, ...)

      do periodic reviews of the FMS deployment against the best practices, update the documentation

       

      9 - measure the performance of different aspects of your solution or App over WAN and compare with performance data standards (see https://fmdev.filemaker.com/thread/78194)

       

      this section has been added to link into the FileMake Performance Data Project which aims to facilitate developers contributing their own performance daat in order to share and compare that data with others.

      this project aims to establish performance norms for different types of deployment hosted with different resources to enable developers to judge whether and to what extent their solution or App is performing as well as current technology will permit.

       

       

      Cheers

      Nick Lightbody

      October 15th 2014

      Contributions: Section 8 contributed by Wim Decorte - thank you Wim.

      [ENDS]

       

      Message was edited by: Nick Lightbody to incorporate the contribution of section 8 by Wim Decorte

       

      Message was edited by: Nick Lightbody to add Section 9 linking in the FileMaker Performance Data Project

        • 1. Re: Design principles for performance
          wimdecorte

          Excellent write-up.

           

          The one thing I am missing in all of this is the deployment.   You design the deployment in the same fashion as you design your solution.  And the solution will be deployed a lot longer than it is developed:

           

          http://www.soliantconsulting.com/blog/2013/01/development-vs-deployment

           

          You can do the most efficient solution design but if it is deployed in a way that is not tailored to the task at hand, it will all have been for naught.

           

          As developers we are also responsible for the efficient design of the deployment.

           

          Wim

          • 2. Re: Design principles for performance
            NickLightbody

            Hi Wim

             

            Agreed 100%.

             

            Can you offer some key pointers to an efficient deployment design - perhaps an exec summary of your document - which we could perhaps add as para 8 - appropriately attributed - with the link to the full version?

             

            I am grateful for your response

             

            Cheers, Nick

            • 3. Re: Design principles for performance
              wimdecorte

              Just a few random ones:

               

              1) understand all the FMS configurations options and their implications.  Especially around security and performance

               

              2) understand how to interpret the FMS logs

               

              3) understand the FMS best practices, document why and where the deployment deviates from them

               

              4) understand how to set up and interpret FMS performance monitoring

                4a) establish a baseline of performance data after each new version of the solution is deployed --> it will give you something to measure against

               

              5) be platform agnostic; learn the ins and outs of what your customer's chosen technology is

               

              6) set up and enforce procedures (backup restore testing, FMS installation and configuration,...)

               

              7) do periodic reviews of the logs, the configuration and the performance monitoring to see how the machine holds up and what the projected growth is (solution complexitiy, # of users, ...)

               

              8) do periodic reviews of the FMS deployment against the best practices, update the documentation

              • 4. Re: Design principles for performance
                itraining

                Hi Nick

                 

                #4 has me a bit stumped.

                I can envisage SSS for deletion and manipulation of records.

                How do you create a new record using SSS?

                Is the server-side record creation creating multiple records in a loop, above and beyond a single record created by the user?

                 

                Thanks in advance.

                 

                Michael Richards

                Brisbane (Australia)

                 

                4 - use server side scripting (sss)

                 

                use sss for record creation, deletion and manipulation

                • 5. Re: Design principles for performance
                  NickLightbody

                  Hi Michael,

                   

                  To create new using sss you need to pass the intended data to the server side script as a parameter - generally a series of pairs, labels and data in one of the many variations that various very clever folk like Ray Cologon and Alan Stirling have created - then pass the record ID back to the user session as a script result.

                   

                  There are several considerations in doing this well and I plan to do a document on the method I have found works well. Howard Schlossberg is very good on this.

                   

                  Briefly you need to account for the server file startup script running at the beginning of every unique user session - ie on every script call - and so control that start up script to only do what you want when calling sss. The server log will pick every error wich is useful but adding a server event log which can capture what is happening in the server side user sessions will make debugging much easier.

                   

                  Cheers, Nick

                  • 6. Re: Design principles for performance
                    NickLightbody

                    Thank you Wim - very helpful - Nick

                    • 7. Re: Design principles for performance
                      beverly

                      Awesome statement, Wim!

                       

                       

                      On Oct 7, 2014, at 1:24 PM, wimdecorte <noreply@filemaker.com> wrote in whole or in part:

                       

                      As developers we are also responsible for the efficient design of the deployment.

                      • 8. Re: Design principles for performance
                        NickLightbody

                        Sorry for my very restrained British thank you Beverly and Wim - with our known preference for deliberate understatement you will know what I really mean :-)

                        Cheers, Nick