How to host a Municipal Election Website for $2.44

It was municipal election day for Charlottetown, Summerside, Stratford and Cornwall here in Prince Edward Island yesterday, and my primary role in the process was to ensure that there was infrastructure in place to support delivery of election results to the public.

When I first started working with Elections PEI in the mid-1990s, putting results online was an afterthought at best; these days it’s the primary vehicle for distributing results information, and so it’s important that, well, it doesn’t break.

In previous elections I’d experimented with using Amazon S3 – Amazon.com’s “cloud-based storage service” – as a backup site in case something went wrong with Elections PEI’s primary website.  This time out I decided to use S3 as the primary site, with the Elections PEI server as a backup should something go wrong: results were entered and managed on Elections PEI hardware and then uploaded, once a minute to S3.

You can think of S3 as a “place to put stuff on the web where other people can see it, and where you pay based on how much you store and how many people access it” and it has the virtue of being reliable, inexpensive and, in theory “infinitely scalable,” all of which are benefits for sites, like results.electionspei.ca, that get a lot of traffic, suddenly, for a relatively short window of time. Traffic like this:

results.electionspei.ca traffic

That’s zero page views per hour to 200,000 page views per hour in the space of an hour.

In total the results.electionspei.ca site received:

  • 7,422 visits from 5,557 unique visitors
  • 460,276 page views
  • 62 page views per user on average
  • an “average time on site” of 44 minutes
  • visits from 11 countries (98% from Canada and 90% from PEI)

By comparison, the results website for the 2007 Provincial General Election received 203,187 page views.

The web browsers that visited the site yesterday were:

  • Internet Explorer, 65%
  • Firefox, 18%
  • Safari, 9%
  • Google Chrome, 5%

Almost exactly half of the traffic was identified as coming from users with “cable” Internet, and half from “DSL” Internet; of the 7,422 visitors, only 28 were identified as using “dialup.”

(All of the above data was gathered, anonymously, from Google Analytics).

Amazon S3 performed well, and there were, as far as I know, no technical issues at all with throughput or availability. And this came at a very attractive price: the entire infrastructure cost for the results website was $2.44. Yes, two dollars and forty-four cents:

results.electionspei.ca cost

It cost 1 cent to store the data, 56 cents to put it there (data was uploaded from the Elections PEI intranet server every minute) and $1.87 to deliver it to the public (the reason that there were 1,872,247 “requests” was that each page view required four requests, one for the page itself, one for the CSS file, one for the Elections PEI logo, and one for the image under the sidebar).

(Brief technical tangent for those of you considering S3 as a solution for your own projects: the only annoyance with S3 hosting is that you can’t set a “default page,” like “index.html,” to be served when visitors hit your domain with no page referenced in the URL; to work around this we set the results.electionspei.ca domain to be served from Elections PEI’s Apache server and then simply redirected all traffic, with an Apache RewriteRule, to municipal.electionspei.ca/index.html. You’ll read that Amazon’s CloudFront service does allow a default page to be set; in our case, though, CloudFront’s minimum caching time of an hour didn’t suit a situation where content was changing minute-by-minute).

The results website’s pages were purposefully small and simple – the largest page was for Cornwall and it was only 14KB – to ensure they loaded quickly and worked with as many web browsers as possible.

There was one design issue that I hadn’t anticipated before the results started to come in: for wards like Charlottetown Ward No. 3, where the councillor position was acclaimed, because there were no poll-by-poll results shown for councillor it wasn’t possible to tell which polls had reported. I rolled out a quick fix for this around 8:00 p.m. by making the reporting polls bold-faced; it wasn’t a perfect solution, but I wasn’t prepared to do major surgery on a moving patient.

To ensure that everything hummed along as planned, and to free me up to deal with any technical issues that might have arisen, for the first time since 1996 I stepped out of the data-entry process entirely; logistically the process went like this:

  1. After the ballot count, results were telephoned in from the polls to a telephone bank at Elections PEI headquarters at 90 Great George Street where they were recorded onto paper sheets pre-printed with candidate names and plebiscite questions.
  2. These sheets were walked over to the data entry room where they were read aloud and simultaneously typed into a web-based editor on the Elections PEI intranet server and a Lotus 1-2-3 spreadsheet; they were then read aloud again and double checked.
  3. From the Intranet server, once per minute the results were totaled and a set of HTML pages created that were saved to the Elections PEI public webserver and then uploaded to Amazon S3.
  4. At regular intervals over the night the website totals were cross-checked against the Lotus 1-2-3 totals to ensure that accurate numbers had been entered into both.

The journey from poll-to-Internet took about 3 minutes from start to finish; results were slower to be reported than in previous elections simply because of the additional task of counting the plebiscite ballots in Stratford and Charlottetown: the first poll result was reported at 7:14 p.m. and the last poll reported was almost four hours later at 11:10 p.m.

Because there were no technical fires to put out, I was free to sit in the background, providing colour commentary on the Elections PEI Twitter feed (an experiment we launched over the weekend) and see the data entry process from the outside looking in for the first time (kudos to my colleague/brother Johnny, who did all the data entry this time out).

We’ll be back in the saddle in less than a year’s time, applying what we learned, for the Provincial General Election in October of 2011.

Data Entry

Comments

Jocelyne Lloyd's picture
Jocelyne Lloyd on November 2, 2010 - 15:30 Permalink

Hi Peter — The site never let us down all night. And we scalped from it frequently. Thanks very much! Jocelyne Lloyd, web editor, The Guardian

Robert Paterson's picture
Robert Paterson on November 2, 2010 - 15:36 Permalink

Bravo Peter!

Mike Grace's picture
Mike Grace on November 2, 2010 - 16:02 Permalink

Awesome!! Always good to hear about success stories like this.

CJW's picture
CJW on November 2, 2010 - 16:36 Permalink

Good show. I was happily refreshing on my Blackberry (w/ no css) throughout and the concise results page was great.

Good luck next year!

Peter Rukavina's picture
Peter Rukavina on November 2, 2010 - 17:06 Permalink

The issue with CloudFront wasn’t the default root object, it was the caching: CloudFront caches content by default, and although you can invalidate the cache, this seemed like more trouble than it was worth given the frequency of content updating (once per minute).