As a part of the reworking of the GrabPERF code, I removed the Google ads from all pages. They were an annoyance, and displayed items were incredibly irrelevant for the site.

Tags: ads, Google, GrabPERF, ISP, it, Om, One, Pages

If you use GrabPERF on a regular basis, the somewhat flaky navigation method has become second nature to you. In fact, to circumvent some of the idiosyncrasies, you have probably bookmarked your favourite pages.

Yesterday, I broke your links.

When I redesigned GrabPERF in February 2006, I had just discover the require function in PHP, and decided to build the entire the structure using a single container page as the framework, and individual functions called using URL parameters.

As time went on, my own “brilliance” started to get in the way of maintaining and updating the code. It took me 10-15 minutes to figure out how I constructed pages, and then find the right code to fix or update.

Yesterday, I got completely fed up with this structure.

Now, all functions have their own unique pages, making maintenance a snap. And as an added benefit, I can now effectively track the usage of individual pages, so I know where to through development efforts.

Some of the changes.

http://grabperf.org/homepage.php?page=compare&test=2&tests%5B%5D=276&tests%5B%5D=277&tests%5B%5D=279&tests%5B%5D=280

becomes

http://grabperf.org/compare.php?test=2&tests%5B%5D=276&tests%5B%5D=277&tests%5B%5D=279&tests%5B%5D=280

http://grabperf.org/homepage.php?page=scatter&test=277&hours=2

becomes

http://grabperf.org/scatter.php?test=277&hours=2

I apologize for the confusion that this may cause, but in the long run, this will help me make the code better, and more robust.

Tags: book, content, design, GrabPERF, GrabPERF.org, HTTP, IE, IM, improvement, ISP, it, maintain, maintenance, Om, optimize, Pages, performance, PHP, pr, run, Technorati, update, web, Web Performance

I have set up measurements to monitor the main pages of some of the world’s largest mobile phone providers.

• US Providers
• Canadian Providers
• European Providers
• AsiaPac / South Asia Providers

Just something to do on a rainy Sunday.

Tags: GrabPERF, Web performance, GSM, CDMA, Web site, mobile, wireless, US, Asia, Europe

Tags: Asia, Europe, GrabPERF, GrabPERF.org, GSM, HTTP, it, measurement, metrics, Om, One, Pages, performance, PHP, pr, Technorati, web, Web Performance, Web+performance

I went to the Natural History Museum, and the Victoria and Albert Museum today, which isn’t too shabby considering that I am jet-lagged and trying to get my body on the local schedule after taking the red-eye in.

The Da Vinci exhibit had pages from his notebooks and sketchbooks. Seeing the mind of a genius, the range of interests…the scope of what he accomplished, is astounding.

Go see it. Worth the trip to London.

Tags: book, HTTP, IP, it, LAN, Om, Pages

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

I have been running the GrabPERF Compression and Performance study for less than a week, but I thought that I should share some of the initial results with everyone.

As you can see above, the byte transmission savings gained by some sites is pretty astounding. Google News sends a pages with a median weight of near 31,000 bytes when compressed; but when compression is disabled on the client, this jumps to over 139,000 bytes.

What is interesting is that the performance gains don’t look truly significant. However, they compressed pages are faster, and have the added benefit of costing the site less, as bandwidth costs count by the byte (I know it’s more complicated than that, but for now, let’s assume a fantasy world).

I will continue to monitor that results and will close the measurements after 14 days and write up a final report.

Technorati Tags: GrabPERF, Web+performance, Web+Compression, HTTP+Compression, Performance+tuning, GZIP

Tags: ARIN, bandwidth, client, compress, compression, Google, GrabPERF, gzip, HTTP, IE, IM, IP, it, measurement, media, Om, One, Pages, performance, pr, run, Technorati, web, Web+performance

I sat down and finally read my copy of Never Eat Alone, by Keith Ferrazzi. Well, I agonizingly got my way through 80% of the book before I threw it across the room in disgust.

What a load of crap.

There might be a message in the book somewhere. But the book is mostly about Mr. Ferrazzi’s preening ego and self-importance.

He obviously thinks that all the world’s ills can be solved by reaching out your hand and saying, “Hey, I’m important and you need to know me!”.

