David Cancel and I have had sort of a passing vague, same space and thought process, living in the same Metropolitan area kind of distant acquaintance for about the same year.

About 2-3 months ago, he wrote a pair of articles discussing the efforts he has undertaken in order to try and offload some of the traffic to the servers for his new company, Lookery. While they are not current, in the sense that time moves in one direction for most technical people, and is compressed into the events of the past eight hours and the next 30 minutes, these articles provide an insight that should not be missed.

These two articles show how easily a growing company that is trying to improve performance and customer experience can achieve measureable results on a budget that consists of can recycling money and green stamps.

Measuring your CDN

A service that relies on the request and downloading of a single file from a single location very quickly realizes the limitations that this model imposes as traffic begins to broaden and increase. Geographically diverse users begin to notice performance delays as they attempt to reach a single, geographically-specific server. And the hosting location, even one as large as Amazon S3, can begin to serve as the bottleneck to success.

David’s first article examines the solution path that Lookery chose, which was moving the tag, which drives the entire opportunity for success in their business model, onto a CDN. With a somewhat enigmatic title (Using Amazon S3 as a CDN?), he describes how the Lookery team measured the distributed performance of their JS tag using a free measurement service (not GrabPERF) and compared various CDNs against the origin configuration that is based on the Amazon S3 environment.

This deceptively simple test, which is perfect for the type of system that Lookery uses, provided that team with the data they needed to realize that they had made a good choice in choosing a CDN and that their chosen CDN was able to deliver improved response times when compared to their origin servers.

Check your Cacheability

Cacheability is a nasty word that my spell-checker hates. To define it simply, it refers to the ability of end-user browsers and network-level caching proxies to store and re-use downloaded content based on clear and explicit caching rules delivered in the server response header.

The second Article in David’s series describes how, using Mark Nottingham’s Cacheability Engine, the Lookery team was able to examine the way that the CDNs and the Origin site informed the visitor browser of the cacheability of the JS file that they were downloading.

Cacheability doesn’t seem that important until you remember that most small firms are very conscious of the Bandwidth outlay. These small startups arevery aware when their bandwidth usage reaches 250GB/month level (Lookery’s bandwidth usage at the time the posts were written). Any method that can improve end-user performance while stilll delivering the service they expect is a welcome addition, especially when it is low-cost to free.

In the post, David notes that there appears to be no way in their chosen CDN to modify the Cacheability settings, an issue which appears to have been remedied since the article went up [See current server response headers for the Lookery tag here].

Conclusion

Startups spend a lot of time imagining what success looks like. And when it comes, sometimes they aren’t ready for it, especially when it comes to the ability to handle increasing loads with their often centralized, single-location architectures.

David Cancel, in these two articles, shows how a little early planning, some clear goals, and targeted performance measurement can provide an organization with the information to get them through their initial growth spurt in style.

Dear Flickr:

I have been wondering for sometime why downloads from your site seemed a little sluggish at times.

At first I blamed your unprecedented growth and success. For a little Vancouver startup (I am a BC boy myself), your entrance onto the stage of social networking applications has been phenomenal. The move from zero to infinity may have played a part in the performance I was seeing.

Nope. There was something else going on; I could see it every time I loaded a Flickr page in my browser. There was something else going on.

So today, I checked something out, and found the problem.

You need to enable persistent TCP connection on the static.flickr.com servers.

Now, that is the simple answer. I know that with large, web-based applications, enabling something as monumental as persistent connections could cause serious issues. If the architecture of the system was not designed to handle persistent connections, turning them on could cause the entire system to collapse.

There are legitimate, if mis-guided, reasons for disabled persistent connections. Some administrators believe that it is actually more efficient to have a client open a connection for every object. Easier to manage state, etc. The only problem is that in order to do that, you have to tune the systems serving data to shorten the amount of time a closed connection spends in a TIME_WAIT state.

