Time to do something about the network bottleneck this time.  How can I do more with what is already here?

Since Firewire can be used to run IP network traffic, and the Mac I was looking to speed up was close to the X-Serve, this seemed natural.  Since the Mac in question was a recent-model Intel-based tower, there was a FireWire-800 port available on both ends.  And, since we had a cable for that leftover from a hard drive purchase, we were in business.
`
Its pretty easy to setup a FireWire network connection; just plug the cable into each machine.  Think of it as a crossover cable (yeah, I know Macs haven’t needed those for a long time…)  Once that’s done, all you have to do is setup the network panel on each end.

I deliberately chose to change the subnet to something not used elsewhere on the network.  I don’t think I really had to, but it kept it clear which network interface was being used.  The office network used numbers like 192.168.10.x for main office computers and 192.168.11.x for the satellite office.  For clarity and unlikely collisions later, I chose 192.168.110.x for the FireWire. So the two computers became 192.168.110.50 for the server (which used 192.168.10.50 on ethernet) and 192.168.110.33 for the Mac (which was 10.33 on ethernet)

Setting things up in the Network panel of System Preferences was easy.  I selected the FireWire port in the list, set “configure” to “Manually” (required, there won’t be a DHCP server this way), then put in the IP Address (192.168.110.33 or 110.50) and Subnet Mask of 255.255.255.0.  The “Router”, “DNS Server” and “Search Domains” entries were not needed. (Ethernet gets the connection to the internet.)   Note that you may have to add the FIrewire port to the list with the “+” button first.

Once all that was done, it was just a matter of connecting FileMaker with correct IP number.  I went into “Open Remote” and added the new IP as a “Favorite Hosts” entry and removed the old one.  Just specifying the FireWire IP address is enough to make the connection go over FireWire.

Now when the user connects, they get 800 MegaBits of speed instead of 100 MegaBits on ethernet.  Better yet, the FireWire connection is completely unshared.  No one else in that office uses it. No file-sharing traffice, no printer traffic, no internet traffic.

The main user of the Mac reported that the connection was much better than ethernet had been.  He experience far faster performance.  And thats good, because up to 4 people at once use this Mac for accessing the FileMaker Server.  How’s that?  Well, that’s a topic for another post.  Hint:  VNC

The main downsides to networking with FireWire:

1. The computer must be really close to the server.  This one happened to be close enough for a 4-foot cable.  You can get longer cables, but I don’t know the limits.  A quick google shows a 33-feet length claimed for FireWire-400 (still better than 100-Megabit ethernet).

2. FireWire hard drives become unpredictable for disconnect-reconnect.  This downside was irritating.  The external backup drive for the X-Serve would always mount on the Mac tower whenever we re-connected it.  Eventually I broke down and conencted the drive to the X-Serve with USB-2.  I could not get it to reliably re-mount to the X-Serve.  This could be a show-stopper in other places.

The drive stayed mounted on the X-Serve just fine if we connected it BEFORE connecting the Mac.  But once the Mac was connected to FireWire, the drive always mounted on the Mac.  Even dismounting it manually with Disk Utility would not let me mount it on the X-Serve.  Wherever the drive was mounted it did work fine.

Tags: FileMaker, FileMaker Server

There’s problem with specifying a single external hard drive as the only backup destination: if that drive fails, there is no backup until somebody notices and replaces the drive.

Previously, I set all my backup schedules to copy from Drive1 (with the databases) to a folder in Drive2.  Other scripts would run periodically to synchronize the folder in Drive2 to Drive3 and Drive4.  But this makes Drive2 a single source of failure for the whole setup.

Now, each external hard drive is specified separately in turn in the server schedules and we backup to the boot drive as well. I’m pretty sure somebody will notice if the boot drive fails.

The schedules do send e-mail updates, but somebody does have to read it every day. And FileMaker Server 9 doesn’t help by sending emails on every execution, succeed or fail.  People start to ignore messages of success.

So, my updated outlook: I’ll go ahead and take a performance penalty for backing up to the boot drive at least a few times per day.

Tags: FileMaker, FileMaker Server

The case of the Mac mini mentioned in part one made me think a bit more about drive operations and backups because when the users were first reporting slow performance, one of them would go look at the server, and see it in the middle of a backup operation. This backup operation was not one of FileMaker’s, it was an Automater script which was copying the databases in the backup folder to external backup drives. (It was triggered hourly by a product named “Proxi”.)

It quickly got all the blame since, when the user quit it, performance returned to normal.  So, if that simple copy operation was too much for the drive to handle while doing FileMaker operations, perhaps FileMaker’s own backup operation is also too much.  (But much less visible than the Automater script.)

Thinking again about the number of operations a drive can perform, and how many we’re asking it to do, we take a new look at backups. So, what might be in a backup operation? In a simple version, one might think of disc-read operations to read the entire set of database files and a set of disc-write operations to write those files to a destination.  If the source files and the destination files are on the same drive, that drive must do all that work while doing the work of serving a FileMaker database.

So, how do we keep the number of disk operations to an absolute minimum? Simple, we have all backups go directly to another hard drive. It doesn’t have to be an external drive. It can be another internal drive. Now, No matter what you do you won’t be able to take away the read operations required to do a backup. But, at least the write operations can go to another drive.

In the case of our Mac mini, we cut the operations down by backing up directly to an external hard drive.

Tags: FileMaker, FileMaker Server

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.

Tags: FileMaker, FileMaker Server