Category: Calculators

Understanding Automation Manager traffic

By Max Ranzau


BandwidthexampleFrom the Nuts, Bolts and Bandwidth Dept. As some of you noticed, a while back RES released the Reference Architecture document for Automation Manager, so now we have one for both the core products, great. If you have no idea what I’m talking about, go read the document here. The reference doc leads in with the basic deployment scenarios and similar things, but the nittygritty stuff is on page 22+23, where we get down to the actual traffic load numbers. Some of these numbers are obviously based on estimates: For example the resulting network traffic of any job, invariably would be linked to what’s in the job in terms of modules, tasks and resources. Note: The ref.architecture doc specifies packet numbers, but since we are interested in the overall bandwidth consumption I’m leaving those number out as they’d only muddle the picture.

One more thing before we get started. The numbers listed below are obviously without Automation Manager bandwidth management involved. I may do another piece on that particular topic in the future so you get a better idea of what it actually does…

AM Agent-to-Dispatcher idle-traffic.

To begin with, lets talk about idle traffic. It’s a fact of life that all components in a network chat. The question is how much, how often and what the impact would be on the fringes on your infrastructure. Given the numbers below, chances are that you can work out the impact by yourself. While RES is keeping the formula on how to calculate the precise idle traffic under NDA, it’s pretty easy to make a couple of observations off the provided numbers. According to the examples in the document:

When idle, one AM agent spews about 47.5kByte worth of traffic per 5 min/300 sec. That’s not a whole lot as it boils down to just below 160 bytes/sec per agent.

Let’s expand on that: Even if you had 3000 agents on the same site, your total background noise from the AM agents, across all switches would be around 475k/sec. This is next to nothing on a regular LAN. Remember this is the agent-to-dispatcher poll traffic, so it would never have to cross a WAN link when you place your dispatchers strategically on your external sub-nets.

AM Dispatcher-to-Datastore idle traffic.

As most of you know, an AM Agent is wired never to talk to a datastore directly, but always go by way of at least one dispatcher.  How many dispatchers you will need depends entirely on the shape of the infrastructure you want to deploy AM in. Since each Dispatcher+ can handle 1500 concurrent agent connections, you are obviously going to have a lot less dispatchers than agents, however the kicker is that the dispatchers will usually be crossing WAN links if you have them. If you go about your dispatcher layout smartly, you should not need more than one dispatcher per wan, link which makes the following math rather easy. When the dispatchers aren’t doing anything job related, the idle traffic depends on:

A) Are there agents connected?

  • If no, the base impact is about 616k over 300 sec †1), being around 2kB/sec per dispatcher, which is negligible on most WAN links.
  • If yes, it seems there is a slight overhead when an agent is connected (22kB over 5 min = 73 bytes/sec). Presuming that number scales linear, then even with a fully loaded dispatcher with 1500 attached agents, you would be looking at around 110kb/sec dispatcher-to-datastore traffic †2)

†1)Disclaimer: As RES is keeping the formula for calculating this under wraps with the NDA stuff, I’m going to have to make a couple of leaps of faith here. Unless somebody with WireShark and the necessary time on their hands is prepared to run the numbers and verify (or spill the beans in the comments section ;)  – we can only go by what is stated in the doc. The reference document said the Agent idle traffic was measured over a 5 minute interval, but it doesn’t say so for the corresponding dispatcher traffic, thus we are going to presume they used the same measurement interval for that test. †2)The other presumption I had to make, is that each additional agent connected to a dispatcher adds on average the 73 bytes/sec onto the idle dispatcher-to-datastore traffic.

B) The other item to briefly consider: Is the dispatcher a garbage collector? This role has a very low impact and not much is posted about it anywhere at present, other than it’s selected dynamically amongst the dispatchers – supposedly similar to Citrix Zone Data Collectors as they all know about each other through their datastore. What the purpose of the RES AM data collection precisely is, when it happens, what the election criteria is, are still unanswered questions, but hopefully someone will provide that information in the near future. Anyway, based on the released numbers, we may presume the garbage collection role adds approximately 215k/5min to an idle agent, equivalent to just under 780 bytes/sec for the garbage collecting dispatcher. So unless part of your infrastructure is running over a 2G cell data connection you can probably ignore this completely.

