Schwarz Software, Perth, WA
Schwarz Software Blog
How to monitor WAN network traffic for FileMaker Server Clients.
Posted 12th December 2016
Are you hosting your FileMaker solution in the cloud, or are others accessing your solution remotely? If so you need to be much more careful with the design of your solution to ensure that it is still usable remotely! There is an excellent free tool called GlassWire that can be used to debug your FileMaker Pro solution piece by piece and work out where your remote slowdowns are occuring, and exactly what is the cause. The cause of remote slowdowns aren't necessary the volume of network traffic, but in FileMaker Pro's case could also be very low volume 'chatter'. I recently had a solution that had a UI that had lots of conditional formatting, the UI was computationally high. A small amount of traffic was preventing remote users from using the UI. My technique for debugging the problem was: - Open Glasswire and move to the "apps" tab under the tab "Graph" and select FileMaker Pro
- Open to the Layout in FileMaker where the slow remote access performance occurs
- Remove all objects from the layout and monitor your network traffic. The network traffic should be almost zero, FileMaker will send a 'heartbeat' back to the server. If there is substantial network traffic then you may have a script running on a timer, or you may have a corrupt layout.
- Add UI objects back to the layout one by one and monitor the change in network activity with GlassWire
- You can also debug scripts, buttons, value lists, etc. by clicking on them and monitoring the response in GlassWire
The UI element that slows down the WAN access will likely be slowing down your UI because
- It has dependencies on a large amount of data, e.g. it is a calculation field that references lots of data, or it has conditional formatting or a hide condition that references lots of data.
- It has dependencies based on tables that are changing very frequently. Note it may reference a field that isn't changing, but if the field is part of a table that is changing then FileMaker will still pull that entire record down again.
- Or a combination of the two.
- Or you are using a SQL statement, SQL will pull data from the entire remote table to execute - this may change in the future but is true at FileMaker version 15 and below.
Now that you have found your issue by using GlassWire you can optimise your solution to get LAN like performance with your WAN solution.
Tips for optimising your solution:
- Store values rather than use a unstored calculations.
- Use "skinny" tables. FileMaker Pro will draw down the entire set of stored fields in a record just to retrieve the information from 1 field (container fields and unreferenced unstored calculations excluded). Note, that using skinny tables is very useful for speeding up the opening time of Value Lists. An easy way to create a skinny table is to create a copy of your main table with only a few fields that is updated when required.
- Use "Perform script on server" to prevent your users from waiting for scripts to run
P.S Accessing your solution remotely via WebDirect can often be faster than accessing your solution remotely via FileMaker Pro if the distance or lag between yourself and the server is high.
You can use glasswire to monitor traffic and lag for any remote client, e.g. FileMaker Pro, GO, Webdirect, PHP API, XML, ODBC etc.