I thought should take a moment and jot down some ideas and tests I’ve done lately to help some support customers improve their FileMaker server performance. I did not create the FileMaker solutions used by these customers, but I do support their Macs, including the ones used as FileMaker Servers. (If any of this helps you with your server, I’d love to hear about it.)

The first piece of advice that FileMaker offers is that we should run FileMaker Server by itself on a computer. That is good advice, but why is it good advice? And what if you don’t have the option? Well, here is a little of my thinking on that.

In one case I’ve worked on lately, there is a massive Intel-based X-Serve, with eight cores, 10 Gigs of RAM and a dual-drive mirror raid (okay, software raid), running multiple services, including file services and FileMaker server. In the other case, there is a Macintosh Mini as a dedicated FileMaker Server. Both of these were getting multiple reports of slow performance (as in taking many times longer than normal to perform a common operation of the solution.)

In the case of the X-Serve, we have way way more than enough processing power to handle everything asked of it and enough RAM (can you ever have too much RAM?). The 100 Megabit network is an obvious choice of bottlenecks, but one computer is connected by FireWire at 800 Megabits. It normally has much better FileMaker performance than the others but its user is reporting slow performance when everyone else is. Since the FireWire connection is not shared with anything else, this pretty much points to the hard drives as the common bottleneck.

Taking another look at the X-Serve RAID drives, we see that the system is booted from the RAID, FileMaker is being served from the RAID, and file sharing is being served from the RAID. (Other services are also being hosted from the RAID, but are not using a significant amount of resources.) File services becomes a big culprit quickly when we learn that some large files are being opened, closed and copied during the day. Of course, the system has things it needs to do, like opening and closing applications, swapping out virtual memory, and so forth.

In the case of the Mac mini, we see that the hard drive which is serving up FileMaker is the Internal 2.5 inch (laptop) drive. A drive which is great for low power consumption and low heat but not great for performance.

In the case of both of these machines, I started to think about the ability of the drives to perform a certain number of operations per second. When you think about it that way, you realize that all these services are competing with each other for operations each second. If they all hit at once, we have an overwhelmed drive, and slow performance. (More complicated, but realistic, is the performance penalty for switching from read-mode to write-mode and back.)

So, how can we help FileMaker Server get the maximum number of operations per second from a drive? Give it a drive to itself, so there is no competition.

In both cases we decided to try a new hard drive. For the X-Serve, we moved the FileMaker databases to the unused 80 gig hard drive which shipped with the X-Serve. For the Mac mini, we moved the FileMaker databases to an external FireWire drive.

The first problem involved with this was specifying where FileMaker server should find its data bases. For FileMaker server version 9.0v2, it was just about impossible. You have an extremely difficult time accepting paths other than its own defaults. FileMaker server version 9.0v3, however, accepted them with much less headache. You still must know exactly how to specify one (“filemac:/VolumeName/folder/path/”) and you must know to begin with “filemac:”,  then a beginning slash, then the volume’s name (not to be confused with a Unix-style path which begins with “/Volumes/”).  Finally, you must end the path with a slash.

You must also know, to have permissions on the target folder set to allow reading and writing for the owner account “fmserver” and/or for the group “fmsadmin”. In the case of an external drive, you can use the “Get Info” dialog in the Finder to “ignore permissions” on the drive. (But that’s Read-Write for everyone.)

As a cheap way to step-up performance a little more, we looked at partitioning the drives so that the databases would stay on the outer tracks which were supposed to give higher performance. Since these are Macs, we used the utility DiskUtility  to partition the drives. The first partition (top one in the list) is the one on the outer-most tracks. Giving it around 20 percent of drive seemed right for the current needs and future expansion of the database files. (Your mileage may vary.)

To check myself on this, I ran the benchmark tool from “Drive Genius” from ProSoft Engineering.  This can’t really say if there will be any difference for FileMaker’s end performance since, but some of the benchmarks did show faster speeds on the outer tracks partition. This was at least encouraging.

With all the pieces in place, we worked carefully to move the files.  In the “Database Server” configuration page, we selected the “Default Folders” tab, turned on “Use additional database folder”, and carefully specified our path to the new drive partition’s database folder. (Which has nothing in it.)  We ran back a backup schedule in FileMaker, closed the database files, then shutdown the server.  Once it was shut down, we made a direct copy of the files in Finder as a manual backup. We then copied the files to their new home drive, and moved the originals to a new folder so FileMaker could not accidentally reopen them later.

At this point we restarted the FileMaker server and there were our databases, up and running. (Wipe sweaty brow.)

At this point, it is useful point out that we went back and changed the name of the database folder on the external drive to reflect its location. Since the admin console still shows the default “Databases” folder it isn’t good to name the new folder “Databases”. We named the one for the X-Serve “Databases80Gig”. All the databases and the sub-folders with databases show up just like they did for the default databases folders, but now under “Databases80Gig”.

Now, since we don’t have any real tools to see if our performance is truly better, we will just go with the anecdotal evidence that in both cases, the users are complaining less about the servers being slow. (They’re complaining less to me.)  It seems fair to say things are closer to their expectations for performance.