Monday, 30 January 2012

A Billion Hits - Countries and Browsers

Over 2011 the GeoNet web site has received over one billion hits.  It's a surprising number given the optimization we do to reduce the number of hits (which put us in the top ten for download speed in an independent audit of New Zealand web sites).  We process the logs to track which browsers people are using so we know which versions to target.  We can also use the ip address from the request to figure out which country the request originated from which can help with capacity planning.

Breakdown By Country

Not surprisingly the majority of the traffic for 2011 came from New Zealand (86%) - there were a lot of felt earthquakes in New Zealand.  The other perils (volcanoes and tsunamis) that cause a lot of international traffic to the GeoNet web site were fortunately quiet.

Traffic to the GeoNet web site by country for 2011 - New Zealand dominates at 86%.

Breakdown By Browser

With eighty-six percent of requests for 2011 coming from New Zealand we can make a reasonable survey of the web browsers being used in New Zealand.  We also look at the type of web browser used to make the requests by vendor and version.  Why do we care?  The browser fetches and renders HTML, CSS is used to style the rendered page (to change the look), and JavaScript is often used to change the style further and to make the page interactive.  There are several different versions of HTML, CSS, and JavaScript.  The browser vendors implement slightly different subsets of those standards and occasionally add their own extensions.  If a web page is anything more than very simple it can be a great challenge to get it to behave consistently in different browsers.  To be fair, this situation has improved immensely over the last year but is still complicated by requests from older versions of browsers.

Browser Vendors

The great majority of traffic to the GeoNet web site comes from four main web browsers;
Plotting traffic by browser vendor over the year we see similar trends as elsewhere.  We don't seem to see the same rapid upswing in use of Chrome that is seen elsewhere and we're a little higher on Firefox and Safari.

Breakdown by Browser Version

This is where things get tough - there are different versions of every vendor's browser.  From the four vendors above we have seen requests from a total of twenty two different browser versions.  If you want to see a web developer cry take them out for a beer or two.  When the alcohol starts to replace the caffiene, they relax a little, and their fingers stop twitching, ask them about cross browser compatibility.   They will probably spend the rest of the night sobbing on your shoulder.

Chrome and Firefox - The Rapid Releasers

Chrome and Firefox (since version 5) both use a rapid release schedule - they are releasing versions something like every six to sixteen weeks and pushing updates to the browser so that it is very easy for a user to stay on the latest version.  The aim is to get new features to the user quickly.  It makes the plots over the year look spikey - a new version is released and then replaced pretty quickly.

Chrome uses rapid releases.  A new version comes and goes pretty quickly in the traffic.

Firefox has used rapid release since version 5.  There are still some version 3 users hanging in there though.

Safari and IE

Safari and IE use a different release approach so the plots are smoother.

Time for an Upgrade?

If you are using an older version of one of these browsers it could be time for an upgrade.  Some of them are free.  Try as many as you can.  Give each one a couple of weeks to see if you really like it.  Visit some sites you are familiar with.  You might be surprised by extra functionality - somewhere a web developer has been heroically using progressive enhancement to make that site work in as many browsers as possible but work even better in those where it can.

It's not just the look you may notice either.  Modern browsers are incredibly fast at downloading and rendering web pages.  There are other features too - a favorite of mine is a thread for each tab in Chrome.  Recall the old days when something bad happened on a web site and the whole browser crashed?  Now just the tab dies and you often get the option to wait for it to recover.  Nice!  

Now if we can just get them all to implement the same HTML standard the same way, everyone will be winning.

Friday, 20 January 2012

Using Mule - Earthquakes on the BUS

Adopting SeisComP3 for locating earthquakes has been a cross cutting change. As I mentioned in a previous post, SeisComP3 makes automatic earthquake locations and as it iterates the solution it releases many updates about an earthquake. Compare this to the current system (CUSP) where we get one or possibly two locations for any earthquake.

The current GeoNet web content is static content that is generated by daemon processes and rsynced to the public web servers. It is event driven; an XML message with earthquake details arrives from the location system, the web content is generated and then copied to the public servers. It takes around twenty to thirty seconds to update the servers. When it takes fifteen minutes or more to make an earthquake location and there is usually only one iteration this time is acceptable. Switching to SeisComP3 means that there are many location messages about an earthquake and they arrive in the few minutes that it takes SeisComP3 to finish iterating the automatic location. Clearly we need a faster way to get locations to the web.

Taking the BUS

To get the earthquake location information to the web quicker we have adopted Mule ESB, an Enterprise Service BUS.  

Note there is often confusion between ESB and messaging (e.g., JMS, AMQP).  An ESB implementation will often have messaging as one of its components.  A messaging solution on its own is not an ESB.