Keith, get over yourself and your tale of the American dream. Focus on the facts. I don’t need to listen to a celebrity gossip story every 5 pages. In fact, your approach turned me off.

Obviously, if you took the time to get to know introverts, which I am, you would find that doing something is more important than who you know. We are people who don’t care who you know; we want to know what you have done.

Introverts have very tight, very small networks. But if you REALLY need to get something done, you usually end up working with an introvert.

I can truly say that I lost my money on this book. Maybe if he took the time to explore how the over half of the population works, he would find that his approach is seen as vacuous and disingenuous.

It’s not the number you know; it’s how well you know them.

Spend a month focusing on those people who are truly close to you. Then you will never eat alone.

Technorati Tags: Never+Eat+Alone, Keith+Ferrazzi, ego, superstar, preening, boasting

Tags: app, book, cro, EAD, HTTP, IE, IM, IP, it, LAN, Om, One, Pages, pr, review, Technorati

One of the performance hits that the GrabPERF system has is the dynamic generation of the main page. The nature of the SQL calls and the underlying PHP makes it scale exponentially past a certain number of measurements.

Last night, Kevin Burton made a grand suggestion: generate a static page on a regular schedule.

Duh!

Today, I wrote the script that does this. The performance of the main page has adjusted accordingly.

Yikes!

UPDATE: Ian Holsman reminded that if I use cURL, I can use the exiting PHP to build the pages without a PERL script.

I. AM. AN. IDIOT.

Now, bedtime.

Technorati Tags: GrabPERF, Web+performance, PHP, MySQL, Dynamic+pages, Static+pages, HTML

Tags: ARIN, bbc, blog, GrabPERF, hits, HTML, HTTP, IE, IM, improvement, IP, it, LAN, measurement, mysql, Om, One, Pages, performance, performance improvement, Perl, PHP, pr, Technorati, update, web, Web+performance

I now have a true live example of how text matching can provide information on issues where a successful page is returned.

In this example, the TEST AGENT returned a Text Match Failed error, while 3 of the agents running the current production code said the page was a success.

How do I know that the TEST AGENT is right? Take a look at the byte count. For the successful pages, the byte count is in the 3,600-3,900 byte range; the page that had the Text Match failure only returned 1076 bytes. And three other measurements around that time reported the same approximate size, but reported successful page downloads.

If this Agent code shows continued success and robust behaviour, then I will push it into production on August 14.

Technorati Tags: GrabPERF, Agent+upgrade, Web+performance, text+match, content+match

Tags: ads, app, ARIN, content, current, GrabPERF, HTTP, IE, IM, information, Issues, it, live, measurement, Om, Pages, performance, pr, run, Technorati, web, Web+performance

AJAX is an amazing bit of technology, and a boon to Web performance.

The question is, how do you accurately measure it?

Now, from the perspective of synthetic transaction measurement, AJAX destroys the foundational concept of the “Page”, as it is built on the concept of the “sequence”. “Pages” assume a whole new HTML document is loaded in each step, where a “sequence” simply tracks the specific flow of steps that the customer performs, regardless of whether they occur in a new HTML document or not.

In this respect, passive monitoring services currently have a distinct advantage over synthetic measurement, because they intrinsically track the sequence of event that a customer triggers, rather than the pages that are downloaded. I will not declare the death of synthetic Web performance measurement yet (my day job is with one the largest synthetic Web performance measurement companies); but the industry has to re-evaluate many of its core precepts.

AJAX is a technology that will definitely benefit from the blending of passive and synthetic performance measurement into a single usable stream of information that companies can act on. With this blend, companies can determine how their servers are responding, as well as what customers are doing, tracking the flow of business data in real-time.

What will be interesting to watch is how the synthetic measurement companies (including the one I work for) respond to this. One of the companies in our space says that they handle it now, but I have yet to see the results of their effort and how they really implement it in the field.

How are you and your team measuring the performance of your AJAX applications?

Technorati Tags: AJAX, Web performance, synthetic, passive, measurement

Tags: ajax, HTML, Pages, passive monitoring services, synthetic Web performance measurement, Web Performance