In the GigaOm blog today, Allen Leinwand puts up a monstrous wake-up call to all the hip and cool Web 2.0 companies out there: Your apps run across the Internet [here].

I have spent 9 years investigating, diagnosing, and validating the Web performance issues of companies. I can tear the Web performance data of a site down quickly and ask pointed questions about why certain components of an application are behaving poorly.

But even after 9 years, there are still gimme problems around connection setup that I can seem brilliant about, not because I have some secret knowledge, but because I think of Web performance from the Network UP, not from the Application DOWN.

The subtlety of this difference what Leinwand is alluding to. Fancy applications run across the Internet. The Internet is built on TCP. And TCP is built on-top of a very complex networking infrastructure that is way beyond the realm of my skills.

If you don’t know what packet loss looks like, or how your fancy app presents to clients, or how to ensure that this data is collected and presented to you in a timely way, then you are being exposed to alerting by client calls.

All because you thought the biggest problem was scaling your app, not ensuring that the network it crossed to reach people affected the way it performed. Network geeks created Web 1.0; Web 2.0 seems to think they are mostly unecessary.

Wrong.

Measure your performance. Understand TCP. Hire a network geek (or 20).

Then sleep better at night.

Tags: Allen Leinwand, GigaOm, Internet, networking, performance measurement, TCP, Web 1.0

I was futzing around with my WRT54G(L) last night and did something wrong. I thought I had bricked the damn thing. Much cursing and swearing ensued as I put a BEFSX41 on the front-end of the network (I have three of these; don’t ask why) and wandered upstairs with the lump of black and blue plastic that used to be the hub of my wireless network.

After much fiddling, I thought I had it working, so I plugged it into the network drop I have at my desk…and the damn thing disappeared!

Not physically, but from the network. I couldn’t connect to it via the network ports, and when I did connect wirelessly, I got an IP address from the wired router..????

Then the lightbulb went on. It appears that when you put a WRT54G(L) on a network behind another router (most likely only happens with other Linksys devices) , it immediately becomes an access point ONLY.

This was the way it was supposed to work.

And people wonder why Linksys/Cisco sells so many of these damn things. With automagic behaviour like this, it makes the world of networking so much easier for morons like me.

Technorati Tags: WRT54G, BEFSX41, WRT54GL, Linksys, Home+Networking, Wireless, 802.11g, Firmware

Tags: app, ARIN, HTTP, IE, IM, IP, ip address, it, media, networking, Om, ssl, Technorati

The last 4 weeks have been extremely traumatic for me. It has culminated in an extended period of renewal, reflection and rejuvenation, where I have looked back over the last 15 years of my life and asked, “What next?”.

An interesting note on the word rejuvenation: it means to reclaim your childlike state (ok, I’m playing fast and loose with the definition).

Why now? Why 15 years?

In the Fall of 1991, I bought my first computer. Until then, I had avoided using them like the plague. I had managed to get through my undergraduate years with a pen, paper, and an electronic typewriter with rudimentary spell-checking. I felt that I had achieved something; I felt bonded to the works I created.

I was also an avid and active journal-keeper. In the months after my father died, the writing in my journal was what let me empty my naive mind, letting me vent the chaos that rushed through my head on a constant basis.

Then I went to grad school. And I realized then that I would need to step up in order to generate the massive amount of paper that is required in a graduate history program.

It turns out that I found the technology more enticing than the program. To this day, my failure to complete my Masters degree haunts me. Someday, I will return to that, and complete it. Knot the loose ends of my life together.

Ok, this really is going somewhere; thanks for hanging on this far.

After 15 years of intense immersion in technology, the Web, networking, and all that comes along with that, I have realized that something has been missing from my work, my writing, my life. I have missed the rushing sound of pen on a clean sheet of blank paper. No lines to slow you down; nothing besides the edges of the page to define what you put in the book.

Technology has lost its lustre. The rushing stream of this new laptop, that new technology, another over-inflated boom have left me feeling empty, asking “So what?”. In a hundred years, we can be so far down the path to post-humanism that computers as we know them are a vague and distant antique amusement.

Or we could be living in caves, scratching by a subsistence existence.

In either case, the only thing that will remain, that will linger, that will connect us to the past will be the written word. Not the electronic bits and bytes we are now so addicted to, but the ink on paper, graphite on wood pulp.

The smooth, quiet, seductive transition of ideas from mind to physical reality.

I have been trimming back my blog-reading. Gone are the political blogs. I fear that the gadget blogs are next.

