Thanks to the generosity of Henrik Sjostrand of Netvouz, there is now a measurement location up and running in Gothenburg Sweden.

You will find it listed in the data as Gothenburg Sweden #1.

I have had a few other parties expressing an interest in hosting a measurement agent, but there is always room for more measurement locations! Send me an email if you can host a site!

Tags: Netvouz, GrabPERF, measurement locations

Tags: data, GrabPERF, GrabPERF.org, HTTP, IE, it, measurement, Om, PHP, pr, run, Sweden, Technorati, tv

This morning, after months of increasing performance issues, and connectivity issues, I have retired the Boston Verizon measurement location. This location hosted 2 measurement agents.

The machines, hosted in my basement, are connected using Verizon FiOS, which has become increasingly flaky over the last couple of months. As well, the machines are 7 year old Pentium IIs, and require a substantial amount of spoon-feeding that I don’t have time for at the moment.

I have re-enabled the Technorati #1 Agent to fill the gap, but this leaves only 4 measurement locations running. I again put out my plea for more volunteers to host GrabPERF measurement locations. I have had one volunteer contact me about this (thanks Henrik!), and this location should be up in about 3 weeks.

If you have a spare linux box and a static IP, have I got a project for you!

PS: The contact page is fixed. It was set to auto-refresh and overwrite your e-mails. Ooooops.

Tags: GrabPERF, Agent, Verizon, Web Performance, measurement, performance measurement

Tags: Boston, connectivity, GrabPERF, GrabPERF.org, HTTP, IM, IP, Issues, it, leave, Linux, Mac, measurement, Om, One, performance, performance issues, performance measurement, PHP, pr, run, Technorati, tv, Verizon, web, Web Performance, Web+performance

My side project, GrabPERF, is looking for a few good measurement locations.

Right now, there are only five measurement locations, two of which are in my basement, on my personal Internet connection. I am hoping, through this pledge drive, to find a number of additional locations. Areas desperately needed include:

• East Coast, USA
• West Coast, USA
• Midwest, USA
• UK
• Asia-Pac
• Southeast Asia
• Australia / New Zealand

Yeah, I know. I am asking for the world. Can’t hurt to try though.

Basic requirements are a Linux box with a static IP address. Additional requirements are documented here.

You can express your interest in hosting a measurement site by filling in the GrabPERF Contact Form or contacting me directly.

Thank you for your continuing support.

Tags: GrabPERF, measurement locations, Web performance

Tags: Asia, Australia, contact form, GrabPERF, GrabPERF.org, HTTP, IE, Internet, IP, ip address, it, LAN, Linux, measurement, New Zealand, Om, performance, personal, PHP, pr, Technorati, web, Web Performance, Web+performance

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

It’s always funny when somewhat tech-savvy folks purposely make their bandwidth bills higher than they need to be.

Here’s TechCrunch’s HTTP header response.

---

HTTP/1.1 200 OK
Date: Tue, 16 Jan 2007 16:02:23 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 PHP/5.2.0-8 mod_ssl/2.2.3 OpenSSL/0.9.8c
X-Powered-By: PHP/5.2.0-8
X-Pingback: http://www.techcrunch.com/xmlrpc.php
Status: 200 OK
Transfer-Encoding: chunked
Content-Type: text/html; charset="UTF-8"

---

Port80 Software’s Compression Checker gives us some idea how much bandwidth Mr. Arrington, et al. could save just by activating this little feature, which comes baked into Apache 2.2.x.

Turn. On. Mod_deflate.

Tags: apache, ARIN, bandwidth, compress, compression, content, deflate, EAD, GrabPERF, HTML, HTTP, IE, IM, IP, ISP, it, LAN, Om, performance, PHP, pr, run, server, ssl, techcrunch, Technorati, web, Web Performance

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

I do not want to host my own blog.

Even if I wanted to, Wordpress.com does not make it easy to export content. This, however, is a separate discussion.

Skype and Web 2.0 (I hate the term, but I am using it) are inextricably linked.

Wordpress and Web 2.0 are inextricably linked.

Wordpress.com hates Skype. It’s that simple.

According to a Wordpress.com forum post:

Actually in this case it’s because skype and callme are being stripped. They’re not XML recognized tags and staff has stated that they won’t be supported.

And

Fraid not. Javascripts are still removed from input for security concerns. If you really need Skype, I would suggest getting a paid host.

See here.

Wordpress.com: BUILD A SKYPE WIDGET!

Thank you.

Technorati Tags: Wordpress.com, skype, widgets

Tags: blog, content, HTTP, IM, IP, it, Javascript, Om, PHP, pr, Technorati, web, web 2.0, wordpress

Today, the sun is shining and I am working from home, so things don’t seems as bad.

