Given the high wait times of your filemaker pro clients, I would assume that it is a bottleneck on your server side.
Have you considered offline sync solutions like MirrorSync or GoZync that do not require a constant connection to the server?
If your staff is only really transmitting once per hour, then I wouldn't see any reason to require a constant connection that times out, and has to attempt to restore?
Are the users closing the file and opening it every time? The long timeouts could be from suspended sessions of filemaker go trying to restore before eventually failing to reconnect.
I was looking for guidance on how wait time is measured:
1. From the moment instruction hits the server's buffer
2. From the moment a request is started by the client to when it's fully communicated to server and processed
You're confirming that the correct interpretation is no. 1. So I should not be looking at Wifi performance to fix the problem.
So I should not be looking at Wifi performance to fix the problem.
Not necessarily true. Long wait times can be caused by packets being dropped. I've seen it many times, and it's usually a bad piece of network hardware, or a poorly configured topology on the network (where the packets have to travel through an unnecessarily large number of switches). While your problem may, in fact, be server-side (as Mike B. has suggested), dropped connections is a red flag for a network issue. FileMaker, because it communicates constantly with all clients, is sensitive to network issues.
I would second Mike's suggestion to look at a sync solution if you're having connectivity issues. Not only will that eliminate the network issues, it will improve performance at the client.
You've already received some great suggestions, hopefully mine will help too.
In our experience we've also found that if your scripting has any heavy transactions to the server such as an unstored calculations or displaying found sets with unstored calcs or requires intensive indexing, this can cause the server to show such delays and therefore cause user problems especially with FMP13 where a connection is constantly maintained.
This problem is not so easily evident on a local network for ethernet users, but will show up with wifi users.
For example, one of our designers had a loop in a script that they failed to close properly, it caused the server to become so slow that it was impossible to use. Another time one of our clients had a returned found set that had many intense non stored calculations per record that simply caused their server to grind to a halt displaying similar results to yours.
So if you've tried looking at your servers cache, backup times (backing up a large db can cause performance issues during working hours), then I would suggest looking at your scripting just to make sure that nothing has changed or that what appears fast on a local network might appear slow over wifi.
I never replied completely to Mike B:
So what you're saying Mike B is: Spinning wheel = iPad trying to re-connect
I've got the iPads on the following regime:
1. iOS sleeps after 5 minutes
2. FM Go executes an On Timer script to do a refresh every 20 seconds
I don't think this regime will allow machines to log-off or fall asleep. So the spinning wheel is either because:
• there's no/low network connection or
• Server is taking its time responding to a specific request
Here's some more background. 20 patients and 3 staff updating a dashboard page. The system needs to refreshed regularly to allow users to see who has been allocated to each patient as this changes on an hourly & ad-hoc basis.
[My ISP went down for 30 minutes, so I'm just catching-up with reading the rest of the comments. I'll be back at my desk later today. Thanks everyone.]
The problem could be the onTimer scripts do not fire when the app is hibernated AFAIK. They will fire in sequence when you return the app to an active state.
If a user hibernated go for an hour, and you have a 20 second timer, that could potentially be ~180 scripts that filemaker needs to resolve when it reactivates. Have you tried it with the timer turned off?
Thanks all for your practical suggestions. Your responses indicate that the wait times could be caused by network or server delays.
To address the problem I'm going to do a few easy things first: upgrade to FM14 and migrate to a faster sever disk. Since posting my question I've been staring at the statistics section of the Admin Console:
It's inspired me to try identify the cause by correlating the "wait time per call" to other server events. For that I'm going to need to polish my limited skills with Windows Event Viewer! If that doesn't work I'll need to come back to optimising the code.
The reason why I don't want to go the MirrorSync or GoZync route is that it will force an expensive re-write. My understanding is that these synchronisation methods are best for when a small portion of the solution is made available on sporadic mobile (3G/4G) networks. My objective is to make the full solution accessible on the Wifi LAN regardless of whether one's on iPad or laptop.
If you have solid experience with this type of troubleshooting in a windows environment and want to do some consultancy work; please contact me directly detailing your experience. Thanks Kevin
You can import the log into a FileMaker database for easy searching.