I run several mac mini servers, basically identical, each running FM Server.
On my laptop, I use FileMaker Pro's "Favorites" screen to open databases on all of them. Works great, except for one server, where there is a two minute delay before it opens the file. But if I close the file and re-open it, it's instant.
This sounds like the old case where FM would store more than one file reference to a database, and it would go through them in order one by one, waiting for the bad one to time out.
Details:
I'm on the local LAN, but am opening the files using the WAN (e.g. the actual DNS name), not the LAN IP address.
After I've opened the file once, if I quit FileMaker Pro, then re-open it, then it works normally again.
My laptop is set to sleep over night, and I believe it's this sleep which triggers the issue.
Edit to add: I also connect to these servers using Apple Remote Desktop, and I just noticed a similar problem. The "slow" server takes longer to connect using ARD (about 15 seconds) the first time, but afterwards is fast on the second time.
could be a DNS issue or if you connect ARD via IP address then it might be the server and could it be possible that it has some power savings settings turned on accidentally? going through the WAN when on the same LAN (same subnet?) could also point on the router. Are the other well behaving servers also on the LAN?
If you set up your internal DNS server to handle the DNS name you wouldn't need to go out to the WAN to come back in. If you don't have an internal DNS server get one (could be as simple as a Raspberry Pi with Pi-hole on it).
If this is just for you and you don't need to worry about other users, you could jus update the hosts file on your machine and hard-code the DNS name to your internal IP. Obviously won't work very well if you also really need to access that file when you are remote. Which brings you back to handling DNS
you may want to see if this helps:
quit out of FM
delete the FMP db cache folder
relaunch FM and see if the file opens faster.
if that works and it becomes slower over time again then the persistent cache in combination with the solution's design and opening sequence is working against you. If you are using FM 19.1 you can consider using the debug flag to use the old-style temp file instead of a persistent cache.
I am running my own router which is handling DNS (and does hairpin / loopback NAT automatically) but again the weird thing is I have 3 identical servers and only one of the three is behaving weirdly.
The fact that I see a delay on ARD (which has nothing to do with FileMaker) does suggest it may be DNS.
I've got more info on this slowdown upon first opening the database:
The problem happens both when accessing via a LAN, and also when using FileMaker Pro on the same machine (e.g. using localhost). This suggests it's not a networking issue.
The problem goes away if I reboot the server
The problem is worse the longer the server has been running
If I Sample FileMaker Pro when the slowdown is happening (using Activity Monitor), the stack trace has references to resyncing the temp file.
I belive what's going on is described here:
But there are some situations where having a persistent cache file causes problems. If the nature of your solution is such that users access large sets of records that are routinely modified by others, then those records will always have to be redownloaded to the cache file. To determine if this needs to happen, the client will compare what it has in its cache file to what the server has in the hosted file. This comparison operation can take a while. All this can be seen in the top call stats log as “Compare Modification Counts” and “Download Lists” operations. In this kind of scenario, starting with an empty cache file might be preferable.
(this is talking about FileMaker 19.1, but I'm using FileMaker 18).
It feels like what's happening is the Cache file on FMServer is growing and for some reason never gets cleaned out. Rebooting the server resets this, at which point everything is fast again.
Other than upgrading to FM19, I wonder if there's anything I can do, other than rebooting the server every few days?
I am just wanting to share a solution I found to slow FileMaker Go access (or even slow in general from the web or Mac or windows app) to a FileMaker Server. I’ve been running FileMaker for decades and for years I have struggled to get good access especially from Australia when my server is in the US. The blame is generally put on “your database is too complicated” or “you have too many scripts” or whatever but I never bought that. Many people have simple small databases that also are slow and take forever just to open.
Anyway I don’t have an answer for why, I think FileMaker is just rubbish in operating over the internet.
I have a new solution though that is literally night and day difference. Databases open and are usable (almost) as though the server was on your local subnet.
The answer: Tailscale. I do not work for them or have any affiliation. The free version allows 100 devices and 3 users. But have everyone just log in under the same user and add their machine. It’s a mesh VPN. Normal VPNs always helped me a tiny bit with speed but Tailscale basically solves the problem. I’ve tried on Mac and iPhone and iPads. It’s all instant now. Just make sure all your devices including your server are all on Tailscale and it’ll solve all FileMaker speed issues, if your database is already working well locally.
Hope this saves some people years of headaches that I’ve experienced.