The last few days have been interesting, as I have become more aware that the my work-related anger and dissatisfaction does not originate with the people at work, or the place I work, or the work itself, but from that beast that so many white-collar professionals suffer from: burnout.

Burnout is not sexy. In the US and Canada, it is seen as a sign of weakness, a lack of the American Work Ethic. NPR had a great discussion of burnout this week, and New York Magazine published a cover article on it this week.

Listening to NPR on Monday, there was a story of how the US armed forces are punishing soldiers who return from Iraq and are diagnosed with PTSD (Post-Traumatic Stress Disorder) [here]. The successful soldiers see the soldiers (what defines success for a soldier?) with PTSD as weaklings, people who should be punished, pushed out onto the streets, stripped of their American citizenship as cowards and traitors.

I do not claim that PTSD and work-related burnout are equal; my focus here is on the stigma that the US culture places on doing the job, regardless of what the job does to you.

You can do the job. Good. What kind of person are you?

I am a rebel. I do not fit the US success criteria. I don’t want a title. I don’t want a box on an org chart. I don’t want to have the biggest bank account. And I have no respect for people who worship at the temple of US success until they show me that they can do something that I respect.

Today. I wrote an email to my manager and VP stating that during my Christmas break this year, I will be completely unreachable for  anything work-related. Unreachable for EVERYTHING work-related. It is likely that I will be seen as “letting the team down”, as it is not only end-of-quarter, but end-of-year.

You know what? I don’t care. I am more important than my job. If the company I work for now doesn’t recognize that, I will find a new company.

You know who the most successful people I know are? My friends who “dropped out” of the corporate world, moved to Maine, and are slaving, day and night, to get their under-funded winery project off the ground. While raising three kids. While renovating and repairing 200-year old farm buildings.

Success does not come from money, power, or a title. I comes from having the respect of the people around you. I comes from a desire to get up in the morning and do something that completes you, fills a void inside you.

Right now, when I get up, I step into a void.

Burnout. It’s here to stay.

Technorati Tags: burnout, bipolar, depression, work ethic, ptsd, npr, success

Tags: bank, Canada, corporate, HTML, HTTP, IE, IM, IP, it, Om, One, PHP, pr, Technorati

Now that I am back on US soil, I have some tips for surviving your trip to London.

1. GSM Phones. If you are one of the millions in the United States who subscribe to a CDMA service (Verizon, Sprint, etc.), invest a few bucks on eBay and buy a low-end, unlocked, tri-band GSM phone. I have used GSM for years, and the unlocked phones give you an amazing advantage — you buy a pay-as-you-go SIM card once you arrive.

   In the UK, incoming phone calls are free. If you have a half-decent office phone system, you should be able to remotely forward your desk phone to your UK number and voila! You have a local number that folks in the US can always reach you at.

2. OYSTER CARD! If you plan to travel anywhere on the London Public Transit system, buy an Oyster card. Same concept as the pay-as-you-go SIM card. And you’re never fussing with change or daily passes for the tube, DLR or busses.
3. Saline Nasal Spray. This seems like a bit in the “too much information” category, but trust me on this one. London’s atmosphere makes New York seem like an untouched Alpine pasture. After one day there, your sinuses will feel and look like the inside of a pool filter after a dust storm. A simple nasal spray takes of this, and often provides a somewhat scary indication of what man does to the urban environment he lives in.

   If you don’t want to pack one with you, you can buy some truly awesome stuff at any Boots — Sterimar. What makes this stuff uniqe is that it is aresol powered. Unlike the wussy atomisers we use over here, this stuff is freakin’ jet-propelled — if it can’t blast the crap out, it’s likely brains.

4. Look to the right. Yeah, we all know that the Brits drive on the other side of the road, but many an American has been nearly killed in the first twelve hours on the ground by using their instincts and not their brains. I am in this group.

   Thankfully, the Brits provide nice warning labels at most crosswalks; look down, and they will tell you which direction to look in to avoid becoming a hood ornament for a Bentley.

5. Change Wallet. Dear lord; you will need one of these or you will blow out every pocket you have. The Brits still use a lot of cash, and like the rest of the world, the lower denominations of their currency are coins, not bills. A solid change wallet is key.
6. Take the red-eye. You will search online and find a multitude of strategies for dealing with jet-lag. I have a simple one — make sure your flight takes you overnight so that you land at Heathrow/Gatwick/Stansted/Dublin/Luton first thing in the morning. For folks on the East Coast or Central Canada, this means flights between 19:00 and 22:00 Eastern. For West Coast folks, it’s a 11-12 hour flight and an eight-hour time change, and Heathrow opens at 07:00, so 11:00-14:00 Pacific is a good range.

These are the top six I can think of rigt now. Comment on your strategies if you have them.

Tags: Canada, cro, GSM, HTTP, IE, IM, information, IP, it, LAN, live, Om, One, online, PHP, pr, search, the other, United States, Verizon

