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.

Tags: Cacheability, Cachefly, caching, CDN, content delivery network, data, David Cancel, geographically-specific server, information, Lookery, low-cost, Mark Nottingham, performance, startup, the Origin, Web Performance, Web performance measurement

I’m the first to tell you that I know nothing about using a tool as powerful as The Gimp. I get Layers, but after that, there is a realm of madness that I have not yet reached.

I have learned a cool trick tonight. It’s building on a trick I learned a couple of weeks ago. It uses layers and the overlay method. Lifehacker pointed me to digital Photography School, and I learned the overlay Gaussian Blur method. I know use this a lot.

But once I figured out layers, I figured that I could really start stacking them up. As a result of my fiddling, I stumbled onto a really cool way to make those pictures leap at you.

Let’s start with a picture of the USB hub that sits next to me.

Sort of lame, with a distinct yellow hue.

Ok, create a duplicate layer. Then, INVERT the duplicate layer. You end up with something like this.

This, in and of itself, is pretty damn cool. But, there’s another layer under there. The original picture. So, what happens when you set the inverted layer to overlay mode?

Now, you may think there isn’t much difference between this and the original. So let’s put them side-by-side.

Pow! Instant Contrast! Things like the cable in the background, the cable in the foreground, and the front edge of the hub suddenly leap out at you.

Now, the true photogs out there are likely yawning. “Yeah, so what?”, they say. “I could of done that in 30 seconds.”

But hey, it’s new to me.

Tags: app, ARIN, blog, content, cool, HTTP, IE, IM, IP, ISP, it, LAN, Om, One, PHP, pr, Technorati, the Origin

I try and avoid the “me-too” factor that has dominated the land of blogs for most of the time I have been involved in it. Simply aping one persons comments with a slight variation, or personal interpretation doesn’t add much to the initial thrill of finding the original germ of an idea.

Kathy Sierra, someone who has been quoted and analyzed multiple times in this blog, has hit another double to the wall. She talks about the value of serendipity, randomness, in exposing us to new ideas and concepts, ones that we would not have run across in our siloed, standardized lives.

Yesterday was a great example of this for me. Something I read a post on Notebookism that spoke of outsider art or Art Brut. I looked it up on Wikipedia, and spiralled into a 90-minute voyage of discovery into this genre of expression, fueled not by training and ideology, but by a raw, unchecked need to express the world in an artistic way.

I would have never gone down this path unless I had read the Notebookism post, and would have been hard-pressed to find structured explanations (whatever you may think of them) of the topics without Wikipedia.

As I explore myself, and examine the foundations that support my cracked mental structure, I find that I appreciate the random explorations far more than a formal education process. I don’t learn the way that we have been taught.

I prefer to discover.

And when you get right down to the basics of Kathy’s post, that’s what she is saying. People are far more enthusiastic, receptive, and amazed when they discover something for themselves.

It may be an old idea to you. I may not interest you. But when a person gets that gleam in their eye, that rush in their mind, when they get the “WOW!“, then they are committed.

Personally, I am finding that I am having a lot more WOW! moments lately. The combination of therapy, and my medications, has forced me to look at the world that I live in, and the world that I have created, substantially different than I have for the last 15 years.

I am re-discovering the joy and awe of discovery. There is so much out there that gets left behind when your mind is absorbed, consumed, by a single devouring purpose. I am awakening from that period, and finding that my mental indigestion requires the soothing relief of the new and unexpected.

Tags: API, app, blog, book, content, cro, EAD, education, HTML, HTTP, IE, IM, IP, ISP, it, LAN, live, Om, One, personal, pr, run, Technorati, the Origin, variation

I am starting to play with a variety of effects to manipulate some of the photographs I am taking with my new camera. I have created four modified versions of the original below. The modified pictures can be found here.

I would love to get comments from folks, either here, or on flickr, telling me which one they like best.

Tags: content, HTTP, IE, IM, IP, ISP, it, LAN, Om, One, Technorati, the Origin

I have set up a test to check the performance of the CoralCDN network against that of the origin server. You can view the comparative results here.

The tests used the base HTML document of this blog as the target.

The results so far indicate that there is a slight performance penalty when using CoralCDN in an ad hoc manner. They do offer continuous CDN services, and these likely provide better overall service under normal conditions.

However, it is likely that in situations where server load or traffic volumes increase substantially, the distributed performance system, even in an ad hoc manner, would save your bacon.

I will watch these tests over the next few days to see if any unique performance patterns appear.

Tags: app, blog, CDN, GrabPERF, GrabPERF.org, HTML, HTTP, IE, it, LAN, normal, Om, origin server, performance, PHP, pr, server, the Origin, The origin server, traffic

Looks like Yahoo TV upgraded overnight.

Guess I will get my TV schedule information from other sources now.

DHTML/AJAX Schedule is slow and confusing.

Front page looks like a Flash designer got lucky — Look at all the dancing images!

Complex, complicated, and visually disturbing.

Oh, and no option to downgrade to the original, functional version.

All I want is the TV listings.

How hard is that?

Tags: ajax, design, HTML, HTTP, IM, information, LAN, Om, the Origin, tv

