FMP Server Performance

[pchernoff]

We are using a database application developed by another company. After doing some comparison between multi-user with FileMaker Pro Server 5.5 and single-user directly on a client machine, I am convinced that I must have the server set up improperly because of the huge speed differences (I use other databases where the server version is quite quick).

Normally we run the FMP Server on a PowerMac G4 QuickSilerver 867Mhz with Mac OS 10.1.5. After having this system up for some time I discovered some server disk damage and bad RAM, and have blamed that and some other issues for poor network performance. This morning I booted up the same machine under Mac OS 9.22, installed the server software, moved the database files to the Mac OS 9 partition, and still underwhelming performance. Other network activities (backup, file transfer) seem quite speedy, and the switch log doesn't show many packet errors.

Setup specs: PowerMac G4 QuickSilerver 867Mhz, 1.5GB RAM, FMP cache set to maximum (40MB), HP PowerCurve 4000M switch, port set to 100baseT half-duplex, no flow control. With Mac OS 9 set to minimal set of extensions. System is set to never go to sleep.

Any suggestions on performance enhancement? The application developers are surprized at the slowness of our system and assure me that other customers have zippier performance (with the exception where an iBook is being used as a server).

[kennedy]

I am looking into this, too. Per the other threads here, FMP's and FMS's performance actually drops if you set the cache too large. And 40MB is way too large unless your database is more than half a Gig.

Try setting it to 2MB or to 10% of your database size.

Smart guys: Beyond that, what are the next most likely suspects? What are the top 5 things you do for performance tuning?

[Kurt Knippel]

RAM allocation: Do not give FMS more than 40MB of RAM. FMS is disk based and giving it too much RAM just causes processor delays as it deals with the additional RAM overhead.

RAM Disk: given the amount of RAM you have, you should consider a RAM Disk. We use RAMbunctious from Clarkwood Software. We put all the DBs, and the Filemaker Server folder into the RAM Disk. Quite speedy.

You also have to be careful in your comparisons as there are so many variables to consider. What performance were you expecting and how is Filemaker not living up to this? Why do you think that you can make a comparison between a particular solution running under Filemaker Server to another solution on another database server platform? What about the network performance?

[Anatoli]

RE: What are the top 5 things you do for performance tuning?

I do not dare to give "IMHO". Kurt will not like it

[kennedy]

RE: What are the top 5 things you do for performance tuning?

I do not dare to give "IMHO". Kurt will not like it

Oh, c'mon... where's the fun in that??

Besides, its rude to tease us like that.

[kennedy]

RAM Disk: given the amount of RAM you have, you should consider a RAM Disk. We use RAMbunctious from Clarkwood Software. We put all the DBs, and the Filemaker Server folder into the RAM Disk. Quite speedy.

I'm a bit surprised by this recommendation. RAM Disks are great for speeding up normal programs, especially when they are being subjected to larger than normal files.

However, a database program's primary function is to efficiently serve data off a disk. It implements sophisticated mechanisms for what to cache in RAM and what to write to disk. Unless the database is POORLY written, a RAM Disk should either:

a) reduce performance by adding an extra layer of cache management,

or

: increase performance but only via a loss of data reliability as the RAM disk gains its speed advantage by not writing to disk as often, increasing the risk of data loss if the machine goes down

But even in the case of (:, a good database should offer tuning parameters such that you can choose to what degree you want to allow data to sit in RAM, not written to disk. And the database can manage that much better by choosing to write out the more critical info more frequently (the RAM disk can't tell critical from junk).

Is FMS really worse at data cache management than a simplistic RAM Disk?

[pchernoff]

All of the database files make up around 82MB. So I will try reducing the cache from 40MB to 8MB. I didn't realize that the cache was done so poorly. I think I'll do some testing in single-user mode with different cache settings and see how long it takes to do the aging.

Since I am running the server on Mac OS X amount of RAM allocated to FMPS is irrelevant, though I would be interested in know if merely having too much RAM on the Mac server could be doing any harm.

Thank you for the suggestion.

[Kurt Knippel]

A RAM Disk is not a replacement for cache or anything like that. A RAM disk is simply a very fast, typically very small (by harddisk standards) harddisk. Filemaker Server does not have any clue that it is running off of a RAM Disk. Generally the disk is slow, cache is faster and RAM is very fast...in this situation, the RAMDisk is very fast, cache is as fast, RAM is as fast.

You can configure the RAMbunctious software with a variety of write through schemes and over the course of 2 years with this running on 5 Filemaker Servers, I have yet to see any data loss.

This scheme also allows you to use less expensive, less powerful hardware, since RAM is typically the same in terms of performance in both the low and the high end of machines. We use Apple Macintosh Cubes as our servers, these are 400Mhz machine with so-so ATA drives in them, but they far outperform even our fastest SCSI drives, although they are so much smaller (256-384MB compared to 160GB).

A classic RAM disk story comes from the California DMV which uses some kind of Filemaker Solution. They were going through something like 1 hard disk per month, because the solution got used so often that the drive would either fragment beyond usability or simply exceede its expected lifetime of usage. Moving to RAM disk solved this problem and increased performance.

[Anatoli]

Kennedy

you asked so here it is:

1. Get NT or W2k workstation as FM server

2. Get even better NT or W2k workstation as FM server

3. Get even better NT or W2k workstation as FM server

4. Get even better NT or W2k workstation as FM server

5. Get even better NT or W2k workstation as FM server

[pchernoff]

I've taken some actions and performed some tests. I feel stumped.

1) I rebuild my Mac OS X hard disk from scratch with Mac OS X 10.1.5 and did permissions repair (I have been warned away from 10.2.x with FMPS) and then installed FMPS 5.5v2. I didn't install anything extra, such as Retrospect Client or Timbuktu. I also reduced the size of the cache to 10% of the total size of the databases involved.

2) In the application I use, the time to generate an aging report went down from 1h45m to 1h20m. Some progress.

3) If I run this same database application from my Xserve (with hardware RAID) as a local application, the aging report takes 11 minutes to generate (with TCP/IP turned off in FMP) (and 14 minutes if data is on a local hard drive). If I turn on TCP/IP on FMP and set up the files for sharing, aging report generation time goes up to 14 minutes. This leads me to believe that my network is performing fine (all computers in question access the network at 100baseT).

4) As a test, I had another computer access the FMP databases with my computer as host. Response time was awful, worse than with FMPS as host. But response time with my computer (the host computer) was fine.

I have ordred the June/July issue of FileMaker Advisor to see if its article on optimizing server performance will yield any clues, but FMPS performance just seems very poor. While I am sure adding a fast SCSI drive (I have a few cards available) would help, I don't know if anything short of adding a RAM disk, with backups every 15-30 minutes to hard disk) will really help. Basic lists and relational lists seem fine, but anything involving calculations seem to get very bogged down when using a "remote" FMP computer. Surely, for $1,000, FMPS has more to offer.

--Paul