Emerge Test Results: January 2009

Late January in 2009, the university conducted tests of the various mechanisms available to distribute messages in the event of an emergency.

I wasn't on campus when the tests were conducted, but I did look at summaries of the results.

There were three messages sent via Emerge in relatively quick succession. It took about 13 seconds to send each message to about 2,500 clients.

The actual message sent by Emerge is the url of a web page to display, and the clients would then look up the web page, usually within a second or two.

Some machines were slower, two didn't retrieve the web page until 20 seconds after they received the URL notification.  The process of displaying a web page is slowed by disk accesses necessary to start up a web browser.

The machines in ADS were running a slightly older version of the Emerge client.  It used the web page display mechanism we use for the Nexus login web pages.  99.6% of their clients retrieved and displayed the message - 648 out of 650.

The nexus machines were running a slightly newer client, updated in December 2008 to use Internet Explorer as the message display engine.  Using IE improves the ability to use modern HTML, and not just HTML 3.2.  However this version had a bug discoverred in January.  I made a fix, and tested it, but the update wasn't distributed until after the test.  Due to this bug, the delivery was only 98% reliable.  Now that the bug is fixed, we expect it will have the same reliability as that realized in ADS.

Of the library's 300 stations, 4 failed, giving us a reliability of 98.7% I don't know if the firewall was a factor or not.

All linux emerge clients, to the best of my knowledge, worked.

Where the system was not effective was with the wireless laptops.  There were about 5 PCs registered, but none of them downloaded the emergency message.  We have theories, but more investigation will be needed.

While the 13 seconds delivery time indicates messages can be received quickly, it may have slightly overloaded the web server.  The message was relatively barebones, no external CSS file or graphic was incorporated.  We may have to rate limit the messages, perhaps to 100 per second rather than the 192 per second that we achieved without rate limiting.  That would only slow the broadcast to take about 25 seconds.

The results look pretty good.  And if we add in rate limiting, I think we should be able to scale up without much work.