What you have left are those people who celebrate life outside the electronic realm. Those who step back, and look back on the knowledge that preceded us. Who pick up a book that was published before they were born.

A book that left the mind of the author and flowed gracefully from the pen, to the paper, to another mind.

15 years is a long time to try and live without paper. Those 15 years have seen the niceties of a bygone age evaporate, get swallowed by an endless sea, a raging torrent of information.

The cursive hand; the thoughtful response; the flowing of ideas from person to person.

To calm the storm of my mind, I have returned to my first love: ideas of the mind, of the soul. Ideas that were worthy of the preparation of the parchment, the sharpening of the quill, the grinding of the pigment to create the ink.

We have walked away from those ideas, grasping at the brass ring in front of us, to the disdain of the treasure chest we leave behind.

To focus on the ideas, that is to live again.

To heal my mind, I must write my mind. Not type it; not IM it or e-mail it or blog it.

That familiar scratch of pen on paper. The rush that comes from committing something to paper; something that you can share with others.

Something that you can set adrift, watch as it floats, the glow from its candle on the gentle rippled flow of all the ideas that have come before.

I am setting my ideas free again.

Picture: girlzone41

Technorati Tags: ideas, quill, ink, pigment, death, life, resurrection, rebirth, technology, paper, pen, rejuvenation, myths, legends, chaos, healing, mind

Tags: ASP, blog, book, EAD, HTTP, IE, IM, information, IP, it, LAN, leave, live, networking, Om, One, pr, Technorati, Torrent, trim, web

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

Tags: ads, app, application, Asia, browser, business, client, data, design, HTTP, IE, IM, Issues, it, media, networking, Om, performance, persistent, persistent connections, pr, server, startup, TCP, Technorati, web, Web Performance, web-based application

I have been getting Partial File errors out of cURL on the Agent that is running on my home network. These started at around 16:15 EDT October, 28, 2005. This is why the availability for this measurement is running at around 50%.

Now, did the folks at Feedster make a networking/server change around that time?

---

Technorati: feedster

IceRocket: feedster

Tags: blog, feeds, GrabPERF, HTTP, IM, it, measurement, networking, Om, run, server, Technorati

This is the latest and greatest in social networking/blogging/picture trading/auction/online marketplace/p2p/moblogging/brand awareness Web apps… [here]

…FREAKIN’ NOT!

Thanks for finding this Joi!

Tags: app, blog, Blogging, brand, HTML, HTTP, it, networking, Om, online, web, web app

It is interesting working in a post-bubble company, watching the companies on the edge of the newly expanding bubbles of search, Web services, blogging and social networking start to try and find ways to link and grow together.

Ask, after buying Bloglines, gets acquired by IAC. Yahoo acquires Flickr. MSN has Spaces; Microsoft buys a file-sharing company; Microsoft has skunkworks projects at Start.com. Google just announced that they are looking for a UI developer to help revive and restore the flagging Blogger service.

The question that arises in my mind is whether these mergers will allow these large companies to effectively control access to what we can and cannot do online.

Now, I am not trying to be orwellian, I am just pointing out that there is likely to be a large amount of control and centralization in these outlets. In some cases, this will be good, providing us with services and features that were unattainable in the smaller company.

On the Dark Side, the benefits could be subsumed in a flood of meaningless co-linked content for tickets, shopping, and other detritus that has yet to overwhelm the new personalized blogging/peer-to-peer/social-networking universe that has “suddenly” appeared since 2000.

The cry of the Internet in 1995 was that anyone could have a Web page, have access to whatever content they wanted, and be in control of their online experience. Now that has come full-circle, after a detour through the swamp of commercialism and marketeering.

With the acquisition of the “cool” and “innovative” companies by the “old” New Media companies, will these new memes simply get subsumed by commercialism and marketeering?

Tags: Acquisition, app, ARIN, blog, Blogging, content, control, cool, cro, Google, HTML, HTTP, IE, IM, Internet, it, media, Microsoft, networking, Om, One, online, personal, pr, search, web

Jeremey Wright hints at some of the features we might/will see in MSIE 7.0. [here]

Again, composition and design standards are important; but do not forget the networking standards as well. It will take a lot for me to switch back to MSIE, but it would be good to if the Internet doesn’t have to design itself to fit the foibles of a single browser platform again.

Tags: browser, design, HTTP, IE, IM, Internet, it, MSIE, networking, Om

That is not a typo. The great man spoke the words today. [here and MSFT Press Release and here and here and here and here
and here and here]

Will it be better…?

---

The quote:

