How can you get the best out of a new FileMaker Server Deployment?
GENERAL Advice on deployment factors
It can be difficult learning how to get the best out of FileMaker Server as specific authoritative published advice is limited. I have been mentoring other developers over the past year, based on my new research which I have published in order to improve the understanding of this technology. Having had some good responses I thought it would be useful to publish an overview here of what to think about when planning a FileMaker Server deployment.
Fundamental to my approach is to observe carefully and to measure wherever possible. Hence the free and open source App dsBenchmark I developed last year as a method of comparative load testing of different deployments of FileMaker Server. You can find dsBenchmark, in English, Chinese, French and Spanish here:
Basics: you are very much better off performance wise using FileMaker Server 15 which offers significant improvements over FileMaker Server 14.
1. IO: The biggest factor is to deploy with the fastest possible IO, so bus speed, RAM speed and disk read-write speed is the first thing to get right. Hence SSD or better storage is optimal. I generally use mirrored RAID myself on the precautionary principle, but, provided you set up FileMaker Server incremental backups efficiently, the priority for mirrored RAID requirement clearly reduces, so there may now be a case for faster striped RAID? The key thing to bear in mind is that FileMaker Server makes many small read and writes so optimisation for that behaviour is essential.
2. STORAGE: the amount of disk storage required is based on the size of the database and planned backups, allowing for the planned deletion of old backups by FileMaker Server, and you then need to add the amount of disk-space required by the OS for use as temporary memory. The outer sectors of rotating media provide faster IO than inner sectors, this is one reason why rotating media which are more than half empty are always faster, but it is much better to use SSD or better if you can in which case rotational factors will not be relevant.
3. POWER: Clearly the faster the box / virtual boxes that you use the better.
4. CPUs: I have seen conflicting views on the efficiency with which FMS manages multiple CPUs. I believe that FMS can treat one vCPU as 2 “virtual” vCPUs, but I am not current sure of the constraints on this behaviour. If anyone can share their knowledge on this please do so. It is certainly the case that each recent version of FMS has become progressively more efficient but I can currently give no definitive advice on the extent to which many vCPUs would be of benefit. My advice is to start with 4 and then if possible track the load and performance and then experiment with more and observe the difference. I assume here that the virtualisation being used means that the deployment can be conveniently adjusted in this manner.
5. RAM: Giving the box as much RAM as possible is always a very good idea, but, it is also very important not to give FileMaker Server any more cache than is strictly required.
It is a very common error that folks confuse FileMaker Server cache with RAM available to FileMaker Server. Increasing the FileMaker Server cache setting reduces the amount of RAM available for the OS and every application running on the box including FileMaker Server.
This may result in very poor performance as the OS and FileMaker Server itself is starved of RAM.
Hence as noted above watch the stats and optimise the FileMaker Server cache setting so that the cache hit rate shown in the FileMaker Server Admin Console Statistics is 99% and then increase it a little so that it is just on 100%.
SPECIFIC Advice on deployment factors
The following factors may result in the preceeding general advice being varied:
SIZE of dbase: a very large db will require more FileMaker Server cache, the old rule about watching FileMaker Server statistics and adjusting the FileMaker Server cache to run with a cache hit rate at just 100% still holds true, since it remains essential to use no more FileMaker Server cache than is actually required, as noted above.
NUMBER of USERS: the more users the more separate threads and the more CPUs required to run those threads in parallel, to the extent that FileMaker Server is able to make use of those CPUs.
MODE of connection: If WebDirect is to be used, and in my experience it is far far better than some folk suggest, then you do require sufficient RAM for all those WebDirect client sessions on FileMaker Server. With FileMaker Server 14 each session required about 250mb RAM (not FileMaker Server cache) based on my measurements when 14 was released. With FileMaker Server 15 that number is I think somewhat smaller but I have not yet remeasured it myself.
The EFFICIENCY of the SOLUTION: this may make the biggest difference of all. A well designed modern solution will run so very much faster in all respects. If the solution is legacy, ie it was designed for any version of FileMaker pre 14, or prehistoric as in pre 12, then taking steps to improve how it handles the Appearance Layer, i.e. using styles and themes effectively, will make a significant difference. Older solutions often have wide tables (many fields) and taking steps to reduce table width will pay dividends as will avoiding permitting the current user layout to be based on a table with many records wherever possible. As you know there are many ways in which a FileMaker solution designed sometime ago can run very slowly, purely because of a design which is far sub-optimal in a modern context.
Take a look at my posting here last week on Getting started building FileMaker Apps for WAN performance for some initial thoughts.
I will post more pieces on FileMaker Performance here in the future.
It will be very interested to hear your own observations on what you have found works for you? Please share your experience so we can all learn more together.
Cheers, Nick
Sussex, UK
August 28, 2016
