In this fourth post of our Scaling FileMaker series, we share insights on troubleshooting complex and possibly interconnected performance issues.
Table of Contents: Scaling FileMaker Series
- Scaling FileMaker – Part 1
- How to Scale FileMaker with a Custom WebDirect Solution
- How to Scale FileMaker by Leveraging Load Balancers and Integrating FileMaker Server with SSO
- How to Leverage the Cloud to Troubleshoot FileMaker as Your Business Scales
- How to Identify and Resolve Server Bottlenecks in Your FileMaker Application to Encourage Scaling
When Scaling Causes Snags in Performance
Sometimes, you can follow all scaling best practices but still face performance issues. This can happen as you add more users in more places with more hardware. And frustratingly, these challenges can arise from several small factors working together or influencing one another, making the issue even more murky and difficult to diagnose.
In these cases, it’s tricky to establish cause and effect. You’re probably dealing with incomplete information and an overwhelming amount of it. A good analysis tool and a team of experienced analysts make a huge difference in uncovering and implementing a fix.
From Nebulous to Obvious: A Case Study
One of the most enjoyable aspects of being a long-time FileMaker consultant is watching clients grow and evolve over years, sometimes even decades. One of our long-standing clients in the clean energy business has experienced an explosion of growth. We’ve been there every step of the way to ensure their mission-critical FileMaker application supports this surge.
However, as with most technology during a scaling process, performance issues arose. The application would slow down often, making users stuck waiting for something to finish resolving. It frequently froze, causing disruptions to operations. Our team got right to work on uncovering the source of the problem.
The Cloud as a Troubleshooting Playground
Our team often starts with a lightweight and temporary AWS testing environment because we can run simulations of multiple (hundreds, thousands!) users in different locations and scenarios when working in the cloud. We can test more thoroughly with all available parameters and don’t put additional strain on the existing FileMaker application.
Hardware Exploration
With the cloud environment set up, we started experimenting with varying hardware scenarios – different servers, variable machine specs, more horsepower, etc. A faster server, for example, could easily be implemented on-premise, but it’s easier and quicker to test in AWS first.
For example, we tested faster servers for the application to see how it would impact performance. It turned out that an investment in faster servers wouldn’t fix the issues our client was having. We helped them avoid the expensive mistake of investing in more powerful hardware without understanding its impact first. A temporary cloud environment built for testing makes this possible.
Network Audit
We also investigated network issues. Our team leveraged Ping Plotter, allowing us to run comprehensive network tests from every user machine every second.
Latency Findings with AWS Local Zones
Fortunately, we learned that the network did not cause our client’s performance issues. However, we learned something more important.
As part of the network audit, we added AWS Local Zones to the pings, which allows us to see the latency impact of moving servers to AWS permanently. In an average case, migrating to the cloud can compromise latency; on-premise is usually faster and better.
However, our testing revealed that latency wouldn’t be worse on AWS, as most of our client’s users were near the AWS Local Zone. In some tests, the cloud environment even revealed improvements for some scenarios.
It’s important to note that this isn’t a hard and fast rule for all FileMaker users across the board – just because you’re near a Local Zone doesn’t mean latency won’t be affected. This is why having a thorough analysis team that evaluates your unique system is critical to its success. Sometimes, you’ll find improvements that wouldn’t work for others.
The big outcome of our network audit was the realization that moving to AWS permanently is an option for our client.
Feature & Functionality Testing
Of course, sometimes the real problem is one innocuous feature that seems so unproblematic from the surface. Our scenario testing typically starts with the most accessed scripts, tables, etc., hoping for something obvious to come to light.
Creating and Visualizing FileMaker Logs
Our FileMaker developers put a script in place to track the usage of various workflows and features. We then leveraged Grafana to visualize and graph these logs. We reviewed CPU, Memory, and other metrics visually, which made our investigation much easier. We regularly use tools like Grafana – and share them with our clients – to show how powerful a diagnostic process can get. The combination of these diagnostic tools with our data and metrics-driven approach to identifying and resolving performance problems made it possible to home in on issues.
Ongoing Server Monitoring
We regularly implement and manage server monitoring for many of our FileMaker clients using Zabbix. The tool is easy to launch on your own out of the box, although we recommend working with an expert to customize it for your specific application.
In a diagnostic setting, server monitoring can help you visualize how small variables within your solution work together to create a larger problem. We, of course, leveraged Zabbix in our investigative process for this client.
Finally, a Solution!
It took quite a bit of scenario testing to uncover our client’s biggest issue – an attachments table – and the cloud diagnostic environment helped us uncover the primary source much more quickly than if we had been manually testing. Without the cloud, we’d probably still be running different scenarios and banging our heads against the wall. As a bonus, we uncovered critical insights into the future of the application, something a less comprehensive evaluation process wouldn’t have accomplished.
Migrating to the Cloud
Because of our findings related to latency, our client decided to shift its FileMaker application to AWS via Soliant.cloud, our cloud environment built specifically for the Claris platform.
And it’s a good thing we made this move! Just a few weeks after migrating to the cloud, our client had a major network issue that would’ve caused an outage had they remained on-premise. They were relieved to avoid a potential significant disruption to their operations.
Working with FileMaker Troubleshooting Experts
A team well-versed in testing (and documenting those changes for you to reference later!) makes a big difference for your FileMaker application. A systematic method for tracking issues and attempted fixes is crucial to the process. Our extensive testing documentation for this client gives them peace of mind that we’re exploring every corner of the application for potential performance challenges.
Our clients benefit from working with not just a deep bench of FileMaker experts but also an experienced AWS Advanced Tier Partner. We have the cloud experience necessary to put a testing environment in place quickly and cost-effectively and can then help you launch long-term cloud infrastructure when you’re ready to take that step.
To learn more, contact our team today.