Really Fat Client

Update 23rd April 2007. Apologies. It seems that I was wrong. A couple of people from Microsoft have pointed out in the comments that  what I initally thought was a big download was just the agent created a local Jet database.  I should have checked wih a network monitoring tool first. Obvioulsy too eager to blog about it – Horrors! I am starting to act liek a journalist. Still, in my defence,  if that had been documented (especially the performace white paper where WAN traffic knowledge is useful) then perhaps I may not have jumped the gun. Now someone will point me to the white paper where it is documented!

Ian

As I was looking at the performance white paper I realised there was no mention of WANs or client sizes. If fact, in the week at MMS ,I can not recall anyone talking about these things. In contrast, when MOM 2005 was launched ,a big thing was made out of the fact that the agent was smaller, quicker and more performant. Here is a table produced by the Product Group for the MOM 2005 launch.

MOM 2000

MOM SP1

MOM 2005

Scale
(nodes/zone)
1,000 2,000 4,000
Alert latency
(1000 nodes)
> 600 seconds 270 seconds 30 seconds
Agent heartbeats
(1000 nodes)
> 600 seconds > 600 seconds 30 seconds
Discovery
(1000 nodes)
15 minutes 15 minutes 3 minutes
Agent push
(1000 nodes)
30 minutes 30 minutes 12 minutes
Agent footprint
(idle)
22 MB 18 MB 3.5 MB
Agent footprint
(managing Exchange)
40+ MB 40+ MB 12MB (agent process) 6MB (host process)

Why was there not a similar one for 2007? Well I decided to push out an agent to server and when I looked at the directory in Program Files after it had been pushed it was 167 MB! For MOM 2005 it was 9 MB. No wonder no-one has talked about it. That is a serious amount to push down a thin pipe. In the States everyone seems to have plenty of bandwidth but in Europe that is not always the case. So now it makes sense that there is a lot of information on AD Integration so you build your agent into the server build.

So if you are pushing out agents over narrow or busy pipes make sure you do it out of hours.

Advertisements

2 Comments

  1. Ellis Paul

    Hi Ian,

    167MB may be the size of the agent directory but not all of that was pushed out over the wire. The amount over the wire will depend on exactly which MPs get pushed down but typically it will look something like this:

    • 7MB for the Agent MSI
    • 9MB for MPs

    If you look in the in the agent directory, specifically in the Health Service Store, there is a file in there, HealthServiceStore.edb which is over 100MB and which gets created by the agent on the box (i.e. not transferred over the network) and will probably account for a large part of the space you are seeing as used in your agent.

    Cheers,

    Ellis

  2. Chris Carlson

    Ellis is correct. There is a local jet database created for the HealthService that is used for client side state cache. The System Center folder on my machine is only 144MB and includes several larger binaries related to the Operator Console as well as a 84mb for the Health Store, with only the out of the box MPs comprising 3.5MB.

    Also, with the base MPs I have the following Memory utilization:
    HealthService.exe = 6.5MB
    MonitoringHost.exe = 5.7MB

    The numbers may not initially appear to be ‘leaner’ on the agent but you have to remember the health model paradigm is entirely different and you are gaining a TON of functionality within the same footprint…to me that translate to a win.

%d bloggers like this: