Improving WAN performance?

[xochi]

Any tips for improving performance over WAN? I have a database which opens in about 1-2 seconds on a LAN, but takes 40 seconds or so over a WAN, even after I removed most of the startup scripts that could access data or go to layouts with big graphics. I've done some testing with a big file and small file, and it seems like FMS is loading the entire file's layout structure before opening it. Since this database has a lot of unused crud in it (test layouts, unused layouts, old versions etc.). "Save as clone" gives a file size of about 6MB with no data. I'm wondering if I would get a speed boost if I cut out the unused layouts. Or.. am I misguided my theory that the size of unused layouts matter, even if they are not accessed in the startup script?

[Vaughan]

It should only load the displayed layouts at startup. But FMP also needs to open all related files too (usually hidden) and over a WAn these could take time. Check the file references and make sure they are in the form "file:filename" (unless the files are on a different server) and remove all other references.

Crate a new layout with no graphic elements on it and test the WAN speed. Move forward from here. Less is more.

Backup before making changes!

[Fitch]

FileMaker has to resolve every relationship in your graph on startup. Extra layouts shouldn't be a big deal, but clean up your graph as much as possible.

[xochi]

Interesting. Are all relationships equal, or do some take longer to evaluate than others?

[Vaughan]

Tom Fitch wrote: "FileMaker has to resolve every relationship in your graph on startup."

Does it resolve relationships, table occurrances, or file references?

[Fenton]

I would think File References. Because related files will not be opened, even in the background, unless a field of theirs is somehow present on the layout (including one used in a calculation for a local field that is on the layout). Perhaps there are exceptions to this, but it's generally true.

[Fitch]

Fenton, you just explained why file references are not resolved at startup. If they were, then it wouldn't ever need to ask you for them later. Only the FRs that are required at startup are resolved at startup.

Relationships and TOs yes, FRs no, that's my understanding based on a Devcon under the hood session from a couple years ago and brief conversation afterwards with Danny Mack. Please correct me if I'm wrong.

I don't know about some taking longer than others.

[Steven H. Blackwell]

Be sure client side cache is set to 12 MB, not the default of 8 MB, and that you have at least 1 GB free space on your drive.

Check server side cache. Check how many open programs on workstation.

WAN's--depending on both bandwidth, latency, and routing--will incur some access penalty. The idea is to minimize that. For example, an initial sort on a table from a blank layout may add to start-up time, but dramatically improve performance thereafter.

Factors generally involved, once you leave the host LAN, include solution architecture, bandwidth, latency, guest network configuration (especially the switch), and guest workstation configuration.

Steven

[boley]

I would try a putting little math to your bandwidth of the LAN vs WAN. WAN BW / LAN BW = worst case slow down. If you have a T1 connection it would be reasonable for the startup to take 60-70 times longer if your server isn't a bottle neck on the LAN side. In my experience the upload or outgoing connection speed from your server is much more important than the incoming connection. This is a good thing if your clients have DSL.