We don't expect much from 3G. But there is slow 3G and fast 3G. The bars are not really a good source of information. Get the SpeedTest app for iOS and run that and it will show you representative speeds wherever you are. Once you see them, you'll understand why 3G isn't that good for Go. When you have .3mbps down and .1mbps up, Go will just not perform based on our experience. And what did we expect, anyway?
On the other hand, running SpeedTest on an iPad3 in San Francisco last week in an LTE area got 27mbps down and 13mbps up . . . which rivals our cable modems. And Go (understandably) rocks!!!!
So we think good news is on the way over time . . . both in terms of coverage and speed.
Home of VetFM
There could be a number of reasons for the slowdown...
- The number of fields on a layout - the fewer the better
- Are you pulling down unstored calc fields?
- Container fields?
- Are there a lot of graphics on the layouts?
- Are any of the graphics scaled down? You don't want to be downloading a huge graphic file that is scaled down to somthing very small
- Use native graphic elements for buttons vs. imported graphics
At DevCon last year there were sessions on the download "payload" associated with different layout styles. You may find it easier to forgo list layouts and go straight to a minimal form layout. There should be some resources here on TechNet that will be helpful.
If you don't already have them you may want to create specific layouts for the iOS devices that are absolutely bare bones.
And with anything over a 3G network - YMMV - your mileage may vary. A user could take 3 steps and go from usable to unusable.
You may want to consider something like GoZync and have the databases local on the devices, then sync them when back on a full network connecction rather than cellular.
David is right - the problem is network payload. To minimize, consider these fixes:
1) Make your tables as lean as possible - remove any fields you can. FileMaker's model is very record-centric; whenever a client requests a record from the server, it gets the entire record - every field - whether or not those fields are displayed on the current layout (exceptions include container fields not yet displayed, unstored calculations not yet displayed, and ESS data not yet displayed).
2) Form View downloads 25 records at a time. List and Table Views download as many records as can be displayed, and then display more as they come into view. Keeping this in mind will help.
3) Graphics - take advantage of caching by not using different graphics on different layouts. Use the same graphic on every layout, and make it as lean - small in size, low number of colors - as possible.
4) Portals will download all related records that can be displayed in the portal (more as they come into view, similar to List or Table View). So you get not only the parent record payload, but the related records as well. (Ugh!) Sorted portals are especially slow, since they require downloading the entire related set.
5) Minimize the use of aggregate functions - Min, Max, Count, Sum - because they require the download of the ENTIRE found and / or related set. HUGE payload.
6) Sorting and creating a new record also fetch the entire found set - so try to get your users to have a small found set (enforced by scripting) to avoid delays. Also expensive are Replace Field Contents, Relookup, Import, and Export.
7) Value lists based on related sets or table contents also create the need to pull the entire set of records ... so that's why your pull-downs slow things down.
8) Any relationship that has portions across two servers (or on the local database and a remote server) will slow things down.
If you're going to be doing a lot of remote work on mobile devices, David has a very good suggestion: Use the databases locally and sync. This was Richard Carlton's suggestion; he essentially abandoned the idea of using the cell network for FileMaker databases because it's just too slow. But YMMV.
I'd try a few things...
- Cut down the number of portal rows being displayed
- Eliminate as many fields from the portal as possible - while I don't remember the specifics, touching a related record also can pull down additional info from the child records. While you may not be seeing the data, you may be downloading it.
- Think about re-vamping the workflow - instead of the portal, can you use a list view which you click on a record and then go to a form view that displays all the related records for just what you see on a single row in the portal? This way you pull down less data. Potentially more clicks (taps) but a smaller download payload
Lots of things to look and consider, thanks.
Did Richard Carlton write a article? I'd love to read that. Thanks.
In addition to the valuable comments given so far, here are some recommendations:
• 3GS phones will not give you the results of the iPhone 4 and iPad 2.
• 3G connections are notoriously slow. Some FM Go developers consider 3G unusable.
• Version 12 won't save an unfeasible situation.
• There are a number of FileMaker developers who are gaining a lot of experience in evaluating FM Go bottlenecks. You could do worse than emailing Rick Carlton, as he has good advice on optimizing FM Go connections. email@example.com
• Attend DevCon, July in Miami, as your issues are not unique and you'll get great insights there.
Beatrice Beaubien, PhD
i2eye, Toronto, Canada
FileMaker Business Alliance
FileMaker 11 Certified Developer
Knowledge Translation Certified Professional
In reference to your FMP 12 question, joshw, FileMaker is touting and many users are reporting that WAN speeds are significantly improved with FMP 12. With FM Go for 12 free, if you can set up an FMS 12 test server you can try this out. In addition to the excellent tips above about optimizing dbs for WAN and iPad performance, the upload speed at the office of the FMS box can be a bottleneck.
I just did a test using 3G on an iPhone 4S and FM Go for 11 and I, too, found performance pretty unusable. Then I tried 3G with the same 4S using FM Go for 12 — albeit different server and different db, unfortunately could not do a straight apples to apples comparison, and found VERY acceptable performance. Once again, 2 KEY details were different (accessed a less powerful server and and a less complex db), but I'm inclined to think that FMI and other users are right about improved WAN performance in 12.
Ann Arbor, MI
Thats great news for 12.
Would hosting Filemaker on a hosting plan for Filemaker databases (I found one or two on a google search) be a good way to consider as well? We are thinking about purchasing a separate server to put Filemaker on it's own public IP, to help with speed dips here as well. Does anyone have a recommendation of which way is better or worse? If you've used a web server, do you have a service you can recommend?
A web hosting company should have a bigger internet pipe than a standard office and this will help you with WAN performance. But employees inside the office will get slower performance because they've now changed to WAN users as well. The priority for most of my clients is database performance for office users and so we keep the database on the LAN and do what's necessary to speed things up for the offsite WAN users.
One of your options is remote control instead of FM Go. Have an iOS user remote control a desktop computer inside the office. That way only screens, keystrokes, and mouse clicks need to transfer across the slower WAN connection and things that require processing power in FMP happen with a fast LAN connection to the server. You do need an unused computer in the office to do this, though. Or go to something like Terminal Server or Citrix (expensive and complex to set up). Lion is supposed to have something like Terminal Server built in, but I haven't had a chance to play with it.
I'm playing around with Screens VNC for iPad (remote control) and having very good results remotely controlling a computer with a very slow internet connection (upload 384K). Also heard good things about Desktop Connect.