It’s getting down to the wire!

I’d originally predicted starting the semi-private beta next week. While it looks like I’ll have the app ready by then, I am going to need a little longer to get it up and running on the production server, so the actual beta will be in about 2 weeks (god willing).

And if you find any glitches, please let me know.

I’d thought, “ok - this is simple, get and set the cache…big whoopee.” But I hadn’t really thought it through. This problem, like so many in software was like an iceberg. Most of it was submerged, hidden.

{BEGIN TECH STUFF}

You see, I can’t just cache the output and expire it when it gets too old… Instead, I have to cache a data structure that tells me when I need to do work and when I can skip it.

I knew that this would necessitate touching the cache at every point in the code that needs to turn on the “do work” mode. It’s ugly, but the only way to do it. And I did make a nice set of wrapper-classes so the code isn’t too interdependent.

But what I hadn’t thought about was that I have to be able to figure out the cache keys every time I touch the cache (I know, not exactly rocket-science). At most of these “touch points” only partial information is available, and that partial information is different at each point.

Which means lots of little, unique pieces of code that can’t be reused.

And lots of hoops to jump through to add cache tests to my unit test suite. (shhhhh! they’ll kick me out of the PHP club if they know I use unit tests)

{END TECH STUFF}

So why is software development just prone to this sort of underestimation? Could it be that I just didn’t know what the hell I was doing, since I’d never implemented that kind of cache before?

Probably a little bit of both, but I’m going to go with the former (big surprise, I know).

The problem is that despite all of our best efforts, code is dependent. The rock you throw into one side of the pond causes ripples all the way to the other side of the pond.

We try our best, I know, to make our components loosely coupled. We try to hide the details behind a public facing protocol. All of that is good, but it doesn’t get rid of dependency, it just pushes it all into one layer. Which isn’t much help if you’re building that layer.

In fact, I would argue that software, by its nature is highly dependent. Otherwise, how could you account for its brittleness? The human brain can have a spike driven through parts of it and keep limping along. But just try corrupting a few dlls and see how far you get. Under those conditions, the best we hope for is “graceful” failure.

Maybe the best thing we can do is treat our efforts towards loose-coupling like a diet. The diet doesn’t mean you don’t need food, but that you try to eat what’s good for you. Maybe we should only use the tight coupling that’s good for us.

And in the end, we can at least take comfort from the fact that the only thing worse than tight coupling is no coupling. The only thing that will make a project later than too much interconnectivity is to try to build it on an XML-driven rules engine flown down from the heavens on the back of Pegasus and glowing with faerie dust.

You see, I was using codeigniter for ChatSpring’s back end. But I was only using it for the pretty url-routing. I wasn’t using active-record. I wasn’t using *any* features that I thought would cause a huge performance hit.

But the framework was just eating up CPU like crazy.

On my development machine, I can pull 50 requests per second for a simple “hello world” page in codeigniter. My actual controller that hits the db was down at 20 rps.

But now that I’ve removed CI from my app, I’m up to 80 requests per second for my controller that does real work.

That just seems crazy.

And that bit I wrote about mysql being as fast as memcache. That’s completely wrong. It’s much faster, but CI was acting as a bottleneck that made it appear slow.

The beta is going to be “semi-public,” which basically means that anyone’s welcome to an account, but we’re not going to do the typical 6-month-promotional-extravaganza. Instead, there’s going to be a hard-core month of production-level testing, followed by release of the paid version to the public.

There are a few reasons for this.

1. Large betas, in my opinion, are less of a requirement for hosted web-applications. There are no installation and platform issues to contend with. And any glitches can be fixed without having to distribute patches or anything of the sort.
2. ChatSpring is a boot-strapped company. I don’t have any real desire to pay for servers that aren’t generating revenue.
3. We’re going to have a generous free-trial period, so even when we do release the paid-version, you can still kick the tires for free, with no CC required.

On another note, I’m going to be moving this blog to a VPS at Linode. Don’t get me wrong, the guys at enginehosting have been great. I’m reluctant to stop using them, but I’ve gotten to the point where I need a vps.

…and in case anyone’s curious: chatspring itself will be hosted at SoftLayer.

Hizaa!

Of course that means its time to pay a lot of technical debt. All of those little, fun things, like escaping user input, ie compatibility, and of course….optimization.

Here’s a little sampling of what I’ve learned.

1) Message queues are a gift from God: Last weekend I wrote a little queue server using python and the twisted framework. That immediately gave me a 500% performance increase for insert-heavy work.

2) Memcache w/ php is slightly slower than the mysql cache. I’ve been testing this all morning. Even when I give mysql 1000’s of inserts and retrieve data at the same time, it’s still faster. I think this arises from the fact that I have to create an additional TCP connection to use memcache, where as I already have a mysql connection open. (So memcache may be faster in a perfect world, but not in my app)

3) A lot of performance tweaks are more about consistancy than about pure performance. They may be slower in certain cases, than non-optimized code, but they make your app work consistently under changing conditions.

Plus a bonus tip:

If you’re using php, don’t forget to use one of the code caches like eAccelerator. That’s an immediate 100% performance boost with no need to change your code.

I haven’t been posting much lately because I’ve been crazy busy putting the finishing touches on Chatspring v1.0.

Let me tell you - It’s great to finally have something to show for all of this work.