In the spring of my last year at Washington State University, I bought an eMachines M6807, one of the first reasonably-priced laptops with a 64-bit processor in it. I almost immediately installed a 64-bit distribution on it, and then almost immediately went back to 32-bit (if I remember correctly, it had a Broadcom wifi card that could only be used with 32-bit ndiswrapper).

Somewhere around the time the b43 driver came out, I switched back to 64-bit Fedora and, in the two laptops since then, have stuck with it. Until today. When I upgraded from Fedora 13 to Fedora 14, I started running into memory problems, and it finally came to a head today when Firefox, Evolution and Eclipse combined were enough to make my laptop start swapping. Heavily. The hard drive light may be pretty, but watching the desktop sitting unresponsive isn’t my idea of fun (or of being productive).

I have 3GB of RAM on this laptop. There should be little need for swap, and no thrashing at all. I decided to install Fedora 14 i386 on a second partition and see if it made any difference. Sure enough, with Firefox, Evolution and Eclipse open for several hours, I’m currently sitting at 815MB used, 2185MB free.

So where do I even start filing a bug on this?

Seven years ago, I got pretty annoyed with keeping my students’ computer grades in a spreadsheet, so I wrote a small web application tied to a MySQL database. Over the last few years, this program, called the Lebanon Evangelical School Scoring Online Network, or LESSON (yes, I know the name is ugly, but I like the acronym), has grown to the point that it’s being used by two of our sister schools and is used by parents to see how their kids are doing in realtime (or something close to it).

One of the early requirements was that LESSON would run *fast*, which meant that it had to be run internally (our internet just isn’t fast enough for it to run externally). We do have a static IP address, so we allowed external access to LESSON, but it was designed to be primarily accessed from within school.

In the wake of Firesheep‘s release, I decided (rather belatedly) that LESSON should be running completely under https. It only took a few minutes to set up the appropriate Apache configuration, but within a day, the complaints started pouring in. “LESSON is too slow.” “It took me three minutes to log in!” “What did you do to LESSON?”

Well that’s not cool. It turns out that establishing a https connection requires far more bandwidth and a few more round-trips then a normal http connection. Our bandwidth is no longer enough to make accessing LESSON reasonable.

We can’t increase our bandwidth (long story, but we’re maxed out at 128/875kbps). I don’t want to go back to an insecure connection. But I can’t leave LESSON unusable.

After I bit of research, I found that MySQL supports master/master replication. We do have a dedicated server running in the States, so, after making some changes to make sure that I wouldn’t have conflicting keys if the the servers lost connection, we were up and running.

And, not a minute too soon. Within a few hours of LESSON going live on our US server, we lost our internet here for roughly 24 hours. When we finally got it back, within two minutes our local master had synchronized the changes from the US server (and vice versa). As far as anyone outside of school was concerned, LESSON was running faster than ever before (when it would have normally been unavailable). And inside of school, LESSON is still as fast as it’s ever been.

Signs credit: Slightly confusing signs by Dano. Used under CC BY