FM Server imports slow

[Gerry888]

In one of my database files I have a script that imports data from several other files (I use the Import script step four or five times). Using regular FM Pro 5.0 on a network, the script takes a few seconds to run. Recently the database was moved to FM Server 5.0 -- and this script now takes several minutes to run, even with only one user. I don't know much about FM Server (and don't administer it), so this may be a stupid question, but: Is there some reason for this? Are imports always slow in the Server environment?

Thanks for any advice anyone can provide.

[Kurt Knippel]

Imports are almost always slower when on server. As fast as the transfer rates of modern networks might be, they are no where near as fast as the transfer rates to your local RAM/Harddrive.

Although you will probably notice not a whit of difference when 250 users are on the system. That is one of the beautify things about server.

There are way to increase the performance of FMServer, such as running in a RAM disk, but I am afraid that this will not address your issue.

Something that I used to do with BIG imports was to actually pull the file offline, and do the imports in single user mode. But this can be a hassle if users are online trying to access the file as well.

[Gerry888]

Thanks for the reply, Kurt. I'd expected the imports to be a bit slower, but this seemed borderline ridiculous (going from a few seconds when off the server to a good five *minutes* when on the server). There are a number of different imports, but each involves no more than about 5 or 6 fields, and 5 or 6 records (although I do have some pretty involved calculations running in the receiving database). Since I'm not the guy administering the server (and don't know much about FM Server) I was hoping there might be a setting somewhere that needed to be adjusted. If not, I guess I may have to try a different approach. Thanks again.

[LiveOak]

The speed issue on server is really the difference between how fast you can transfer data to a disk drive vs. over a network. The speed difference is dramatic. Disks transfer at 20, 40 or a high as 160 MB/sec (that's BYTES per second). The raw speed of 100 basedT is 10 mega Bytes per second, but with a bunch of protocol that makes the actual speed much less, maybe 2 megabytes per second. In head to head comparisons of communication intensive FM operations, something that takes 1-2 seconds on a local machine might take a minute when run on a server. This is about right as it is about a 30-60 ratio of speed.

-bd

[Gerry888]

Thanks, bd. I clearly need to study up on FileMaker and networks. It hadn't occurred to me that the actual *data* needs to travel across the network from the user's machine, since it's really just being transferred between two files on the server. Now that you've spelled it out, I see why things are taking so long. Thanks again. Time for a new approach.

--Gerry

[Anatoli]

It needs to be read by machine/client, evaluated, calculated and send back to the server and written there. In the same moment server has to lock everything what is just processing and release locks after processing. In the same moment some collisions are probably occurring on Ethernet, so server is sending packets again or asking for processed packets again, so not everything is running linear.

You should see some 5-20 minutes dead terminals in multi-user environment in mainframe, which was a 1 million bucks 15 year ago. 50-100 users with terminals, bad design in SW and users waited and waited and....

[Gerry888]

Thanks, Anatoli. I'm going back to the drawing board.

--Gerry