1 pointThe behavior is similar on macOS and Windows. Getting more cores is typically cheaper on the Windows side of things, high-core machines on the mac side typically have a lot of extra hardware (GPU,...) that FMS does not need and that drive the overall price up. As to whether you will benefit from more cores: the only answer can come from your current performance baseline. Mainly your stats.log and to some extent the TopCallStats.log. Any server has 4 potential bottlenecks: processing power, disk i/o, memory and network throughput. In the FM world it is typically processing power and disk i/o, depending on the total user load, the nature of the solution and the design/architecture of the solution. If processing power is not your bottleneck then you won't get benefit from adding more. FMS can take advantage of more cores depending on the type of activity. If you use PSoS a lot, or server-side schedules, or WebDirect or any other kind of server-side activity, then absolutely. Here's a good recent discussion about processing power for FMS18: https://community.filemaker.com/en/s/question/0D50H00006tgeVdSAI/fms18-any-definitive-documentationevidence-of-multicore-use The shot version: figure out from your stats.log where your bottlenecks are, add more resources to the bottleneck area.
1 pointHello, During the process of setting up a MirrorSync configuration, MirrorSync generates a FileMaker script that gets pasted into the syncing solution. In this script are all of the fields you specify to include in the sync. If changes are made to the structure of the database of which MirrorSync is not aware, it could result in an error. If a field is added to a sync layout---the layout specified in the configuration as the interface by which MirrorSync syncs data---changes to that field will be ignored. However, any changes to that field would trigger the modification timestamp to change, so MirrorSync will pick up on this discrepancy between the hub and spoke mod timestamps---the driving factor for processing changes---not find any field value changes, and may perform a slow deletion scan or run in recovery mode, which will slow down the sync process. If a field is added or the name changed, FileMaker will probably throw a "missing field" error because the Set Field script step in the MirrorSync script will try to write to a missing field. This will cause the sync to abort, or for changes to not sync properly. MirrorSync logs all sync activity, especially errors. Major errors like a sync failure can be reported to an e-mail specified in the sync configuration if you select this option. Any changes in the database configuration that affect the sync or cause it to fail will just register as a errors with MirrorSync. MirrorSync does not do a separate evaluation of the databases on both sides of a sync to ensure the schemas match up perfectly. This is assumed. How often are you wanting to back up your information? Are you wanting to perform a minute-by-minute back up to maintain data integrity? This is the scenario I imagine where using MirrorSync to back up your data would be advantageous. Otherwise, if you just want something like an hourly backup, if you're looking for a 3rd party app to back up your databases, we offer SafetyNet(https://360works.com/filemaker-offsite-backup/) which backs up FMS hosted solutions to Amazon S3. On the topic of schema changes, we also have a product, 360Deploy(https://360works.com/filemaker-deploy-versions/), that makes deploying new FileMaker database versions to your prod server very easy. I hope that answers your questions. Let me know if you have more!
This leaderboard is set to Los Angeles/GMT-08:00