Improve WAN in FileMaker

Top-2 Tips for Improving WAN in FileMaker

Lately, there has been an increased emphasis on WAN performance in FileMaker solutions. The pandemic likely influences this; with more and more people working from home, many FileMaker solutions that used to be accessed strictly from a local area network are now being used over the wide-area network, aka WAN.

I’m sure some of you, or most likely, some of your users, have started to complain about your solution’s performance.

There are many good resources out there that cover this subject. I’ve listed a few here:

• WAN solutions on the FileMaker platform – Overview and Troubleshooting
• 7 Factors that Affect FileMaker WAN Performance and Hosting
• FileMaker Server Performance Improvements in 19.1.2
• WAN Performance Data Monitoring tool

In this article, we won’t dig too deep into all possible root causes of WAN performance issues. Instead, I’m going to follow the 80-20 rule and detail two things you can do that will most likely improve your solution’s WAN performance.

Tip 1: Update to the Current Version

My number one tip is to stay current. The Claris FileMaker engineering team is well aware of the performance challenges we are facing, and they spend most of their resources improving it.

Improvements can be seen with new features that came out in the past few updates.

Engineers at Claris can address issues we cannot address as solution developers. So when they listen to our feedback and release improvements accordingly, leverage them.

I know new versions feel intimidating sometimes, but don’t be afraid. Moving forward, we will continue to publish information about the most recent feature releases and best practices for utilizing them. For example, for the latest release of FileMaker 19.5, we published this article to explain it in more detail.

Tip 2: Leverage Server-Side Computation

Too many remote calls are probably the most common cause of WAN performance issues. Simply put, the time it takes for data to travel between your FileMaker Server and FileMaker Client is amplified by the number of remote calls between them.

When you work in the local area network, the server and client travel time is negligible, so you might not notice it.

But in the wide-area network, let’s say it takes 100th of a second for data to travel between your server and clients, which is already a very optimistic assumption. For a script that only requires 100 remote calls to finish, the lag introduced by remote calls is about 1 second. But for a script that takes 10,000 remote calls to finish, the lag is about 100 seconds—almost two minutes. And without consciously leveraging server-side computation, the latter will be the typical case. So how do you leverage server-side computation?

Using WebDirect

First, try WebDirect. Some of you might have already noticed that your solution feels faster when accessed via WebDirect. This is because WebDirect uses a web browser to act as its client. A web browser is nowhere as powerful as FileMaker Pro or FileMaker Go, so when using WebDirect, FileMaker automatically offloads a lot of the heavy work to the server to compensate.

Of course, there’s a tradeoff. WebDirect has some limitations compared to FileMaker Pro or FileMaker Go. You will need to make some adjustments to ensure WebDirect supports all major features needed in your solution.

Using PSOS

If you don’t want to use WebDirect, try the Perform Script On Server script step, commonly known as PSOS.

The key thing to understand about PSOS is its running context. Using the PSOS script step is equivalent to having a user log in from the server machine, wait for all triggers to fire and then perform the script you specified with the parameter you specified.

Beware: it does not know which layout the user was on before running the PSOS script step. It also does not inherit the found set the user had.

Because of that, moving business logic to the server side is not as simple as replacing the Perform Script script step with the Perform Script on Server script step. For all scripts you want to run on the server-side, you must first make them context-independent. A PSOS script cannot depend on the user being on a specific layout, records, or particular mode. You need to provide that information to the script as parameters so that it can run from anywhere.

Here’s an example:

We have a script that finds all related contact records for the current company and deletes them. It will work fine if I attach it to a button on a layout based on the Company table.

What do you think would happen if I call this script using Perform Script on Server instead of Perform Script without any modification?

When I have this script run on the server, the server session doesn’t know which record I was on. When the script session logs in, the system lands the session user on the first company record. So the server session will run the script from that context. Because of that, the server-side script will delete the first company’s contacts instead of the one I’m on.

How do I convert it to be context-independent? I need to tell it which client it should operate on.

The script above transforms the context-dependent script into a context-independent one by taking the company record’s primary key as a script parameter. So it will always know which company’s contacts should be deleted.

We can refactor it further by removing some redundancies, and that gives us the script below:

These are my top two quick tips for improving WAN performance. We hope that these tips are helpful for you and that they expedite your WAN performance. If you prefer to learn in video format, we’ve also created this video on the topic.

Happy developing!