Wim Decorte, Nov 8, 2018, DIGFM
Table of Contents
- Introduction
- Wim Decorte’s Journey with FileMaker Server
- Understanding FileMaker Server Bottlenecks
- Monitoring and Logs: The Key to Early Troubleshooting
- ZABBIX for Multi-Server Environments
- FileMaker Server Hardware: Cores vs Clock Speed
- Server-Side Activity: PSoS, WebDirect, and CWP
- Optimizing Disk I/O for FileMaker Server
- FileMaker Data API: Scalability and Use Cases
- Common FileMaker Server Performance Issues and Solutions
Introduction
In this comprehensive guide, we dive into FileMaker Server’s core functionalities, explore potential bottlenecks, and provide strategies for improving performance, scaling, and troubleshooting. This guide is heavily based on insights from Wim Decorte’s presentations, discussions, and hands-on experience with large-scale FileMaker deployments. Wim’s expertise spans from diagnosing performance issues to integrating FileMaker with IoT solutions and external APIs, particularly in high-demand environments.
Wim Decorte’s Journey with FileMaker Server <a name=”wim-decorte-journey”></a>
Wim’s career with FileMaker started in the 90s when a client needed a cross-platform database. This propelled him to dive deep into FileMaker Server performance, tuning, and troubleshooting. Over the years, Wim has tackled some of the most common and complex server-side issues, gaining a deep understanding of the technical demands that FileMaker Server solutions impose on hardware, networking, and server processes. His experience makes him a leader in large-scale deployments and optimizations.
In his presentations, he frequently highlights the following key lessons:
- Don’t guess—measure: Rely on logs and monitoring tools rather than guesswork when diagnosing server issues.
- Think ahead: Always plan for scalability, especially when deploying solutions that will grow in complexity or user count.
- Automation is key: Use tools like ZABBIX and Perfmon to automate performance monitoring and mitigate issues before they affect users.
Understanding FileMaker Server Bottlenecks <a name=”filemaker-server-bottlenecks”></a>
Performance issues in FileMaker Server are typically caused by bottlenecks in one or more of the following areas:
CPU Bottlenecks <a name=”cpu-bottlenecks”></a>
When CPU bottlenecks occur, they often manifest as long processing times or slow execution of complex scripts. FileMaker Server utilizes multiple CPU cores, but certain operations (like unstored calculations or PSoS scripts) may consume large chunks of processing power, leading to delays. This is especially critical for servers handling many concurrent processes or for WebDirect sessions, which can overwhelm CPU capacity if not properly optimized.
Wim recommends:
- Balancing cores and speed: High core counts help with concurrency, but don’t forget clock speed.
- Use PSoS carefully: Overusing Perform Script on Server can quickly overload the server if too many scripts run at once.
Disk I/O Bottlenecks <a name=”disk-io-bottlenecks”></a>
Disk I/O is frequently the biggest performance bottleneck in FileMaker Server environments, especially when large datasets are involved. Slow read/write speeds can cripple performance when multiple users are accessing records or when server-side processes require intensive data operations. This is particularly true for WebDirect and PSoS scripts that involve significant database interactions.
SSD vs. HDD: Always opt for SSDs over HDDs for FileMaker Server to reduce latency in data access.
Wim’s recommendations:
- Use RAID 1+0 (RAID 10) to ensure both redundancy and fast read/write performance.
- Avoid RAID 5 or RAID 6, as they tend to have slower write speeds, which can affect overall server performance during high load.
Network Latency <a name=”network-latency”></a>
Network bottlenecks are often overlooked but can significantly affect server performance. Even with a high-performance server, poor network conditions (latency, bandwidth limitations) can create lag for end users accessing the FileMaker solution remotely or over WebDirect.
Wim emphasizes:
- Server location: Ensure that your server is geographically close to the majority of users, especially for WebDirect or Data API applications.
- Network optimization: Use Gigabit Ethernet or higher to minimize latency between the FileMaker Server and its clients.
Memory and Cache Usage <a name=”memory-cache”></a>
Sufficient RAM is critical for FileMaker Server, particularly when managing large datasets or concurrent users. The server’s internal cache can speed up data retrieval if it’s adequately sized, but under-provisioning RAM can lead to frequent disk access, exacerbating Disk I/O issues.
Wim’s recommendations:
- Allocate enough RAM: FileMaker’s cache setting should ideally be set to at least 75% of available RAM.
- Monitor Cache Hit percentage: This metric helps identify if the server is frequently reading from the disk due to insufficient cache size.
Monitoring and Logs: The Key to Early Troubleshooting <a name=”monitoring-logs”></a>
Wim stresses that logs are invaluable for diagnosing server performance issues. Without proper monitoring, it’s nearly impossible to pinpoint the root causes of bottlenecks or to proactively resolve issues before they affect users.
The Importance of Stats.log <a name=”importance-of-stats-log”></a>
The Stats.log captures key performance metrics, such as memory usage, cache hit percentage, disk I/O rates, and network throughput. Wim suggests enabling this log immediately when setting up the server, even in environments that don’t experience frequent issues. The log data is critical for establishing a baseline of “normal” server performance, which helps you diagnose deviations when they occur.
Top Call Stats and Client Stats <a name=”top-call-stats”></a>
Top Call Stats provides visibility into the most resource-intensive calls made by users or server processes. This allows administrators to identify inefficient queries, slow-running scripts, or performance-intensive calculations. Client Stats show which users are placing the most load on the server.
In environments with frequent PSoS calls or WebDirect sessions, Top Call Stats and Client Stats are essential for identifying patterns that lead to server strain.
Perfmon Integration on Windows <a name=”perfmon-windows”></a>
For Windows-based deployments, Perfmon is an invaluable tool for monitoring FileMaker Server alongside system metrics like CPU, memory, and disk activity. Perfmon’s integration with FileMaker allows administrators to track FileMaker-specific metrics in real-time, providing a granular view of server health.
Wim shared examples of how Perfmon helped him diagnose server crashes by correlating FileMaker-specific data (like cache hits) with overall system performance (such as memory and CPU usage).
Enabling Monitoring Tools <a name=”enabling-monitoring-tools”></a>
To turn on logging in FileMaker Server, use the fmsadmin CLI:
fmsadmin enable serverstats
Make sure to enable Top Call Stats and Client Stats during troubleshooting sessions to track problematic processes.
ZABBIX for Multi-Server Environments <a name=”zabbix-monitoring”></a>
Wim highlights ZABBIX as a robust monitoring tool for multi-server deployments, allowing for centralized monitoring of server metrics across multiple FileMaker Servers. ZABBIX can be configured to send automated alerts when specific thresholds are breached, such as CPU usage above 80% or disk I/O rates that exceed a predefined limit.
WPE Monitoring with ZABBIX <a name=”wpe-monitoring”></a>
WPE (Web Publishing Engine) can be a significant contributor to performance issues, especially in environments with heavy WebDirect or Custom Web Publishing (CWP) usage. ZABBIX allows administrators to monitor WPE processes specifically, ensuring that web publishing activity doesn’t overload the server.
Wim recommends configuring custom triggers in ZABBIX to alert you when WPE processes spike unexpectedly, which could signal a misconfiguration or excessive load from web users.
Automated Alerts and Custom Triggers <a name=”automated-alerts”></a>
With ZABBIX, you can create custom alert rules based on specific server conditions. For example, you can configure the system to send an email alert when disk I/O exceeds 90% of capacity or when a server process becomes unresponsive. These alerts help administrators proactively address issues before they cause system-wide slowdowns or outages.
Performance Troubleshooting: Case Study <a name=”performance-troubleshooting”></a>
Wim shared a case study involving a large FileMaker Server deployment with over 300 users. The server began experiencing severe slowdowns during peak usage hours, leading to timeouts and frustrated users.
Case Study: Unstored Calculations Causing Slowness <a name=”case-study-unstored-calc”></a>
The root cause of the slowdown was a combination of unstored calculations and summary fields that were recalculating every time a user accessed the data. This was particularly problematic when users performed multi-table queries or summaries across large datasets.
Solutions Implemented:
- Pre-calculations: By shifting certain calculations to pre-calculated fields (which were updated periodically), Wim was able to reduce the server load during peak hours.
- Server-Side Scripts: Some of the more intensive calculations were moved to server-side scripts, ensuring that the server processed the data asynchronously, reducing delays for end users.
This case study highlights the importance of reviewing solutions for unstored calculations and summary fields, which can significantly impact performance in high-user-count environments.
Optimizing Scripts to Reduce Server Load <a name=”optimizing-scripts”></a>
Wim recommends reviewing all scripts for efficiency, particularly those that perform searches or manipulate large datasets. Common script optimizations include:
- Reducing the number of loops: Loops can place a heavy burden on the server, especially if they involve database actions like creating or modifying records.
- Avoiding “show all records”: In large databases, showing all records at once can overwhelm the server, particularly if summary fields are involved.
FileMaker Server Scalability: Virtualization and Cloud Deployment <a name=”server-scalability”></a>
As organizations grow, scaling FileMaker Server becomes a necessity. Wim frequently discusses the benefits and challenges of virtualization and cloud deployments for FileMaker Server.
Virtualization Best Practices:
- Dedicated Resources: Ensure that virtual machines have dedicated resources (CPU, RAM, and disk) to avoid resource contention with other VMs on the same physical host.
- Scaling Up vs. Scaling Out: For FileMaker Server, it’s often more effective to “scale up” (increase resources on a single powerful server) rather than “scale out” (deploying multiple smaller servers).
Cloud Deployments:
Cloud deployments, particularly on AWS or Azure, offer the flexibility to scale up or down based on demand. However, Wim warns that cloud environments can introduce network latency issues, particularly for remote users.
Conclusion <a name=”conclusion”></a>
By following the best practices outlined by Wim Decorte, you can ensure that your FileMaker Server deployment is optimized for performance, scalability, and reliability. From monitoring tools like ZABBIX and Perfmon to performance optimizations involving PSoS and WebDirect, this guide covers everything you need to know to run a smooth and efficient FileMaker Server environment.
All Things Server +Community Roadmap (11/8/2018; DIGFM)
The resources Wim and Steven Blackwell created for FileMaker Server 17:
FileMaker Server 17 Admin Console
