This year, Performance Planet did an advent calendar again, just like last year. I was also invited to write an article, and gladly accepted the invitation. I wrote about WPO Analytics, which is what my master thesis is about. It’s quite strange to see your name appear among the big names of Yahoo, Facebook and Google, but at the same time it’s reassuring that my efforts have not been in vain.
The following article is a 1:1 copy of my “WPO Analytics” article for the 2010 Performance Calendar.

Introduction

Web performance monitoring services such as Gomez, Keynote, Webmetrics, Pingdom, Webpagetest (which was also featured in last year’s web performance advent calendar) and recent newcomers such as Yottaa are all examples of synthetic performance monitoring (SPM) tools.

QCachingLocale speeds up Qt’s slow QSystemLocale::query() calls by caching the answers. This seems to be particularly necessary on Mac OS X 10.6.

The other day I was working on my master thesis, on the parser that is going to parse Episodes log files. I had finished a rough version that parses all fields on an Episodes log line. Unfortunately, performance turned out to be extremely poor: 4.8 seconds for parsing 1000 lines.

After a bit of research, it became clear that it was the call to QDateTime::fromString() that was the cause of the performance issues. Unable to figure it out on my own — I tried for an hour or so, I hopped onto the #qt IRC channel and I posted a simple test case that could reproduce the problem:

After almost a year since the last master thesis blog post, it’s about time to finally break the silence.

Much has happened since then.

I’ve read a lot for my literature study. It’s quite an adaptation (and a challenge!) to read virtually solely about data mining and statistics. Many of the papers were poorly written (in the typical, extremely awful, overly verbose Academic English). It’s an even larger challenge to actually write about it, in a consistent manner that’s sufficiently formal, yet also understandable.
This is also the reason I haven’t blogged about the progress of my literature study: it is so technical, abstract and complex that it is extremely unlikely that it would have piqued anyone’s interest (although it actually is very cool, sometimes). To be honest, the only thing that kept me going was the anticipation of being able to build something truly useful, possibly game-changing.

Fortunately, on June 24, 2010, 15:00 I successfully defended the literature study of my master thesis, resulting in a score of 16/20!

In this final article in my bachelor thesis series, I explain how I proved that the work I had done for my bachelor thesis (which includes the Episodes module, the Episodes Server module, the CDN integration module and File Conveyor) actually had a positive impact on page loading performance. For that, I converted a fairly high-traffic web site to Drupal, installed File Conveyor to optimize & sync files to both a static file server and an FTP Push CDN, used the CDN integration module to serve files from either the static file server or the FTP Push CDN (the decision to pick either of those two is based on the visitor’s location, i.e. the IP address), measure the results using Episodes and prove the positive impact using Episodes Server’s charts.

Previously in this series:

In this article, I explain the rationale behind the CDN integration module for Drupal 6, which was written as part of my bachelor thesis. It supports integration with both Origin Pull CDNs (out-of-the-box) and Push CDNs (by using File Conveyor).
Note that development of version 2 of this module has already begun! Version two will also be ported to Drupal 7.

Previously in this series:

In this article, which was in fact written in January—February 2008 (well over two years ago), I explain what the benefit is of using a CDN and how the then-new CDN integration module 1.x for Drupal 5 could help you do that for a cheap FTP Push CDN.
This was in fact more of a proof of concept module and therefore this Drupal 5 version of the CDN integration module is no longer supported. This article has been published because it would otherwise only been gathering dust. It will give you a better view on Drupal’s history for supporting CDNs, i.e. how hacky this solution is in comparison with its follower, the CDN integration module for Drupal 6.

In this extensive article, I explain the architecture of the “File Conveyor” daemon that I wrote to detect files immediately (through the file system event monitors on each OS, i.e. inotify on Linux), process them (e.g. recompress images, compress CSS/JS files, transcode videos …) and finally, sync them (FTP, Amazon S3, Amazon CloudFront and Rackspace CloudFiles are supported).

Previously in this series:

• Page loading profiling tools
• Improving Drupal: Episodes integration
• Key Properties of a CDN

So now that we have the tools to accurately (or at least representatively) measure the effects of using a CDN, we still have to start using a CDN. Next, we will examine how a web site can take advantage of a CDN.

This weekend on Sunday, February 7, we’ll have a full day of Drupal talks at the 10th edition of FOSDEM, Europe’s biggest, free-est and open-est software conference.

FOSDEM, is a free and non-commercial event organized by the community, for the community. Its goal is to provide Free and Open Source developers a place to meet. The Drupal project was granted a developer room at FOSDEM to do exactly that: to share knowledge about Drupal.

The presentations schedule for the Drupal devroom features interesting speakers such as Robert Douglass, Károly Négyesi, Roel de Meester and Kristof van Tomme and even more interesting subjects as mobile device design, AHAH, eID and Views 3. Everyone is invited to attend the presentations.

This is the brief version of my actual master thesis proposal, which is attached in PDF format.

Introduction {#introduction}

My bachelor thesis was about making Drupal web sites load faster. 80 to 90% of the response time (as observed by the end user) is spent on downloading the components of a web page. Therefor this is also the part where optimizations have the largest effect.

To be able to prove the positive impact of optimizing the loading of the components of a web site — thereby proving that the work I was going to have done had a positive impact — I researched existing page loading profiling tools. Episodes (which refers to the various episodes in the page loading sequence) came out as a clear winner.

Also as part of my bachelor thesis, I wrote a simple Drupal module¹ that could create simple charts to compare the average page loading time per day per geographic region.

Last night, I upgraded to Mac OS X Snow Leopard, so I could start using OpenCL (for a school project). After about an hour, it was ready, and all my settings were still intact. Awesome!
I immediately executed a small OpenCL benchmark application I had found on the internet and voila, it worked!

I continued, attempting to build PyOpenCL. That’s a major pain, because I can’t get Boost to build correctly. But that’s another story.

While attempting to build PyOpenCL, I decided to run the other OpenCL demos I had found. And … all of them would oddly result in crashes. Inexplicably, even the initial OpenCL benchmark application I ran, now refused to run. Even worse, the open command now seemed to fail.
What was going on?

After asking around in #macosx a bit, the very helpful user KonaB1end offered some insightful guidance. Creating another account, testing it there, it all worked. So it was my account. Then I figured I could as well try starting a new terminal with an empty ~/.bash_profile file. And that fixed it all!
So clearly, there was something in my ~/.bash_profile that was causing this. But what?