Building on those advancements, Gates announced Internet Explorer 7.0, designed to add new levels of security to Windows XP SP2 while maintaining the level of extensibility and compatibility that customers have come to expect. Internet Explorer 7.0 will also provide even stronger defenses against phishing, malicious software and spyware. The beta release is scheduled to be available this summer.

But what will those features be?

• Complete CSS2 support? Hell! CSS1?
• Full HTTP/1.1 compatability?
• Final removal of ActiveX?
• Truly enforce [X]HTML standards for publishing?
• Simple extensibility for any developer?
• Themes/Chrome?
• A matching version for MacOSX?

They know they are in trouble. They are generating buzz. But if they have just patched and incremented MSIE 6.0, without re-engineering the core parser, rendering and networking engines, then it won’t be worth talking about.

Come on Microsoft: Impress me.

Tags: ASP, blog, Chrome, cro, css, customers, design, Firefox, hits, HTML, HTTP, IE, IM, Internet, Internet Explorer, internet explorer 7, it, Mac, maintain, Microsoft, MSIE, networking, Om, PHP, pr, web, window, Windows

Service Level Agreements (SLAs) appear to finally be maturing in the realm of Web performance. Both of the Web performance companies that I have worked for have understood their importance, but convincing the market of the importance of these metrics has been a challenge up until recently.

In the bandwidth and networking industries, SLAs have been a key component of contracts for many years. However, as Doug Kaye outlined in his book Strategies for Web Hosting and Managed Services, SLAs can also be useless.

The key to determining a useful Web performance SLA rests on some clear business concepts: relevance and enforceability. Many papers have been written on how to calculate SLAs, but that leaves companies still staggering with the understanding that they need SLAs, but don’t understand them.

Relevance

Relevance is a key SLA metric because an SLA defined by someone else may have no meaning to the types of metrics your business measures itself on. Whether the SLA is based on performance, availability or a weighted virtual metric designed specifically by the parties bound by the agreement, it has to mean something, and be meaningful.

The classic SLA is average performance of X seconds and availability of Y% over period Z. This is not particularly useful to businesses, as they have defines business metrics that they already use.

Take for example a stock trading company. in most cases, they are curious, but not concerned with their Web performance and availability between 17:00 and 08:00 Eastern Time.But when the markets are open, these metrics are critical to the business.

Now, try and take your stock-trading metric and overlay it at Amazon or eBay. Doesn’t fit. So, in a classic consultative fashion, SLAs have to be developed by asking what is useful to the client.

• Who is to be involved in the SLA process?
• How do SLAs for Internal Groups differ from those for External vendors?
• Will this be pure technical measurement? Will business data be factored in?

Asking and answering these questions makes the SLA definition process relevant to the Web performance objectives set by the organization.

Enforceability

The idea that an SLA with no teeth could exist is almost funny. But if you examine the majority of SLAs that are contracted between businesses in the Web performance space today, you will find that they are so vaguely defined and meaningless to the business objectives that actually enforcing the penalty clauses is next to impossible.

As real world experience shows, it is extremely difficult for most companies enforce SLAs. If the relevance objectives discussed above are hammered out so that the targets are clear and precise, then enforcement becomes a snap. The relevance objective often fails, because the SLA is imposed by one party on another; or an SLA is included in a contract as a feature, but when something goes wrong, escape path is clear for the “violating” party.

If an organization would like to try and develop a process to define enforceable SLAs, start with the internal business units. These are easier to develop, as everyone has a shared business objective, and all disputes can be arbitrated by internal executives or team leaders.

Once the internal teams understand and are able to live with the metrics used to measure the SLAs, then this can be extended to vendors. The important part of this extension is that third-party SLA measurement organizations will need to become involved in this process.

Some would say that I am tooting my own horn by advocating the use of these third-party measurement organizations, as I have worked for two of the leaders in this area. The need for a neutral third-party is crucial in this scenario; it would be like watching a soccer match (football for the enlightened among you) without the mediating influence of the referee.

---

If your organization is now considering implementing SLAs, then it is crucial that these agreements are relevant and enforceable. That way, both parties understand and will strive to meet easily measured and agreed upon goals, and understand that there are penalties for not delivering performance excellence.

Tags: app, bandwidth, book, business, client, critical, data, design, Doug Kaye, eBay, eBay Inc, extension, HTTP, IE, IM, ISP, it, leave, live, measurement, media, metrics, networking, performance, pr, SLA, third-party, web, Web Hosting, Web Performance, Web performance objectives, Web performance SLA, Web performance space