My life is an utter bore right now. Didn't get much (translation: any) sleep last night because I had a lot of stuff to catch up on.

I'm currently helping in the move of LB7 to the new owner's site (as well as working out the logistics of transfering the money ... Escrow.com has impressed me so far throughout this transaction) while trying to persuade a client to switch from a Flash-driven site to a standards-compliant site (Color Matters).

This was the first client I actively pitched standards to, so it's not going so well. I'm sure I'll get the pitch down with more practice so the future clients will love standards as much as I do now :)

So my main task last night (besides doing some work on maintaining the servers) was going through and fixing up user registration on Tabulas. Before I left for Korea, the aces.tabulas.com (a personal data server) maxed out the users, so it wasn't creating new folders for users. Thus, the gallery features weren't working for many people.

Diagram of Data Distribution in Tabulas

Let me first explain this diagram. This diagram is a very rough outline of how data is stored across the Tabulas network. You have two basic types of backend storage; textual and multimedia data types. The textual information (entry) as well as all settings are stored in a mySQL database (Note: I think this is bad architecture; in the long run I would actually like to offload JUST the entries onto a separate server).

Within the multimedia hierarchy there are "personal data servers." These store your gallery files (and once 2.0 launches, they will also each store your RSS files, media files, CSS files ... anything that's multimedia-related will go there). The advantages to moving static stuff like that is for performance reasons; the best way to optimize a large site like this is to separate dynamic and static data ... you can tweak many settings once you know certain pages are or are not dynamic (you don't have to leave Keep Alive on in Apache for dynamic data).

So aces.tabulas.com, the first PDS, maxed out while in Korea. This prevented new users from uploading images. So in the first test of scaleability, I tried adding the new PDS (lca.tabulas.com, which stands for my new love, Lee Cheong Ah) ... with a little difficulty. Apparently some of the older PHP scripts had to be updated to handle these changes ... but in the end, it took me only about 3 hours to set up the new PDS (this included time in hacking the old control panel scripts ... 2.0's CP already inherently handled this). And in the future, it will take me maybe all of 10 minutes to set up another PDS. I could probably automate it if we ever get to a point where we get 30,000 users within a short time period ;)

So be happy! The first test of scaleability is the direct result of the past few months of work (mostly backend stuff that none of you saw). This is what I meant by working on more scaleable code - it allows me to handle a greater volume of users with real ease (just by throwing more hardware at the problem).