So first, it’s been a while since I’ve posted on the Hab.la (soon to be Olark.com) blog. A lot of exciting things are in the works as always. This week we launched a bunch of new plans. You probably noticed the new signup process, we tried to help new users experience Hab.la before they had completed signing up.

We monitored the changes that we made in the signup process using a tool from our friends at MixPanel. Which lets us compare the funnels on our old signup and our new signup. If you are confused by Google Analytics, or want to track events with a little more granularity I recommend checking their product out. In any case the new signup appears to be performing about 5% better getting people setup on their sites. (But is not yet available to Internet Explorer Users).

We’ve implemented RabbitMq to help speed up transcript processing, you’ll see some nice improvements to transcript processing in the next week or so.

We decided to become Olark.com to help our visitors find us better. When you see search referrals coming in for people searching for “hab.la.com” you start wondering how much traffic you are losing from people who can’t remember your name or try to spell “habla” like “ahblah” or “ahbla” or “obla” or “habla.la” or “habla.com”.

Roland has been working on some great new graphics for Olark. Think Lark – the bird, but far more valuable to your business than twitter :-) [at least in terms of direct value that we will be able to measure and present to you! ]

We welcome feedback on the name, but let’s just say we wasted far too much time figuring out the new name to be easily swayed to something new

I spent some time this week hacking on Puppet, it was a bit of a learning curve, but seems promising for managing configuration across all of our servers. To be honest we still have a manageable number of servers, but something like puppet lets me easily build classes of nodes with specific configuration. I.e. I can define a web node with nginx, haproxy, lighttpd, and apache, or a DB node with mysql. When I deploy a new server I just tell puppet what type of server it is, and it syncs up the right firewall options and configuration options. [I’ll post some of our specific config another time]

The great thing about using puppet for deployment, and storing the configuration in GIT, is that I can build a post-receive hook that take the latest commit to git, pushes it to puppet, let’s puppet update all of our servers. Just add a post-receive hook to your remote git repository. And make sure you have a password-less way for your git repository to update puppet.

#!/bin/bash
#.git/hooks/post-receive
ssh puppet@puppet "cd /etc/puppet && git pull"

So now I can edit config for all of our machines in textmate, commit with git, and sit back, and manage our entire cluster without logging into a single machine using SSH :-).

-Ben

Hi guys, I realize our blog posting has been a little lacking recently, but never fear, the less we blog the more exciting changes are around the corner.

Here’s a brief overview of a few of the milestones we hit this month.

We incorporated in Delaware. (For the amount of money we paid, the photocopied certificate of incorporation was a bit of a let down.)

We moved to California. Fun in the sun, sure beats the snow of Michigan (but it’s summer).

We printed stickers. If you found one of our stickers a Apple’s WWDC or somewhere in San Francisco, take a picture of it and send it in for a discount on Hab.la. Roland will be trying to hand out as many cool Hab.la stickers as possible this summer.

Other things to come. (I don’t want to give too much away), but we have a planned server migration coming up (to Rackspace) and some hot new features on their way.

Oh yea, and check out our one click account creation for Gmail users.

I’ve been trying to replicate the Hab.la experience on AIM and on MSN since around July of 2008. Today, after working on this problem off and on for far too many months, improving the existing pure python libraries for OSCAR (AIM’s protocol) and MSN, and finally rewriting everything using libpurple (the brains behind meebo, pidgin, adium, and finch). I have to admit defeat (at least in the short run).

It appears that the rate limiting on both MSN and AIM, makes it far too unreliable to try to build a bot, that sends a high number of status messages to the AIM and MSN servers (key to some of the protocol hacks I needed to make it work). After trying a lot of hacks, and getting everything working for small numbers of concurrent users, I’ve decided to stop bringing webusers online and offline as visitors come to your website – I could not stand behind the reliability of the service. From now on MSN and AIM users will have access to a limited version of Hab.la where they will not be able to easily initiate conversations with visitors to their websites. Although, their visitors will have no problem initiating conversations with them, and operators can still attempt to follow particular users by sending the message “/follow” to a webuser buddy on their buddylist.

We may add a few other modes of use for these protocols to make it easier to initiate conversations in the future, or bring back the old method if we can decrease our MSN or AIM ratelimit effectively, but this is unlikely to be a high priority in the near future.

We continue to recommend either connecting to Hab.la directly using a Jabber(XMPP) client. Or using Hab.la with an existing Gtalk or Jabber client. You will be able to take advantage of all of Hab.la’s features with either of these two approaches. Most notably: monitor visitor location on a website and initiate conversations directly with these visitors.

Some of our users are in environments where they can’t embed the hab.la javascript directly onto their websites. As a workaround we developed a method of showing an image that displays hab.la status on their websites.

A few days ago, I noticed that the status display was a little slow for my liking. In fact, it was running as a normal CGI ( a big no no), but since not to many people were using it, it’s performance wasn’t that big of a deal.

Today, I increased performance by 1800%, speeding up the status image response time from ~0.474 seconds to ~0.026 seconds.

ben@lyle:/var/www/online# time curl "http://dyn.hab.la/online/image2.cgi/4324-24618-10-8812/image.png"

real    0m0.474s
user    0m0.016s
sys     0m0.004s

Versus:

ben@lyle:/var/www/online# time curl "http://hab.la/status/4324-24618-10-8812/image.png"

real    0m0.026s
user    0m0.012s
sys     0m0.004s