When a TCP connection is closed, the socket is not immediately closed by the system in a default configuration. The TIME_WAIT state is the holding pen that these connections are pushed into. While in this state, the socket is locked and this may count against the incoming TCP connection queue, forcing the network stack to delay or reset new incoming connections.

Still, as Flickr is a worldwide company, the delay that the lack of persistent connections injects is astounding for locations in Asia. If you want to grow your business, and support more services, this will likely become a bottleneck very quickly.

Have a great weekend!

smp

Technorati Tags: Flickr, persistent connections, TCP, http, web performance, scalability

Kathy Sierra once again reminds us that only the truly intelligent employers realize that the Work/Life balance is more important than ANYTHING else. [here]

And her reason for this: clients who abuse startups and small companies who then abuse their employees to work miracles.

The takeaway:

And as the tech employment market starts to tick up ever so slightly, it’s becoming less and less of an “employer’s market” again. I don’t care about the Aeron chair, but I do care about having a life beyond work. If you can’t make your business model work without promising your clients a miracle (which we’re expected to pull off), change your business model! And when you DO ask us to go our ass off again, a little worshipping goes a long way ; )

alarm:clock has great advice for startups: Fire Your PR Firm! [here]

After the presentation I attended last week with a candidate PR firm my company is interviewing, the five points offered up really hit home.

One of the things that David Parmet and I disagree on. [here]

Jeremy Pepper writes more here.

Jeff Nolan comments here.

Lots of inward-looking thoughts from some of the VC blogs that I read.

Jeff Nolan flames alarm:clock for claiming that VCs are greedy, soulless vampires [my paraphrasing].

A VC and Brad Feld comment on Paul Graham’s Essay, “A Unified Theory of VC Suckage”.

I wonder why so much attention is now being focused on the VC community? I kinda like them, as they have provided me with two very solid companies to work for over the last 6 years.

My opinion, not backed up by any facts or knowledge, is that there is a new bubble occurring, and people are already looking for someone to lay the blame on when it bursts.

The VC community, on the other hand, has learned a lot over the intervening years. To claim that they are going to let the madness that occurred 1995-2000 to occur again is highly unlikely. The bubble is occurring because there are smart companies driving smart ideas to people who are now ready to use them.

Now, whether the VCs will drive this bubble like they drove the last one remains to be seen. I think that the caution and conservatism (if that word can be applied to the VC community) that arose from the flame-out in 2000-2001 will see more firms driving their own success through the methods seen in Paul Graham’s other essay, “How to Start a Startup”.

A while back, I posted that I had submitted a presentation concept for OSCON 2005. [here]

Got a very nice rejection letter Friday.

Then Dave Winer posts a link to this fantastic quote.

But it’s clearly not the only criterion considered by O’Reilly & Associates for its event lineup. There’s a distinct rock-star syndrome going on with O’Reilly conferences that is a bit disappointing to me. So many of the scheduled speakers are former speakers, re-hashing, remixing old speeches that keep them busy on the lecture and blog circuit for months or years at a time.

I wish this weren’t the case with the ETech conference. I wish there were a lot more unknowns speaking at the conference, about technology that’s not yet on my radar. That is what I would find valuable. I suspect that the vast majority of attendees to ETech are people already, if not intimately, familiar with most of the topics and technologies being discussed the conference. There will be a lot of familiar faces there, which is nice. I wish none of them were speaking though. I wish all of the speakers had never spoken before at ETech or any other O’Reilly conference. In fact if I had my way, I’d say the deal with speaking at ETech is that you can’t have spoken there before, at least on the same subject, but even then, probably not. I wish ETech were more like DEMO — not similar in the way it does its frantic six-minute pitch sessions from seventy-odd unknown startup companies. But in the fact that most of the speakers are unknowns, presenting new things, different things, (often remixed things).

I went to OSCON in 2000 in Monterey. And I realize that no one besides the rock stars can break into this group.

It’s too bad that an open-source conference is so focused on the stars, and not the implementers, hackers, and module builders who took the core ideas and made them jump.