FileMaker over WAN is very slow... always has been, because it has to transfer every single pixel and the information associated with every single pixel — that's a lot of data. There are ways to optimize your graphics/layouts/etc. (especially in 12). I recommend looking into the new "Tweak" tool by Scriptology (it's part of their new Theme Library for 12 http://www.scriptology.com/theme-library) — I use this and it's awesome. Instead of using mulitple objects to obtain the desired look (like a simple drop shadow), this tool allows you to mod the CSS of the actual field. One object now has the design effect that used to take 2+ objects in the past... which means less data to transfer if using WAN (or LAN too). One of the major changes with 12 is moving to CSS. The more FMP moves in this direction, the faster it will be over WAN. Eventually it will be able to perform over WAN like a website (hence the move to CSS) because it won't have to transfer every pixel and the associated info.
If you're using FMP Go, then I'd look into a sync solution, rather than using WAN. Go will be buttery smooth just like an app, then you sync your changes throughtout the day. I hear good things about GoZync (http://www.gozync.com). SeedCode makes excellent software, so I'm sure this is top notch (I haven't used it myself).
Without knowing more about your solution or what specifically you want it to do, this is the best I can do.
The speed problem is why we started hosting FileMaker in the cloud using Citrix XenApp for our customers. It isn't the perfect solution as it uses a Windows interface that some Mac users don't like and some of FileMaker's more fun features have to be limited for security reasons.
However, if the main requirement is to access and process data from multiple locations it allows access from any device via a web browser, runs a full version of FileMaker Pro (or Advanced) and gives near network speeds. The speed tests we've published on our web site shows a replace field for 26000 records took nearly 25 minutes for FMP 11 running locally connected to a cloud hosted server, 14 minutes using FMP 12, 16 seconds for both versions using XenApp and 5 seconds on a database running on the computer's hard disk. Most people we've helped move from local to cloud based systems haven't noticed much of a difference in speed.
If you'd like to see other speed comparisions we've various tests published at http://www.filemakerdatabases.co.uk/pages/videodemos.html
It's posts like this that keep the Product Managers and Sales Office up at night :-)
Citrix is a bit expensive, but has always been a great work around. We've used it for years, but host it locally
> FM11 and it is too slow and FM12 is even slower. Because of the poor performance of FM12 I'm unable to use it.
We had a similar situation with performance. An alternative to Citrix/XenApp is 2X. ( http://www.2x.com ) It accomplished the same thing but at a much lower costs. They also have client for iOS and Android. (Also Thin clients as well.) 2X is also great for quick access to administrate servers as well. We tried both XennApp and 2x and performance was about the same. Features are very close. I prefere using the 2x client on the iOS than Citrix Client and it's easier to use. 2X is also a lot les complex to setup than Citrix.
Just want to add my two cents here with reference to FMS 12, filemaker is very much aware of performance issues with FMS 12 and are currently working to resolve the issues. Other than that i have no idea when the next patch will be released and that the performance issues with be resolved. Currently all my solutions are staying in FM 11...
Anyone else having performance issues with FM12?
Just an FYI, I couldn't get any of your videos to run on my system through Safari or Firefox, but they would run on Chrome. OS X 10.8.2
Thanks for the heads up on the videos. These are all hosted by Vimeo, so there isn't much we can do and they do appear to be playing on our copies of Safari and Firefox. We'll keep an eye on these and thanks for going to have a look.
All the best
In addition to the recommendations you've seen from others, I'd suggest taking a look at your database structure itself. The fact that the solution is slow under both 11 and 12 suggests that there may be some things you can do along those lines. Let me explain just a bit.
FileMaker's client-server model is "record-centric". When a client requests a record from the host, the server delivers the entire record - all fields (with a few notable exceptions). So you can help yourself by deleting any extraneous fields from the tables involved. Depending on how old the solution is, you may be able to get rid of old fields that were used in the pre-version 7 days that were used for things like concatenated joins, or interface elements that can now be done in another way (like Conditional Formatting). That will help you speed things up. In other words, try to think in terms of more, narrow tables instead of fewer, broad tables.
Other things you can do to speed up your network performance:
1) Use lean graphics - small size, small number of colors.
2) Use the same graphic on multiple layouts. This takes advantage of caching behaviors - FileMaker only has to download the graphic once. If you change graphics between layouts, FileMaker has to download the new graphic.
3) Use native objects (like buttons) instead of graphics, especially in a version 12 environment.
4) Move business logic out of the database layer and into the interface layer using tools like Conditional Formatting and Script Triggers.
5) Where you have a table where some fields change frequently, and others change very rarely, consider using one-to-one relationships that split the frequently-changed fields out from the rarely-changed fields. This takes advantage of caching behavior for the rarely-changed fields and avoids the system having to download lots of data that didn't change to update the user cache.
6) If you have table occurrences on your graph that aren't core to the solution, consider substituting the ExecuteSQL function for permanent joins. This will help performance because the calculation is run on the client side.
You do have some valid points however this is a FMS 12 issue when importing records into a basic table.
Sorry. I was answering the root question, which doesn't say anything about importing. Unless I've gone blind.
Great advice Mike and fully understand your problems Martin. However, I believe the FM12 performance issues are dealt with in detail in many, many other posts. We're currently involved in the Data Viewer slowdown thread at the moment and FM12 has been a nightmare for our productivity.
However, the original question here was WAN performance and it would be unfortunate to hijack this thread into another generic FM12 speed discussion.
We've proved to ourselves there have been significant speed improvements over a WAN connection from v11 to v12. As Mike suggested, providing you can take advantage of FileMaker's inbuilt caching, once you've waited for the first load of a layout, you can pretty much navigate speedily over a WAN.
But, for complex solutions where large data sets are updated a speed increase from 24 minutes down to 14 minutes is a high percentage gain but pitiful in terms of overall performance. Currently we believe the virtualisation of FileMaker using Citrix, 2X, etc is the only guaranteed way of obtaining performance. We opted for the Citrix option due to the seamless way it allows printing locally and for integration to allow PDF creation on the user's local hard disk. No doubt FileMaker will continue to improve their WAN speeds in the future.
FileMaker over WAN is very slow... always has been, because it has to transfer every single pixel and the information associated with every single pixel — that's a lot of data. There are ways to optimize your graphics/layouts/etc. (especially in 12).
FileMaker over WAN can be slow. But I've also participated in some demos of a few solutions that while very complex, were very fast. CSS can help, if done right. And I think FMI is heading in the right direction.
The separation model with a client side interface file, server side data file can eliminate a ton of data movement. And increase performance by leaps and bounds. Mike's suggestions are also very good. Large data sets can be an issue, for any platform. FM 12 has shown us a little more of the problems than I would have liked to see, but v2 is better and I expect v3 will resolve many of the speed/performance issues we are seeing.
Another good idea, if you are doing a lot of WAN deployment, check in with Mark Richman at Skeleton Key and get into one of their "Developing for Maximum WAN Performance" Workshops. There are a lot of best practices and tips to reducing data movement that can drastically increase your performance. And if they are still doing it the same, he actually takes your solution, and walks through it with you and helps you identify some areas that may be decreasing your performance.