Friday, April 04, 2008

Comparison: Polling vs. Eventing

Polling vs. Eventing comes up every so often, and I believe that as a general rule, if you can choose events over polling, your generally better off. I think that most people agree with this, yet we still have a number of polling scenarios across our environments. Many were conscience decisions, many were the result of 'legacy' applications.

As a mental exercise, I set out to do the math.

Specifically using an web service resource that has been designed to be polled. Something akin to a queue. Our hypothetical web service will have a single operation, GetMessage. Each time we call it, if there is a message waiting to be processed, a message gets returned. If no message is available for processing, effectively a NullMessage is returned.

Lets forget about how this scales for the moment and just get an idea of the amount of operations to process 100 messages in both a polling and eventing scenario.

For the example, lets assume that I'm calling the GetMessage operation, 1/minute as my 'poll':

  • 1 GetMessage requests/minute
  • 60 GetMessage requests/hour
  • 1440 GetMessage requests/day

Each invocation of GetMessage, regardless of whether or not data is available, is processed down through the application stack: web service, business object and data tier. This puts unnecessary load on the resources involved: CPU, Memory, Disk and Network - across multiple systems. That can be a pretty expensive operation, given that it might not even produce any actual data.

If GetMessage supports multiple clients, say with operation GetMessage(clientId), to retrieve any messages for a specific client. Now, that same IO overhead increases exponentially for each client thats calling GetMessage.

Assuming (3) clients, and that all of three (3) are polling GetMessage(clientId) with the same frequency, our requests now look something like this:

  • 3 GetMessage requests/minute
  • 180 GetMessage requests/hour
  • 4320 GetMessage requests/day

Start imaging if there are more clients, or they are polling more frequently. We may find ourselves in a position of having to have hardware in place just to mainly support operations that don't produce any business value.

With an eventing scenario, to process the same 100 messages, I have 100 operations. This should give better overall resource utilization.

With anything, there are tradeoffs that have to be understood and made.

Wednesday, April 02, 2008

On Designing and Deploying Internet-Scale Services

I came across On Designing and Deploying Internet-Scale Services via Arnon's Shared Items.

I am always interested in hearing what some of the challenges are for some of the big 'guys' out there and how they were met. Microsoft, Google, Amazon, do they design not only applications, but data architectures and infrastructure, to support the user loads that they have placed on them.

This is a decent summary of things to think about, but given that it only weighs in at 12 pages, there's too much to cover. Of course, not one person is responsible for the depth of this knowledge, but team(s) of such people. Still, I'd pay good money to be able to spend 2 weeks with the guys and gals that build these systems just to see how its done!

Hmmm....corporate internships? Now thats an idea! Hey, Amazon! I want to come spend my summer working along side your team! Hear that Microsoft? Google?? [echoes through virtual space]. In return, I'll ...well, I guess I'd do just about anything. I can imagine being about as excited as my kids would be to get to go to Disney World!

Do they have 'training' camps for small to medium enterprises, where they can send resources to apprentice at larger enterprises (or notable industry 'experts'), if you will, for a time? You get some of this from industry events, but thats merely scratching the surface when compared to living and breathing it.