FMServer-hosted dBase starts slow then speeds up???

[Kenny Beckman]

I have just started using a FMPro hosting service, and have a question about what appears to be a particular problem that I experience using the remote host.

For about a year I've been developing a LIMS for my lab at a research institute, using fmnet and my dBase hosted using FMPro 8 on a Mac in my lab. Now I want to make the dBase available to others, so I'm trying to see how the dBase operates from a remote FileMaker server outside my institute (so my collaborators would be able to access it).

I find, oddly, that when I access my dBase at the remote hosting service using FMNet, that any layout I navigate to takes ages to load the first time I access it, but on any subsequent visit to the layout navigation is very fast. My database does not display this behavior from within my institute. I know this has to do with indexing, but why should indexing be slower on FMServer (which is presumably the better platform) than FMPro?

Can someone explain to me what is going on? Does this have something to be with FMPro Server? Is there any way to get the Server to act like the standalone program?

I surmise from reading posts that summary calculation fields slow down the loading of a layout that requires these fields to be calculated, and indeed is I strip out the calc summ fields I have this helps a lot. But why would I have never observed this using the dBase at my institute?

Note: this problem re-occurs each time I log on -- the faster navigation that occurs upon a single visit to a layout is lost when I log out of the dBase on the Server. If this is due to indexing, does that mean that indexing ,ust be re-performed every time you log on to the dBase? I also found that when I logged on simultanesouly as two different users, the increased speed upon re-accessing a given layout did not translate from user to user. In other words, the indexing (or whatever else results in the increase in loading) was limited to a single user's session.

I know this is probably a really basic question, but thanks for your time, in advance...

Edited May 11, 2007 by Guest

[Vaughan]

Well, your post is in the IWP forum, so I guess the database is being accessed through a web browser.

The reason why you have noticed a speed difference is that the hosting service is running on Broadband speed (~256 Kbs or maybe 512 Kbs) and you are sharing the server cpu with others. When you had the file hosted in your lab you were connecting to it at Ethernet speeds (~100,000 Kbs or higher) and you had the cpu all to yourself.

Sharing the server with others means that data processing is going to take longer to perform. The server will cache some of the data after it has been used the first time, and this is probably causing the speed-up. Once you log-out the server is probably clearing the cache.

Buy a copy of FMSA and host it yourself on your own box on your own network.

[Kenny Beckman]

Thanks! (In fact I'm using fmnet at this point -- I couldn't find a thread that specifically lists fmnet issues.) I'm assuming that the speed issue would be the same or worse with instant web sharing.

Edited May 11, 2007 by Guest

[John May - Point In Space]

I don't think the problems are the server speed, but rather the latency of a WAN vs. a LAN, especially if the slowness encountered is with calcs, summary fields and the likes. These operations do a lot of back-and-forth to the server, and this is going to be noticably slower going over a WAN (like the internet) as latency is going to be considerably slower then when operating on a LAN - even with the best internet connections.

As far as the slow at first, faster later deal. What is probably happening is the CLIENT is caching the calcs, summaries, layout information, etc. for later usage. That cache then gets cleared when the database is closed.

- John

[Kenny Beckman]

Empirical data: I removed most of the summary calculation fields from my Start page (these summarized flagged "to do" fields for records throughout the dBase) and now it's quick as a wink.

So as John suggests, this does appear to be a design issue I'll need to deal with.

Thanks folks!