AM Dispatcher-to-Datastore traffic, running a job

Since you hopefully won’t have your new Automation Manager installation sitting idly too much, it’s also worthwhile knowing what kind of traffic patterns you are looking at when a job is actually processing. Again we have to do a bit of guestimating based on the provided numbers in the RES reference architecture guide. The numbers are based on a job that downloads a 5.5MB AM resource. The only thing they really tell us is, that regardless if you are master caching or connecting a dispatcher directly to the datastore, the amount of data going across the wire seems roughly equivalent to the size of the resource payload + 500kB. If a dispatcher is set up as a master caching dispatcher, the transfer overhead looks to be about 200kB less than for a regular dispatcher connected to the datastore.

In conclusion, while the overhead isn’t very large, it is not easy to create usable rules of thumb out of this, as the reference document only provides one datapoint (5,5MB and resulting traffic), so in order to make an accurate estimate on traffic size, one would have to know how/if the 500kb overhead grows with the size of the resource/modules. I would suggest this would be an excellent addition to a revision of this document.

Other than that, clarifying comments are welcome!

Updated: AM2011 License Calculator

Back in Febuary 2009 I posted an article (#RG00D) on the licensing of RES Wisdom as licensing had changed a lot at the time. With the release of Automation Manager 2011 this year, we have a new license scheme on our hands once again. Basic licensing of a workstation has been dropped from 1 to 0.5, a new Small Busines Server connector has been added and also there’s the whole Service Orchestration piece which charges 0.5 licenses per serviced user. In short, it was time to give the Licensing article a well deserved overhaul.

Tip: Try clicking on the calculator on the right to jump directly to the new calculator thingy.

To read the entire licensing article, click here

Switching off – Still a good idea!

Icon, power plug 1Remember a little while back, we looked into how much money can be saved by turning off computers? An article was posted last month on how and how much money you can save if you can turn off selected computers and servers for a few hours every week. In case you missed it, the article can be read here

To make  the point that we here at are not completely bonkers (that is besides the point :), here’s a newspaper clip from the Reading Post (in the UK) of Febuary 11th. Click on it to view full-size.


Wisdom licensing 101

Icon, calculatorLike the cover of the yellow books say: A reference for the rest of us! With the release of Wisdom 2009, RES made some changes to the way the products are licensed. This post is an attempt to clarify matters a bit, as it recently has become a red hot topic. The document describes both the agent and the connector licencing scheme, and there is a nifty calculator in the article to help you figure out your license needs and associated costs. 

Click on the preview picture of the calculator below to read the complete article:

Wisdom license calculator preview

Wisdom PowerSaver/ROI Calculator

Icon, calculatorA new calculator has been posted. This one will help you determine how much power and thereby money you can save by utilizing RES Wisdom to turn off/servers in your environment. This subject was adressed in an article by Edgar over at the RESinside blog. The PowerSaver calculator builds on that article. On top of that, a ROI calculator has been thrown in for good measure. This will enable you to, just based on the simplest of Wisdom’s features, find out how long before Wisdom has paid for itself.

Have a look for yourself. Click on the preview screenshot to launch it

PowerCalc screenshot

PowerTrace DBsize Estimator

Icon, calculatorThis is kinda cool. This estimation tool will let you take a qualified guess at how big your PowerFuse database will be, approximatly. Now – before you jump in to it, here’s a brief reality check. The calculator only deals with the big tables in the PowerFuse datastore, namely the PowerTrace tables. These are the ones that matter when it comes to size. The rest of the database would rarely exceed 100 Meg anyway. Just to be clear, the following items are not taken into consideration:

  • Custom Resources
  • Uploaded .ADM files
  • Desktop and Screensaver bitmaps
  • Odd-sized icons
  • Other stuff you upload into the database.

The PowerTrace engine in PowerFuse will create database records the moment a user starts an application or launches a website. When the user closes the app or website, the record create earlier is updated with and end-timestamp. Each record created by PowerTrace is 512 bytes in size.

The calculator is an external spreadsheet stored at, where one can make online excel calculators. Have a look at the calculator by clicking on the preview image below:

Scr, powertrace calc