AnsweredAssumed Answered

Design principles for performance

Question asked by NickLightbody on Oct 7, 2014
Latest reply on Oct 15, 2014 by 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


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


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

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


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


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.




Nick Lightbody

October 15th 2014

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



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