This paper is an extension of the work done for another article that highlighted the performance benefits of retrieving uncompressed and compressed objects directly from the origin server. I wanted to add a proxy server into the stream and determine if proxy servers helped improve the performance of object downloads, and by how much.

Using the same series of objects in the original compression article[1], the CURL tests were re-run 3 times:

1. Directly from the origin server
2. Through the proxy server, to load the files into cache
3. Through the proxy server, to avoid retrieving files from the origin.[2]

This series of three tests was repeated twice: once for the uncompressed files, and then for the compressed objects.[3]

As can be seen clearly in the plots below, compression caused web page download times to improve greatly, when the objects were retrieved from the source. However, the performance difference between compressed and uncompressed data all but disappears when retrieving objects from a proxy server on a corporate LAN.

Instead of the linear growth between object size and download time seen in both of the retrieval tests that used the origin server (Source and Proxy Load data), the Proxy Draw data clearly shows the benefits that accrue when a proxy server is added to a network to assist with serving HTTP traffic.

The data above shows just how much of an improvement is gained by adding a local proxy server, explicit caching descriptions and compression can add to a Web site. For sites that do force a great of requests to be returned directly to the origin server, compression will be of great help in reducing bandwidth costs and improving performance. However, by allowing pages to be cached in local proxy servers, the difference between compressed and uncompressed pages vanishes.

Conclusion

Compression is a very good start when attempting to optimize performance. The addition of explicit caching messages in server responses which allow proxy servers to serve cached data to clients on remote local LANs can improve performance to even a greater extent than compression can. These two should be used together to improve the overall performance of Web sites.

[1]The test set was made up of the 1952 HTML files located in the top directory of the Linux Documentation Project HTML archive.

[2]All of the pages in these tests announced the following server response header indicating its cacheability:

Cache-Control: max-age=3600

[3]A note on the compressed files: all compression was performed dynamically by mod_gzip for Apache/1.3.27.

Tags: ads, apache, app, ARIN, bandwidth, cache-control, Cacheability, caching, client, compress, compression, control, corporate, data, EAD, extension, gzip, HTML, HTTP, IE, IM, improvement, IP, it, LAN, Linux, mod_gzip, Om, One, optimize, origin server, Pages, performance, performance improvement, pr, proxy, proxy server, run, server, the Origin, The origin server, traffic, web, wordpress

For history fiends, enthusiasts of lost treasures, and lovers of a good mystery, the discovery of the Archimedes Palimpsest has been one of those stories that must be followed.

The texts contained in the Palimpsest were lost to humanity for hundreds of years as a result of a common Medieval European tradition — the re-use of parchment. To quote the site:

“The word Palimpsest comes from the Greek Palimpsestos, meaning “scraped again”. Medieval manuscripts were made of parchment, especially prepared and scraped animal skin. Unlike paper, parchment is sufficiently durable that you can take a knife to it, and scrape off the text, and over write it with a new text. In this case, [the text of Archimedes'] five books were taken apart, the text was scraped off the leaves, which were then stacked in a pile, ready for reuse.”

Using a new x-ray scanning technology, the original Greek text is exposed to the Western world for the first time since 1229.

This holds more than a passing interest to me, as one of the most influential history courses I took during my undergrad tenure was taught by a paleographer and historian at the University of Victoria, Michèle Mulchahey (she is now part of the faculty at the University of St., Andrews in my ancestral homeland, Scotland). I still often wish I had continued my Medieval European history studies, but my lack of latin prevented me from go much further than I did.

Glad to see a truly old classic resurrected.

Technorati Tags: Archimedes, Palimpsest, paleography, Michèle Mulchahey

Tags: ARIN, book, EAD, Europe, HTML, HTTP, IE, IM, IP, it, LAN, leave, Om, One, pr, Technorati, the Origin

At our garage sale today, I sold off the original GrabPERF Web server. Sad to see it go, but it was time.

I am still trying to sell the database server. But I might turn it into a file server with a couple of massive drives.

Technorati Tags: GrabPERF

Tags: data, database, GrabPERF, HTTP, IM, it, Om, server, Technorati, the Origin, web, Web server

As everyone should know by now, GrabPERF has moved to some pretty swell co-lo digs provided by our friends at Technorati. This saved us a bunch of money, both in connectivity and in power.

Now, after nearly 6 months of inactivity, I have decided to sell the original GrabPERF servers. I have no more need for them, and if I was ever to do something like GrabPERF again, I would do it on much more modern hardware.

These two twin PIII 600MHz machines have done stellar work, given that they are at least seven (that’s right, 7) years old. They are rock solid running Linux; your mileage may vary running other OSes.

These are defintely NOT desktop machines. People at the local Air Base asked me to keep the noise down. They have less than stellar video cards and no sound cards. These are servers.

These workhorses can be seen in an annotated context here. Until you go there, here is the old GrabPERF rack, just for the memories.

Technorati Tags: for sale, GrabPERF, servers

Tags: ARIN, connectivity, desktop, GrabPERF, HTTP, IE, IM, it, Linux, Mac, Om, One, pr, run, server, Technorati, the Origin, video