There are several open source ESB options available. When I was trying them out I found Mule to have a great mixture of features, documentation, community, and training available. Also, if we need them, there are commercial features and support options available beyond the open source version. These are all important features for building long term sustainable software solutions.

Our ESB implementation does have messaging, we use ActiveMQ which implements JMS 1.1.  When I get a chance I'll also try out RabbitMQ which implements AMQP and has some really nice features.

In the time we have been working on this project Mule version 3 has been released.  I've been having fun converting the ESB configuration from Mule 2 to Mule 3; it has some very nice features that make development, testing, and deployment a lot simpler.

Mule for GeoNet Rapid (Beta)

The primary use of Mule for GeoNet Rapid is to take earthquake messages from SeisComP3, transform them to a simple XML format, send them over the messaging, and insert them into the database.  The projects are available under GPL3 on Github:

  • seiscomp-producer - takes messages from SeisComP3, transforms them and puts them on the messaging. 
  • hazbus-xslt - XSLT's for simplifying the SeisComP3 output.  A dependency for seiscomp-producer.
  • quake-db-client - inserts quake messages into the database.

Note on loose coupling: Why that transform from SeisComPML to a simple XML format before sending to the messaging?  This is loose coupling - the other clients of the ESB don't need to know about the input format.  We have to do a little more work on the input (the message transform) but the benefit is that when the output format of SeisComP3 changes we only have to change the transform and not all the other ESB clients as well.

Conceptually the ESB implementation looks like this.

A reasonable question may be, "Do you really need that ActiveMQ network bridge?"  The answer is it's there to give us a lot of flexibility for when we work on adding other instances of SeisComP3 for geographical redundancy.  It's also useful to abstract away the network configuration from the Mule applications.  It remains to be seen if this architecture will make it to full production.

We've achieved a lot with Mule.  It really makes integration problems like this a lot simpler.

Finally a big thanks to David Dossot and Bruce Snyder for the books they've written on these topics and some very useful discussions.

Monday, 16 January 2012

GeoNet Rapid - Being Faster

GeoNet Rapid - Introducing SeisComP3

Over the last year we have been working on implementing a new system for GeoNet to locate earthquakes in New Zealand.  Soon we will start a public beta of the new system.  This post introduces the star of the new system: SeisComP3.  One of the main goals of the project is to be faster at locating earthquakes.  We selected SeisComP3 which was developed within the German Indonesian Tsunami Early Warning System (GITEWS) project by GeoForschungsZentrum (GFZ) Potsdam and is now maintained by Gempa.  SeisComP3 is a distributed system that uses a messaging bus.  This means that it can be scaled to allow processing of many seismic sites.  GFZ are currently processing around nine hundred sites from around the globe in real time.  Throughout testing for New Zealand SeisComP3 has proven to be very impressive and it looks like we should be able to make earthquake locations available on the web site much faster.

Locating Earthquakes - Being Faster

Being faster - easy, right?  Just stop doing the slow bit.  For GeoNet the slow part is that a person has to get involved.  The fastest we can currently typically locate an earthquake is around ten minutes but it's usually more like fifteen to twenty minutes. During the night it can be a real challenge – a pager beep wakes the Duty Officer from a dead sleep, they get up and boot a computer, login, bring up the seismograms, review, locate and finally post the event.  Learn more about locating earthquakes in the links at the end of this page.

SeisComP3 doesn't need manual help, it can make automatic earthquake locations.  As soon as it has enough data (from ten stations) it makes a first location.  As more data arrives, from more distant stations, it refines the location through an iterative process.  This process is finished when the last data arrives and is processed.  So how fast is it?  During the recent sequence of earthquakes on 23 December 2011 in Canterbury the test version of SeisComP3 located one hundred and six earthquakes over magnitude three.  On average SeisComP3 had;

  • The first automatic location after two minutes.
  • The final automatic location after four minutes. 

Compare that to how long a manual location takes!  Also, SeisComP3 doesn't struggle to keep up.  When the earthquakes are happening close together it is very hard for the Duty Officer to keep up.

On 23 December 2011 (UTC) there where 106 earthquakes over magnitude 3 in the Canterbury region.  On average SeisComP3 (SC3) had a first automatic location two minutes after the earthquake occurred and a final automatic location after four minutes.  Compare this to the fifteen to twenty minutes it typically takes to make a manual location.

So, SeisComP3 makes earthquake locations very quickly.  However, because initially it's fully automatic it can make mistakes; things like noise, two earthquakes at the same time, or the earthquake being off shore (outside the network) can cause SeisComP3 to make mistakes.  For significant events a Duty Officer will still manually review SeisComP3's work.

We are currently working out the best way to display the earthquake information as SeisComP3 iterates the location.  We're also updating our delivery systems to handle the extra information.  I'll cover these changes in future posts.


Links to information about locating earthquakes.