What sped it up so much? First, I replaced the CGI script, with a very lightweight webserver. This made it so that python didn’t have to instantiate from scratch every time image.cgi was loaded. Second, I replaced the old calls to our RPC server, with newer calls to our memcacheD servers. There are still too many MySQL calls in this process, but optimizing those into pure memcache can wait for a while.

To learn more about using Hab.la without Javascript, take a look at My blog post or our tutorial for websites without Javascript.

This is not the official release of these new features, but I thought I’d let our brave beta testers take a look at what we’ve been working on for the past month.

If you navigate to: http://staging.hablagroup.com:3000/

And sign up for an account, you will be able to chat with users on your website using MSN or AIM. That is to say, jabber will no longer be required!

Keep in mind that this is our staging server, and by no means stable. We often push out new releases, and wipe the database without warning. However, it might be fun for some of you to play with while we work out the bugs, before we send it to production.

I know most of our users really like updates to the front end, to the Hab.la chat box, and methods of theming the window. However, everyone should be happy to know that since the memcacheD edition of Hab.la has been deployed we have sped up Hab.la’s average response time, while cutting our CPU usage in half. I.e. we are now handling more traffic than before with about 1/2 the load. Bring on the new users :-) – and we haven’t finished optimizing!

Front end improvements will resume later this week :-)

haha, I wish I could tell you about the exact performance gain in the version of Hab.la that I just pushed to production. However, we don’t really have a great method of benchmarking code outside of production and so we won’t really know the TRUE speed ups until we have a few hours of statistics generated from actual use.

What I can tell you is that I have spent the last week or so refactoring the backend RPC server that handles the connection between Jabber and the JavaScript widget to make the code much cleaner, and the session management far better.

Here’s a brief summary comparing the new setup with the old setup.

Old method of session management: mysql Minimum of 2 SQL calls per RPC call. I.e. we load the session from mySQL perform updates on it, and save it back to SQL one time per hit. We were doing this over 200,000 times a day, generating approximately 400,000 SQL calls from session management alone (200,000 writes).

New method of session management: MemcacheD Unlike most high traffic sites that use MemcacheD we don’t have to perform a MySQL write every time a session is updated. Therefore memcacheD not only reduced mysql reads, it also reduces mysql writes. We now only write conversation buffer changes to Mysql. This means that instead of updating the mysql copy of the Hab.la session each time a visitor hits the RPC server, we only write it to SQL when an important event occurs (i.e. a message is sent), so if a server goes down we might lose our temporary record of what page your visitor is on – but won’t lose the conversation.

We get about 3,000 messages sent on Hab.la a day. So this reduces our number of mysql writes to about 3,000 + the number of visitors we handle a day (currently about 12,000 on average). So 200,000 mysql writes, becomes 15,000 mysql writes, and 200,000 mysql reads, becomes 0 session related mysql reads.

Of course there are other mysql related reads that occur during session setup, and before initiating a chat, but the vast majority of our reads and writes come from session handling, and the new memcacheD option pretty much eliminates the need to read from mysql to get session data.

In the coming weeks I will be phasing out even more of the mysql reads, to continue to make it easy for Hab.la to scale going forward.

As always, please let me know if you are experiencing any problems with the new RPC server, it passes my unit tests, and I haven’t seen anything in the error log, but that doesn’t mean there aren’t conditions we’ve overlooked.

I just finished implementing a feature to make it easy to customize all the colors used in your Hab.la window to match your site’s look and feel. AND you can do it without writing a line of JavaScript! (Let’s see another FREE livehelp solution beat that! ;-) )

Anyone with the Hab.la code on their website can log into the their My Hab.la page, and than customize the colors of their Hab.la window using the color customizer. As a user all you have to do is set the colors using the handy ‘color selector’ and press ‘save’. That’s it!

And if you want a new color scheme tomorrow, just come back to the Hab.la website, and change it. No need to touch the source code of your web-page at all!

In other less happy news, I realized that there was a race condition pushed out in last-night’s Hab.la update. I fixed the race condition in the recent push. Essentially it was causing Hab.la to display the “invalid site ID” error, when everything was actually kosher.

A long time ago I wrote the first version of the JavaScript color customizer. It is probably the only JavaScript based tool for customizing a livehelp, livesales, or chat widget application. Of course it’s never been as user friendly as it should have been.

I just spent some time hacking around on a new color customizer to make it easier for Hab.la users to customize the colors of the chat widget. Now, every color can be customized. The new Color Customizer.

The current version of the customizer still requires users to paste JavaScript code onto their web-pages. However, in the near future we will integrate the Color Customizer into the new and improved Hab.la Customizer where you can customize most of the text fields in Hab.la without having to edit any JavaScript.

I pushed out the latest version of the Hab.la JavaScript tonight. (I actually have been slowing rolling it out over the past few hours, but it is completely deployed now)

Before we do any deploy we test the JavaScript with IE6, IE7, Firefox, Safari, and Opera. It’s funny how you need to make simple tweaks for each browser and so the Javascript will compress correctly. Funny in that so much time is essentially wasted because Microsoft didn’t listen to W3C standards.

The new JavaScript should be completely backwards compatible with the old setup. Please let us know if you did a lot of customization on Hab.la, and your customizations no longer work.

The most interesting aspect of the new JavaScript is it’s support for dynamically loading themes and plugins, and the ability for Hab.la users to customize their Hab.la windows without having to write JavaScript. (We will be rolling out a control panel for managing these features soon).

In any case the transition should be relatively transparent for most users. We will be adding documentation on the new features this week.