Thoughts on live chat 
Sign up | Plans | Help | Contact
Tags


Filed under

speed

 
September 1, 2008

Faster online and offline image for IMAGE-ONLY users

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.

Filed under  //   javascript   livehelp   no   optimization   python   speed  

Comments [0]

October 17, 2007

As lighttpd as a feather as quick as a wink

Ok, that title was pretty lame. I digress.

Here’s the news: we’ve migrated hab.la’s front end proxy servers on to lighttpd so now we have joined the in crowd for web2.0 applications (delicious .. anyone who does ruby …etc ). As an end user you should see a general speed increase for most aspects of hab.la. However, this migration was done to specifically address some of the problems apache experiences when dealing with large number of passive connections. [Jeremy Zawodny has a great post on dealing with slow HTTP clients – which is very similar to what hab.la appears to be from the proxy server point of view at http://jeremy.zawodny.com/blog/archives/008496.html. You might want to also read about cache performance issues http://www.mnot.net/blog/2006/08/21/caching_performance ]

Ideally we should remove the proxy server from the mix and you should hit the RPC server directly, either by running the RPC server on port 80 (requires root) or by some sort of TCP level routing trick to tunnel requests around from port 80 to port 8000. But, that’s a fix for another day.

Filed under  //   apache   backend   cache   lighttpd   optimization   performance   proxy   slow   speed   tuning  

Comments [0]

July 9, 2007

Oh yeah .. speed holes!

Way, way Back In The Day, I got a big kick out of optimizing my code. I would write entire programs in assembly language, then spend hours sweating about cache lines and pipeline stalls in order to shave a few milliseconds. (Of course, that was before I had a job or a car, so I had plenty of time for those things.)

So I was undaunted when we discovered that Hab.la’s performance sucks. A user added Hab.la to a site with pretty heavy traffic, and the whole system promptly slowed down to the point of unusability. That bumped speed up to top priority.

My tweaks today sped Hab.la up by a factor of about 55 in laboratory conditions. In real-world conditions, the improvement is more like 26x, which is still not bad for four hours’ work. We shall see if this is sufficient for now.

Filed under  //   back   day   in   optimization   speed   the  

Comments [0]