Remote access too slow!

[jdaheartfm]

Our company is using FM Server 9 to host our files via remote access over the internet. We are experiencing extremely slow speeds when opening files and navigating through layouts, loading value list drop down, etc. We've tried removing various components, images, complex relationship, extraneous fields/scripts/layouts/tables and find no increase in speed.

Any suggestions or insight into what might be causing the slowdowns would be much appreciated. Thanks!

[Steven H. Blackwell]

There are so many items that could be causing this that's it's almost impossible to list them all. Here are a few:

Less than optimal file architcture.

"Busy" layouts.

Incorrectly configured FileMaker Server hardware, including memory.

Incorrectly configured or inappropriate OS on Server machine.

Poor configuration of FMS service.

Running extraneous services on teh server.

Poor quality NIC cards.

Latency of connections on WAN (the internet is the WAN here).

Incorrect configuration of FMP client on user workstations.

Poor quality workstations.

Too many programs open on the workstation.

And so forth.

Steven

[Linux on Unix Action Hero]

I'm not too familiar with FM yet, but I might be able to offer some input/things to check.

- What is the processor load during use?

- Does the system swap out to disk?

- How big is the database/how many db rows are getting returned at once?

- How many users are accessing remotely?

- Do you have local access speed problems?

The thing is, compared to pretty much every other OS out there, MacOS X falls a bit short when doing with threading due to how many kernel locks it allows at once, and its general signal handling ability. DBs usually require a fair number of threads, and as OS X compares (for instance) roughly 1/7th as well as Linux with thread/process signal handling, you're going to hit a bottleneck pretty quickly. Network server roles also generate a fair number of threads on a system due to the additional forking of data over interfaces.

This is, unfortunately, a fault of OS X itself, in part due to its "kernel within a kernel architecture" design. (IE, the difference between OS X on PPC and Intel is marginal - they both suffer about 7-8th the performance after only about a concurrency of 2).

[Fancytricks]

Hi there,

This depends on the internet connection. But most of the times if you are opening a database over TCP (normal internet) then it will be slowish.

Options:

Terminal Services - run win2003 with teminal services which in my case is the best options, we run in 7 countries from the UK with no issues.

SDSL - like adsl, but you get a dedicated line, this will solve the problem all together.

[Vaughan]

"This depends on the internet connection. But most of the times if you are opening a database over TCP (normal internet) then it will be slowish."

No.

Well designed FMP databases can be *faster* when shared with FM Server then when opened locally.

It depends on the speed of the network, the speed of the server, and how well the database has been optimised for network use.

[Steven H. Blackwell]

Well designed FMP databases can be *faster* when shared with FM Server then when opened locally.

[color:red]Absolutely 100% correct and on-target here.

Steven

[David Jondreau]

This is hard for me to believe, but it's coming from V. and S.B., so it MUST be true!

What techniques optimize a solution for network use, aside from 'busy' layouts? (The other options noted by S.B. have little to do with the solution itself).

[Steven H. Blackwell]

Avoiding large numbers of summary fields displaying on layouts will help enormously.

Steven

[Vaughan]

"This is hard for me to believe, but it's coming from V. and S.B., so it MUST be true!"

In many cases FM Server does processing on the server, which means the data doesn't need to travel down the network pipe, and the user's (often slower) computer isn't doing the number crunching. Older versions of FMS just dumped all the data to the client for processing.