How much improvement can you see with compression? The difference in measured download times on a very lightly loaded server indicates that the time to download the Base Page (the initial HTML file) improved by between 1.3 and 1.6 seconds across a very slow connection when compression was used.

Base Page Performance

There is a slightly slower time for the server to respond to a client requesting a compressed page. Measurements show that the median response time for the server averaged 0.23 seconds for the uncompressed page and 0.27 seconds for the compressed page. However, most Web server administrators should be willing to accept a 0.04 increase in response time to achieve a 1.5 second improvement in file transfer time.

First Byte Performance

Web pages are not completely HTML. How do improved HTML (and CSS) download times affect overall performance? The graph below shows that overall download times for the test page were 1 to 1.5 seconds better when the HTML files were compressed.

Total Page Performance

To further emphasize the value of compression, I ran a test on a Web server to see what the average compression ratio would be when requesting a very large number of files. As well, I wanted to determine what the affect on server response time would be when requesting large numbers of compressed files simultaneously. There were 1952 HTML files in the test directory and I checked the results using CURL across my local LAN.[1]

---

Large sample of File Requests (1952 HTML Files)

mod_gzip

		Uncompressed	Compressed
First Byte
	Mean	0.091	0.084
	Median	0.030	0.036
Total Time
	Mean	0.280	0.128
	Median	0.173	0.079
Bytes per Page
	Mean	6349	2416
	Median	3750	1543
Total Bytes		12392318	4716160

mod_deflate[2]

		Uncompressed	Compressed
First Byte
	Mean	0.044	0.046
	Median	0.028	0.031
Total Time
	Mean	0.241	0.107
	Median	0.169	0.050
Bytes per Page
	Mean	6349	2418
	Median	3750	1544
Total Bytes		12392318	4720735

	mod_gzip	mod_deflate
Average Compression	0.433	0.438
Median Compression	0.427	0.427

---

As expected, the First Byte download time was slightly higher with the compressed files than it was with the uncompressed files. But this difference was in milliseconds, and is hardly worth mentioning in terms of on-the-fly compression. It is unlikely that any user, especially dial-up users, would notice this difference in performance.That the delivered data was transformed to 43% of the original file size should make any Web administrator sit up and notice. The compression ratio for the test files ranged from no compression for files that were less than 300 bytes, to 15% of original file size for two of the Linux SCSI Programming HOWTOs. Compression ratios do not increase in a linear fashion when compared to file size; rather, compression depends heaviliy on the repetition of content within a file to gain its greatest successes. The SCSI Programming HOWTOs have a great deal of repeated characters, making them ideal candidates for extreme compression.Smaller files also did not compress as well as larger files, exactly for this reason. Fewer bytes means a lower probability of repeated bytes, resulting in a lower compression ratio.

---

Average Compression by File Size mod_gzip mod_deflate 0-999 0.713 0.777[3] 1000-4999 0.440 0.440 5000-9999 0.389 0.389 10000-19999 0.369 0.369 20000-49999 0.350 0.350 50000 and up 0.329 0.331

---

The data shows that compression works best on files larger than 5000 bytes; after that size, average compression gains are smaller, unless a file has a large number of repeated characters. Some people argue that compressing files below a certain size is a wasteful use of CPU cycles. If you agree with these folks, using the 5000 byte value as floor value for compressing files should be a good starting point. I am of the opposite mindset: I compress everything that comes off my servers because I consider myself an HTTP overclocker, trying to squeeze every last bit of download performance out of the network.

Conclusion

With a few simple commands, and a little bit of configuration, an Apache Web server can be configured to deliver a large amount of content in a compressed format. These benefits are not simply limited to static pages; dynamic pages generated by PHP and other dynamic content generators can be compressed by using the Apache compression modules. When added other performance tuning mechanisms and appropriate server-side caching rules, these modules can substantially reduce the bandwidth for a very low cost.

---

[1] The files were the top level HTML files from the Linux Documentation Project. They were installed on an Apache 1.3.27 server running mod_gzip and an Apache 2.0.44 server using mod_deflate. Minimum file size was 80 bytes and maximum file size was 99419 bytes.

[2] mod_deflate for Apache/2.0.44 and earlier comes with the compression ratio set for Best Speed, not Best Compression. This configuration can be modified using the tips found here; and starting with Apache/2.0.45, there will be a configuration directive that will allow admins to configure the compression ratio that they want.

In this example, the compression ratio was set to Level 6.

[3] mod_deflate does not have a lower bound for file size, so it attempts to compress files that are too small to benefit from compression. This results in files smaller than approximately 120 bytes becoming larger when processed by mod_deflate.

Tags: apache, caching, compress, compressing, compression, deflate, gzip, HTML, LAN, Linux, loaded server, PHP, SCSI, Web server, Web server administrators