NEVER use the verification feature of backups if your db is being accessed ! It absolutely kill FMS performance. I've made that mistake the first day I deployed FMS, and it was absolutely unusable (and that's only 3-4 people using it).
I do one backup with verification on per day, when users have left the company.
FM Inc should have put the verification switch in red, stating DON'T USE IT if people connected to the db ! I almost cancelled my fms order cause of that. That was my very first post here.
Howerwer you can do live backups provided the verification feature is off.
My backup policy is 1 backup for each working hours of the day, + 4 backups for the latest hours each 15 minutes, + one backup per day with verification.
it works ok.
But recently I felt some slowness, mand i investigated. My backup without verification were still too slow : up to 5 minutes, and that's too slow especillay is 15 min backup overlaps with the hourly, which will occur with such long backup.
What's even worse is if you run an heavy script and there's a backup involved : so slow it almost stalls !
My 63 files DB is 2 GB Total. So recently I cut down my backup time from 5 minute to 30 seconds ! So almost zero backup/script overlapping. Much better
How did I do ? Simple, put a modern hard drive internally (Mac Pro) and targeted my backups to this new HD. It's a 7.5 TB 7200 rpm Seagate but you can get faster with Hitachi 2TB or WB Caviar black 2 TB. I monitor the disk thougput during backup : Full stable 100 MB/s
My previous HD to which I backup was an old 250GB, it clocked t only 20-30MB/s during the same task.
What is interesting is that the backup seemed only limited by the new hd writing speed, so I guess with a RAID 0 (not especially recomended for backups) it could be faster. I monitored the disk activity crefully and there was absoluteluy no reads whatsoever from the hd containing the actual database. That's both a good and bad news. Good because it should be that way, bad because a faster drive for hosting the db won't help since all the db is in ram.
In fact, I host the db files on a ram disk, but FMS seems to never read or write from it, maybe FMS writes on it when it flushes its caches but it's very quick and very few kb are written.
I think FMS startup is faster with the ramdisk hostting the db.
Now, I'm already hearing people calling me crazy to host my db on a ram disk, because if power off you'll loose everything. Given that any not nicely closed FMP database is potentially corrupted, I don't see the value of having a badly closed db on a hd rather than none considering that I bakup every 15 minutes. I can only loose 15 min of work, I take taht any day isntead of potentially corrupted DB.
But given that I didn't see much activity on that ram disk, and that actual benchmark I made were virtually the same, I tend to think that the ram disk in unecessary, at leat in my case with a 2GB db that fits easyly in the 12 GB of ram I have.
That leads me to your final question : how can I speed up FMS ?
You just can't. You can only avoid to kill it's performance by using the verification feature. And you can have less sucky backup times by using a fast HD. But HD speed for hosting the DB is not relevant.
CPU for FMS, I don't know, it's not that much important in my experience. On my quad core it never goes more than 170% (and that's because I highly tax it with FM Robot running big scripts on the same machine, everybody says you shouldn't do this, but I they did try, without that robot I rarely saw the FMS cpu usage above 70%, except when backuping). I think might matter with server side script processing but since FM Inc crippled that feature so much…
And with script I'd suggest some high Ghz rathern than cores. As I said I never saw more than 170% instead of the 400% available.
The main bottleneck is network speed and by that I mean number of I/O not throughput. But you can't do anything about it (except infiniband that you won't be able to install on the clients).
Hope this helped.
P.S : For backup speed, econnectix claims to be able to backup ANY FMPP Database in less than 1s with their XFM for FileMaker disk system. I didn't tried it, seems too expensive for me, and since I think according to my hd activity analysis that HD doesn't matter for hosting the DB, I think that's wont speed up things for me.
P.S 2 : I actually think that FMS 10 is more processor hungry than FMS 9, and is actually slower while using more CPU, so you've nicer CPU graphs but less work done. But that's just of feeling, I've no evidence of that, Id be glad to get information about it.
oh, and for the 64 bit kernel, I'll go with it. Theoretically it shouldn't matter but there's some evidence on the web that it can help. The excellent diglloyd Photoblog showed up to 32% performance gains booting in 64 bits for Apple's Aperture.
Since Aperture's is almost as baddly writtend than FMP as far as performance is concerned, we can have hopes (but surely, in a typical FM Inc fashion, it will disappoint:-))
P.S : I've no access to a 64 bit bootable machine unfortunately.