As I’ve mentioned before, one of the main reasons I was brought on board was to help out with performance and scalability.  And let me tell you, we didn’t waste any time getting right into the thick of it.

In case you haven’t checked the stats, SocialAdr has posted almost 30,000 backlinks to members’ sites.  That’s a LOT of linking in a pretty short period of time.  We keep track of every individual link: who created the link, who shared the link, what the result was, etc.

We use that data for all kinds of things like showing you what’s happened to your links and figuring out what’s available for you to share.  As you may have guessed, we’re crunching a lot of data to deliver some of the pages on the site.  And that translates into a lot of server resources and sometimes, slow response times.

So naturally, as the new guy, my first suggestion was that we completely rip out the entire history tracking system and rewrite it. :)  To Kane’s credit, he didn’t hang up on me and call the whole thing off.  Instead we started talking through how it could work, what impact it would have, and how hard it would be to get done.

The amazing thing is that less than a week later we rolled out an updated version of the site with a completely revamped history tracking subsystem.  You probably saw the unassuming post announcing some performance enhancements; we didn’t make a big deal about it, but it was no minor upgrade.

If you haven’t already, you’ll definitely be able to tell how much faster the site is.  The share queue, the history page, and even the dashboard are much more responsive.  Even better, as the number of users and shares increases in the future, we shouldn’t have any trouble handling it in stride.

Now that we’ve got that behind us, we’re turning our focus to other tasks including keeping the share queue full, revamping user accounts, and enchancing and adding to the bookmarking services.