I’d guess that 90%+ of LGF’s readers aren’t aware that something huge happened here over the weekend. And that’s exactly the result for which I was hoping.

The entire back-end LGF Blog Engine was swapped out, while the site was live. The whole thing. It’s a little like rebuilding a car’s engine while driving at 75 mph. (A little.)

OK. Maybe 45 mph. Since it was the weekend and most readers weren’t at “work.”.

Yesterday the LGF Long-Running Hamster Squad in server 1 had a rest for the first time in five years. Whew. The main server was operating at much lower loads than usual, since the site is now split between the display portion (on server 1) and the data portion (on server 2). And the newly recruited Hamster Squad in server 2 had a moderately stressful, but certainly not nervous-breakdown-inducing time of it. Neither server ever got close to the danger zone.

The new architecture is very, very scaleable (an adjective that should appeal to lizards). This means that as traffic/bandwidth/server resources increase, I can simply add new servers to handle the load, with the requisite hamsters. That’s the theory, anyway. We’ll see about the practice.

And today I added another very nice feature I’ve been developing and testing for a while, that will be completely invisible to most of our readers; the session information (which keeps track of your login information when you post comments, and lets us display the current number of visitors online) is now stored in the MySQL database, along with the majority of the site data.

Why? Because the default PHP session management functions use files on the disk to store data—and the whole point of this upgrade is to get away from flat files, to reduce overhead on our main web server. So now it’s all in MySQL, and another big source of disk thrashing has been eliminated. Not only that, it gives me a huge amount of flexibility in how I handle the sessions, what data I store, etc., and it’s much more secure than the default flat-file method.

So how’s the makeover working so far, for its main purpose of helping us stay online during major traffic surges?

Well, the last time Fark.com linked to us, the traffic took us offline; the web server crashed and had to be rebooted. We all know how painful that can be.

Today we had not one, but two links on Fark—and although the load got pretty high and we slowed down a bit, we never were close to a server crash.

That’s a great sign.

Next step: setting up replication so we’ll have a hot backup and a fall-back server for emergencies. (And by the way, as a result of all this expansion, hosting costs have increased tenfold—but it was necessary.)