As the first of my series of performance-related interviews, on the 24th of October I had the pleasure to interview Wim Decorte from Soliant Consulting at the FMTraining.tv live stream. We talked primarily about Punisher, a tool Wim developed a few years ago to stress-test FileMaker Server.

 

Recording of the whole interview has been published on the FMTraning.tv YouTube channel and you can watch it right here:

 

Here's a brief recap of what we talked about: 

Punisher for FileMaker Server testing

Wim explained the use of Punisher, his tool for testing Filemaker Server's performance. Punisher allows for server-side testing, isolating variables such as hardware and network, and can be used to test different versions of Filemaker Server. Wim also highlighted the importance of the top call stats log for understanding operations and their impact on performance. If you want to see how Punisher works and how to use it, make sure to check the recording above.

 

"Top call stats log being off is borderline criminal, it should be on by default," Wim said...

 

I could not agree more. Top Call Stats are crucial to finding out what's happening on the server and the overhead of collecting the stats is negligible compared to what the server has to do, despite that Claris still warns about their negative impact in the FileMaker Server Help. The good news is that the default has now been changed to "on" in the latest version.

We discussed the impact of the Top Call Stats on server performance in a bit more detail. Wim emphasized that monitoring requires some processing and disk activity, but it should not be a reason to turn off logging. I agreed, suggesting that the amount of data logged should be considered in proportion to the server's overall workload. Furthermore, FileMaker Server only adds up to 25 lines per interval in this log, which limits the overhad to bare minimum. Wim would prefer more configurability in this feature.

We concluded that Filemaker is a tool best suited for specific tasks and excels in these areas, unlike other platforms like Oracle or MSSQL.

Pivot tool and common bottlenecks

Wim then showed how he uses the Pivot tool for analyzing the data collected by Punisher from different angles. He explained how to configure test runs, export results, and import them into a central repository. He also highlighted the importance of understanding potential bottlenecks in server performance, such as processing power, disk I/O, memory, and networking.

 

As Wim suggested, tools like Punisher can help identify these issues, such as impact of virtual machine types and configurations, spider-web relationship graphs etc. We also dove into some details about performance of virtual machines and cloud instances, such as the potential for performance drops when credits run out.

When discussing the inefficiency of giant spider-web relationship graphs in FileMaker, Wim suggested that this could be the most inefficient operation in the software. He explained the concept of permutations, leading to an exponential growth of peformance hit of any new table occurrence being added to an already large table occurrence group. I recalled my team's experience with optimizing a large solution by redesigning its spider graph to the popular "anchor-buoy" design, consisting of larger number of much smaller table occurrence groups, resulting in significant speed gains.

Valuable tool for your performance testing toolbox

There is no doubt that Puninsher is an extremely valuable, but not the only, tool you should have in your toolbox if you care about performance of your FileMaker Solution. It's available for free from Soliant Consulting's GitHub repository and watching my interview with Wim should be more than sufficient not only to convice you to use it, but also to show you how to set it up, how to run the tests, and how to interpret the results to get a real value from it.

Key characteristics of Punisher:

• It tests FileMaker Server power by running multiple simultaneous server-side scripts
• It is best to compare one server configuration variable change isolated from any others
• Use the Pivot tool to see impact of different variables
• It intentionally does things the bad, not the good way, in order to stress FileMaker Server as much as possible

Who's Next?

As mentioned in the beginning, talking to Wim was just the first of a series of interviews I have arranged to talk with various people about various performance-related topics. The next two have already been broadcasted as of this writing, one with Johan Hedman, discussing how different components of FileMaker Server affect each other and how you can get more out of your server by accessing the database engine via different channels simultaneously, and the other one with Vince Menanno, discussing his local file editing technique, also known as "being an optimist in the pessimistic world". I will soon also talk to Philipp A. Puls and Karl Jreijiri, who both have also valuable experience with FileMaker performance tuning to share.

While waiting for the next interview to watch or read about, you may want to check Initiative '24, our endeavor to convince Claris to make the FileMaker calculation engine significantly faster for everyone. And if you have already supported us by voting yourself, why not spread the word and convince your peers to vote as well?