Yesterday I noticed that my GroupWise mailbox was snappier. Didn't know why, and thought that maybe the email archiving software had trimmed my mailbox (which would be a good thing). I've got 19 GB in my mailbox, and 18 GB of it ought to relegated to the archive. Nope - turns out my co-worker had added RAM to the server while nobody was watching.
GroupWise has a mode called Client/Server where your desktop fat client talks to the server via TCP/IP packets. Back around GroupWise 5, if the post office agent (on the server) went down at all, everyone knew it because every machine immediately got an error on the screen: lost contact with server! Somewhere around GroupWise 6 or 6.5, Novell reprogrammed the fat client to wait instead of immediately throwing up an error. The timeout is about 30 seconds.
Last year we started a whole push to virtualize as much as we can. We use Xen virtualization, as that is what Novell supports and includes in SuSE. Paravirtualization has a few advantages, one of which is that you are essentially running a guest OS that is the same as the host OS. So when it comes time to reboot, the OS is already loaded in RAM - the Xen host just has to create the guest, and do a bit of linking. We typically see an init 6 take ten seconds from time we lose continuous ping packets to the time we get them back.
My co-worker was looking at the server stats, and the mail server showed pretty much 100% utilization 24 x 7. Certainly the post office seemed slow. He thought it might be a process gone bad, but no - the mail server was just that busy. It looked like it could use a little more RAM though.
(Prepare by opening the Virtual Machine Manager)
Edit the VM definition to have another 1 GB RAM
It is up, and before the 30 second timeout from 120 fat clients. Nobody notices, nobody calls. It just works (and faster, too).