In the previous article, we chatted about speeding up record creation and modification within our FileMaker applications. As we said, there's no one size fits all way to make an exotic supercar out of a minivan. However, there are ways to make that minivan corner smoothly and stop quickly and maybe even take off from the line like a dragster.
In this article, we're going to focus on ways to mitigate bottlenecks when we access our FileMaker apps remotely. Due to the pandemic, many of our users are accessing hosted apps from home. Of course, we do this over the internet, also referred to as a Wide Area Network (WAN). When we connect to the network at the office, that is typically a Local Area Network (LAN), which usually offers faster speed than a WAN.
With so many organizations moving their servers to the cloud and their work offsite, especially during the last few months, we're starting to see one of Claris FileMaker's weakest flanks. That is its performance in high latency environments. One of the truly great things about the FileMaker Platform is its fundamental dynamic nature. When we change a scripted workflow, a layout, or some of our data, all the users connected to that server see and can use it immediately. This allows folks to use and see improvements right away, which is great for productivity and overall user satisfaction. However, to achieve this, FileMaker constantly sends data back and forth from the server to the clients. And, because FileMaker is both an application and a database, that can end up being a lot of stuff.
Latency is the time it takes to send a data packet from the server to the client and back. It's expressed in milliseconds or ms. If our connection to the server has a long latency, like a lot of WAN based networks do, FileMaker can struggle mightily to keep everyone in sync, which inevitably slows down everything for everyone in the process. How do we get this minivan racetrack-ready? Well, FileMaker has recently given us some new high-performance tires to slap on the old jalopy in the form of the Persistent Cache.
The Persistent Caching feature was folded into the FileMaker Platform a few versions ago and can speed up our remote connections if properly leveraged. FileMaker has always created local copies of all the apps we connect to during a given session. A session is defined as the period we have the FileMaker desktop application running. As we make our way through the data and interface, FileMaker will save retrieved components on our computers, so that if we need them again, it can get them from the cache instead of asking the distant server for them another time. FileMaker used to delete this local cache when a session ended, so we would have to start all over with the next session. With the Persistent Cache, we don't have to ask for everything again. FileMaker retrieves the data from the local copy that is saved on our computers. Since many applications designed in FileMaker don't have tons of data and interface changes occurring daily, this new feature is pretty slick. In most cases, this happens quietly behind the scenes, but to take full advantage of this feature, we first need to understand how FileMaker finds records and how it returns the results to us.
When we search a hosted FileMaker app, it generally performs the find on the server and sends us back a list of record IDs that our desktop then uses to query the server to get the actual data. As we mentioned in our previous post, FileMaker always deals with its data on the record level. So we get all of the data regardless of whether the results of the find apply to all the fields in the layout we're viewing or not. If we're in a List View, we will typically receive all the data from the server for the records being viewed, plus 25. So although we get a list of all the server records, we don't get back all the data until we scroll past that 25 or so records, then the server will send us more. All this data we've requested from the server is now saved locally in our cache for later use.
To maximize this system, we can take it one step further, but we need to understand something else about FileMaker, and that is that the client, not the server, typically handle sorts. So if we perform a find and then sort the results, the server will be forced to send us all the record data for the entire found set, so that we can sort it locally, even if we're sorting on just one field. If we use the Show All Command and then sort on a field, we will have created a local cache of the entire table, potentially speeding up a lot of operations. What's more, we can script this operation and download our entire hosted file's data, while we go get a cup of coffee.
Now our mileage may vary depending on the type of data structure our app has, and the number of reads vs. writes it does through the day, week, month or year, but if our data doesn't change a whole lot, this can make our app scream down the track. We have customers who have their remote folks, run a "Cache Refresh" script every couple weeks, when their system seems to be getting a little sluggish and that is pretty effective.
Now that we understand how FileMaker works under the hood, we can correct any congestion that might hold us back. Based on how FileMaker sends and receives data over the network, we can leverage this behavior to add a few more improvements "the ole' grocery getter" minivan, making it lower to the ground and faster off the line.
So, we've discussed how to improve FileMaker app performance by optimizing searches and record creation/modification and improving accessibility at home or in the field. We'll close out this tune-up session with a talk about unstored calculations and how they can affect our system's overall responsiveness and user experience.
This article is also published on FileMakerProGurus.com.