Back in late November I tried to get iCal Server running on some older hardware and this is what happened…
I ran iCal Server + iCal in a test environment on a older Xserve–Dual G4 1GHz 2GB RAM Mac OS X Server 10.5.5–in this test environment with only a couple of test users and I noticed a significant increase in CPU activity due to iCal but it seemed that it wasn’t something the server couldn’t handle. A month later when I rolled out the service to 60+ users the server was brought to its knees. It ramped up to 100% CPU usage as more users logged in and by about 11AM that business day it ceased to be functional. Anyone trying to connect timed out before they received updates.
I have not been able to track down any specifics as far as something I can “fix” to prevent this problem as my iCal Server install is Apple default and other than running the CPU load at 100% there was not a single error reported/logged. I’m going to use brute force to work around the issue but I would like to find a better approach.
I am going to try to roll out this service again but hosted on a brand new Xserve 3.0GHz Quad-Core Intel Xeon 16GB RAM (I’m lucky in that I work for a bunch of lawyers).
Now two months later I think I have finally got it working…
Here are the details of what we have running in our offices:
Server Hardware:
Xserve 3.0GHz Quad-Core Intel Xeon 16GB RAM, 1.6TB RAID 5. (complete overkill?)
Software/OS:
Mac OS X Server 10.5.6 (completely stock, no open-source mods) which runs iCal, iChat, and VPN. On our network we run Open Directory, Kerberos, and we manage our own internal DNS (all Mac OS X server based). Everything more or less works (although I can’t even keep track of how many things I’ve kludged to “force” Apple server stuff to work the way it is supposed to. For example my DNS is a clean BIND install as I completely removed the Apple BIND setup yet it still plays nicely with the Server Admin GUI tool.
Users:
65 users with about 20 having pre-existing calendars from NUTD each with about 1400 events that were imported into iCal. All my users are using various Mac systems running 10.5 (with a few throwbacks on 10.4). I expect that nearly all my users will give about 30-40 users read permissions to their calendars and 5-8 users read/write permission.
So what happened when I rolled it out this time?
As before it was very slow for all users on the first day which I expected. There are 52,079 events listed on the server, 56 user calendars so far and 16 groups. There have been some brief CPU spikes around 91% but the average CPU load works out to 26%. I am hoping that after a week or so it will start to average 18% – 20% during business hours. Before I loaded all the imported calendars and users started connecting the server load averaged just 2% with the same three main services running (iCal, iChat, VPN).
Once each user has their own calendar fully loaded as well as any delegated calendars the iCal client remains very responsive since events are first being cached locally. The background sync with 56 users actively using the system has–so far–had little impact on our network. We have three satellite offices that connect over dedicated VPNs (sonicWALLs) so their connection speeds are not always very good but each local network is Gigabit ethernet and 802.11g wi-fi. After the initial day’s surge the average bandwidth usage on the server is under 40 KB/s in/out with some spikes of course (at this point most of the data is outbound which makes sense).
It is sad that such a powerful server was required to host this system but I expect this is largely due to the fact that I was importing many pre-existing calendars from an earlier system. If the iCal system had been rolled out with initially empty calendars I might have been able to get by with a slightly lesser server (but in any case the dual G4 Xserve would never had supported so many users).