I created a light-weight HTML page, a “hello world” php app (no db or sessions) and a light weight “hello world” django app using mostly default values (sessions are enabled). I then ran the apache benchmark (ab) on the three using a small VPS w/ 512 MB of RAM from localhost (so no latency is involved giving ideal conditions).

Apache is configured with a max clients of 40 so I tested with a concurrency of 40.

• Static HTML:
  Requests per second:    3249.36 [#/sec] (mean)
  (no measurable impact on server load)
• PHP:
  Requests per second:    2786.73 [#/sec] (mean)
  (no measurable impact on server load)
• Django:
  Requests per second:    157.97 [#/sec] (mean)
  (no measurable impact on server load)
• Static HTML using SSL:
  Requests per second:    10.30 [#/sec] (mean)
  (during this, server load rose uncomfortably high)

What do we understand from this? First, considering the added functionality of the Django framework, I’m quite comfortable with the performance here. If I need as lean of an app as possible, I may want to consider not using a framework. Carefully crafted PHP is probably going to be faster.

However, with a concurrency of 40 the Django app was able to support 157 connections per second. The server load and memory utilization indicates that this VPS can probably handle a higher value for max-clients.

I’m quite shocked at the poor SSL performance. I have no idea why the VPS would perform so poorly. I wonder if the VPS technology forces the server to offload SSL decryption to a virtual network adapter. The CPU of the VPS is an Intel Core 2 Quad @ 2.4GHz.

This is an OpenVZ VPS running Ubuntu 10.04 LTS, Apache 2.2.14, PHP 5.3.2, Django 1.2.3 on Python 2.6.5 using mod_wsgi 2.8.

You can get a good deal on a VPS at burst.net for $5.99/mo (this link uses my “refer a friend” feature so I get credit). I’m extremely happy with the quality of their service and have had 0 downtime in the few months I’ve been a customer.

RewriteEngine On

RewriteCond %{REQUEST_URI} ^/$

RewriteCond %{HTTP_ACCEPT} !"text/vnd.wap.wml|application/vnd.wap.xhtml+xml" [NC]

RewriteCond %{HTTP_USER_AGENT} !"acs|alav|alca|amoi|audi|aste|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-" [NC]

RewriteCond %{HTTP_USER_AGENT} !"dang|doco|erics|hipt|inno|ipaq|java|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-" [NC]

RewriteCond %{HTTP_USER_AGENT} !"maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|opwv" [NC]

RewriteCond %{HTTP_USER_AGENT} !"palm|pana|pant|pdxg|phil|play|pluc|port|prox|qtek|qwap|sage|sams|sany" [NC]

RewriteCond %{HTTP_USER_AGENT} !"sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo" [NC]

RewriteCond %{HTTP_USER_AGENT} !"teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|w3cs|wap-|wapa|wapi" [NC]

RewriteCond %{HTTP_USER_AGENT} !"wapp|wapr|webc|winw|winw|xda|xda-" [NC]

RewriteCond %{HTTP_USER_AGENT} !"up.browser|up.link|windowssce|iemobile|mini|mmp" [NC]

RewriteCond %{HTTP_USER_AGENT} !"symbian|midp|wap|phone|pocket|mobile|pda|psp" [NC]

RewriteCond %{HTTP_USER_AGENT} macintosh [NC]

RewriteRule ^(.*)$ http://www.yoursite.com/ [L,R=302]

Three things to note about this compared to the original:

1. My use case is two sites, www.yoursite.com for normal and m.yoursite.com for mobile sites
2. I only check URLs on the homepage, I figure here that if they’re on an interior page they’re there on purpose
3. You understand mod_rewrite and regular expressions enough to know what to change above to make it right for you (only the 2nd and last lines will likely need to change)

Now you have no excuse not to try out the latest Drupal 7 beta. It’s not hard but you will need to do just a bit of setup. It works like this:

1. Create a free account
2. Make sure you’re able to use SSH (try installing PuTTY if you use Windows, Linux and Mac OS users are already set)
3. Launch an instance
4. Use my instructions to setup Drupal 7 (takes 3 min)
5. Play with Drupal 7 for the remainder of the hour for free

You can repeat steps 3 – 5 if you’d like, but the nature of the system means your data is wiped clean when your hour is up. Fortunately my instructions are copy and paste so you can do it very quickly.

Create an account

Visit https://10.cloud.ubuntu.com to begin the process. Click the big orange button to try Ubuntu 10.10.

You’ll be asked to either sign in (the form on the left) or create an account (the grey button on the right). I assume you have not visited here before and need to make an account.

Next, fill out the form with your e-mail address. Choose a password and enter the captcha

You’ll be sent an e-mail with a short code to enter. Copy that and paste it into the form here to confirm your e-mail address.

Your account was created, now sign in by clicking the big orange button:

By the way, if you have a launchpad.net account you probably skipped some of those steps above. As a matter of fact, if you have an SSH public key associated with your launchpad.net account life will be even easier.

Now we launch the Ubuntu 10.10 Server instance. I’ll assume you don’t have an SSH key filed in launchpad. You’ll get a one-time use password when you launch your instance. You’ll also see an informative paragraph above the gray box which no doubt you won’t read. It’s OK.

Launch your server

Check the 2nd box saying that you will agree to the Amazon Web Service Customer Agreement and the Ubuntu Code of Conduct (basically, if you use this for Drupal 7 testing you’re in compliance). Then hit the orange Launch button.

It takes a min or two for your server to launch. Keep the page open, it refreshes every few seconds. Once the server launches you’ll be given a simple information screen like this:

If you are using Windows you’ll probably want to use the excellent SSH program PuTTY, if you are in Mac OS or Linux you can just open a terminal. The command to type at the terminal is:

ssh ubuntu@address (basically just copy and paste from the webpage)

If you’re in putty just enter the IP address and click connect. When asked for a username type ubuntu.

The first thing that happens is you’ll enter your one-time password. It will immediately request you change it. Follow the instructions to type the one-time password again and then enter a new password of your choosing. It may log you out, if so, just connect again and use your new password this time.

Now test Drupal 7 Beta

You’ve probably now invested about 6 min of your life and you’re ready to see D7. Let’s go.

Type these commands from the terminal:

sudo tasksel install lamp-server

This will prompt you to install a web-server and MySQL onto the server. The screen turns blue and you’ll be asked to choose a MySQL server password. GO AHEAD AND PICK A PASSWORD. It can be 123456 if you want, it will only be around for 1 hour. If you don’t it slows things down a little.

1. sudo apt-get install -y php5-gd
2. wget http://ftp.drupal.org/files/projects/drupal-7.0-beta1.tar.gz
3. cd /srv
4. sudo tar zxf ~/drupal-7.0-beta1.tar.gz
5. sudo sed -i ‘s/\/var\/www/\/srv\/drupal-7.0-beta1/g’ /etc/apache2/sites-available/default
6. sudo /etc/init.d/apache2 restart
7. sudo mysqladmin -u root -p create drupal
   (you’ll have to enter your MySQL password you chose earlier)
8. cd /srv/drupal-7.0-beta1/sites/default
9. sudo cp default.settings.php settings.php
10. sudo mkdir files
11. sudo chown www-data settings.php files/

You are now down. Drupal 7 beta is installed and ready to configure. You can do the rest of these steps in the web browser.

Remember your server address you have open in your browser? (it’s a series of 4 numbers separated by dots) Copy that, open a web browser and then paste that address in as the URL and hit enter.

At this point, you are now officially a Drupal 7 Beta tester!

Follow the instructions to configure Drupal. At the database screen the important details are:

1. Database name: drupal
2. User name: root
3. Password: (the password you typed into the blue screen during configuration)

Explore, play, look for problems, read this page to find out how to test and report issues you find.

Don’t forget to say thank you to Canonical. If you like how easy it is to set up Ubuntu Server strongly consider Ubuntu Advantage, a tool created by Canonical to make setting up and managing Ubuntu Server much easier.

When I started at Canonical there was under 50 employees and the webmaster job description was quite broad. Over time as the company has grown and more people came on to help in various aspects my role became more of a marketing job, making content changes and running web reports. I was spending less of my time doing tasks where I excelled.

It’s kind of a lateral move. I’ll be switching to the team of developers responsible for managing our internal apps. I’ll continue to work on the Ubuntu.com infrastructure including Drupal, WordPress and Moin Moin as before. However this job is explicitly about developing custom application solutions. Someone else will be hired to take on the roles of managing the content and reporting for the website.

For those of you who are my colleagues in the Ubuntu community (i.e. not Canonical staff) our relationship will not change – I’m still the contact. As a matter of fact, there is a lot about my job that isn’t changing. I mostly get to focus on the parts I love.

This suits my tastes perfectly. I’m much more comfortable thinking about HTTP headers, reducing code duplication, CSS and the likes than I am hunting for typos, ensuring headlines are sentence case and keeping on top of web reports.

There will be a job post to fill the role of webmaster. If you’re interested in it, let me know and I’ll send you the details when they’re finalized by management. If you know me you know how to contact me privately and I think that would be the best method to express interest in the job.

There are many aspects related to a release. I can only talk about my own perspective, as it pertains to managing the website. Usually, a week or so before release we’ve got a pretty good idea of what the website will look like and people are viewing it on a testing server. Invariably there are last minute changes, and I do mean up to the last minute.

Wednesday evening the release manager starts the process of dispersing CD images to the corners of the globe so that when its time to go live they show up on the mirrors pretty quickly. I talk to him and plan a time for me to come online to prepare the website for release. This time we agreed I’d be online at 5:00 am (10:00 UTC), aiming for a 12:00 UTC release time.

There’s an element of risk in pre-seeding the CD images because the image testing happens in parallel. Normally its not a problem but this release a serious bug was found. I’m not sure of the details but it was bad enough that there was a “day-of” re-spin. When I came online at 5:00 the disks were being remastered.

This went OK apparently but a new problem popped up. We have a mirror prober application that checks our mirrors to see if they have the correct images. We do this by making HTTP HEAD requests to ensure the file name exists and the file size matches what we have. Unfortunately, the remastered disk images were exactly the same size as the defective ones. Exact to the byte.

We couldn’t tell which mirrors had the new version and which had the bad version. We use a protocol to communicate with our mirrors telling them which files to mirror. Therefore we updated the list to include a dummy file. That allowed us to identify which mirrors were up to date and which were not.

Finally, about 12:21 my time (17:21 UTC) we got the word that it was about time to “push the button.” I had prepared by opening up a bunch of tabs with the pages that were changing, updating the pages so that all I had to do was submit each form. The release team gave me some last minute changes and in the process of applying those I accidentally closed my browser window. If you were in central Iowa you may have heard me scream.

I’m an optimist, so I hoped that firefox would remember the tabs and values of the forms, but unfortunately our authentication system redirects you to an openid auth page when you first visit it. All was lost.

So I copy and pasted again while people constantly instant messaged me asking if it was ready yet. Finally, at about 12:46 (17:46 UTC) the website launched. I kid you not, multitudes of people open their browser to the homepage and refresh again and again waiting to see the site change. I hear someone in the Millbank office with a bottle of champagne waits until the website updates so that they can celebrate. Talk about pressure.

We’re fortunate that our intense loads are so predictable. It gives us plenty of time to beef up our infrastructure and plan appropriately. When we get slashdotted we usually don’t even notice (unless they link to our wiki). A release day is at least 12 times more traffic than when we hit the homepage of digg and slashdot. For a reference, check out this image. The big bump is a release day, the small bump to the left of it is when we hit some big news site.

After the site launches I get a rush of bug reports. There’s nothing like having a million people proof reading your site all at once. The next couple hours are spent doing low-priority updates and fixing little issues that show up. About 3:00 my time (20:00 UTC) I stepped away from my computer and took a nap.

And that is a release day.

When you purchase a certificate you must perform some additional steps besides those to create a self-signed certificate. These steps help you demonstrate who you are. For example, it may require that you prove you can receive email at the domain you’re security, prove that you own the domain, talk to a person or use an automated system that calls you to verify your phone number and identity or even fax business verification documents.

Once you’ve performed the steps necessary to show that you are who you say you are you receive an SSL certificate. Of course you also have to pay money.

I’m not really in agreement that the fees associated with an SSL certificate are justified. The cost of verifying an organization that is purchasing a certificate are pretty much static and don’t vary depending on the number of servers they have. Yet you buy the certificates by the server. If it costs $50 to verify an organization and that’s how much they charge for one certificate and a businesses purchases 10 then you’ve got yourself a pretty good margin. If you don’t believe me, ask Mark Shuttleworth. I shouldn’t complain because his success at selling SSL certificates pays my salary.

Back in the late 90′s the web was young and everyone saw potential but everyone was frustrated because it was hard to do the stuff we really wanted to do. Then Microsoft revolutionized things with the release of Internet Explorer 4 (IE4). It shipped a little before Windows 98 and when added to later releases of Windows 95 it changed the desktop in many good ways. You were foolish not to install it just because of what it brought to the desktop.

But what it brought to the web was even greater. We were doing things we’d only dreamed of before. At first we built our sites with IE4 and Netscape 4 in mind (it was a big improvement over the 3.0 browsers before it) but it quickly became clear that these browsers were in two different leagues and IE was going to be the champ.

Many many organizations and websites dropped support for non IE browsers. It became hard to navigate the web w/out IE. It helped Microsoft resoundingly take over the desktop because you commonly needed IE to view critical websites.

This was the third biggest mistake we’ve made with the Internet and we’re still paying for it. Really. There are extensions for all browsers that let them trick websites into thinking they’re IE so that they can get past the dreaded, “you must be using IE to view this site” error. Sometimes it works but sometimes the only option is to just fire up IE.

And we’re doing it again. The next big thing, the thing that will change the web for ever, is the emergence of Mobile. A few years ago, for the first time, Laptops outsold desktop PCs in retail. It was a big deal because people’s primary computer was not a desktop but a laptop. And soon it will be an even smaller device like a mobile smart phone. I’m confident that soon web enabled mobiles (real web, not WAP) will outsell PCs.

Apple was the vendor to get people really excited about the mobile web, and rightly so. The iPhone is inspiring. Apple started out telling people to design mobile websites but then did a full turn. They opened up an API for native software development and encouraged people to use it rather than web apps. And the encouragement was easy money – build apps, sell them and make a ton of money. We liked the idea. We took the bait, hook, line and sinker. We even swallowed the bobber and asked the fisherman to give more.

How short-sighted though. The Mobile web is too big to be owned by one vendor. We’re repeating the IE 4 mistake all over and instead of groaning in despair we’re grinning and gleeful, asking for more vendor lock in.

We have to stop. Run away from native apps, back to the safety of standards compliance. Back to the world where everyone, regardless of the platform, can access and use your app. Don’t wait!

body {
font-family: sans-serif;
line-height: 130%;
font-size: 91%;
}

First, this helps improve readability by switching to a sans-serif font. Even the highest resolution screens (iPhone and similar) max out at 160dpi. More commonly screens are 96 to 120dpi. This is far less than a printer which is more like 600dpi on the low end. Therefore the curly tips to serif fonts do not get well defined and are essentially blurred (interpolated) by the screen to make them look smooth. This completely negates the benefits serifs enjoy in the print world.

Secondly, it increases the line-height, effectively putting a bit more space between the lines of text. This makes it easier for people to read your content because they can more quickly refocus their eye on the next line of text as they move their eyes from the far right side of the column back to the left.

Lastly, it drops the font-size by 1pt from the browser default which allows more condensed type. Since sans-serif fonts are much easier to read on-screen this does not undo any of the improvements on screen. 11pt sans-serif is easier to read than 12pt serif.

Some people don’t think this matters. If you are one of these types of people let me assure you that you that it does matter to many of your site’s visitors, even though many would have a hard time quantifying or describing why the styles above improve things.

We’ll use the site of my friend and colleague Barry Warsaw as an example. I’ve adjusted his site’s styles using firebug and the two images below demonstrate the change:

Note that the newly styled page actually fits more content in before you have to scroll. Also note the links in the navigation at the top of the page, how the under-lined links have more space between the underline and the text below it.

So very little work is done on your part, your site’s general appearance hasn’t changed dramatically (though some people will notice it) and your site has gotten easier to read.

Please don’t omit the line-height, it is essential to the end result.