While testing some script on TEM, i ran into a big issue where evaluation of newly created/changed fixlets and Baselines would take very very long time.
The timintg issue caused the setup to be useless for testing as a change would not propagate to the client in a timely fashion. I figured out that I needed to set the time where the client actually requests the site-definitions. By requesting the site definitions often, the client would be able to properly evaluate new actions in a timely fashion. This is the action part of the fixlet made for the test computers:
// Poll for site changes every 5 minutes (so all changes are available almost immediately)
setting "_BESClient_Comm_CommandPollEnable"="1" on "{now}" for client
setting "_BESClient_Comm_CommandPollIntervalSeconds"="600" on "{now}" for client
// Check in with report data every 5 minutes
setting "_BESClient_Register_IntervalSeconds"="600" on "{now}" for client
// work very hard to evaluate relevance, just below 10pct cpu
setting "_BESClient_Resource_SleepIdle"="460" on "{now}" for client
setting "_BESClient_Resource_WorkIdle"="40" on "{now}" for client
// enable more logging
setting "_BESClient_EMsg_Detail"="10000" on "{now}" for client
I know info about these settings are documented and available, but it did not occur to me that I had to set anything else but the register_Interval.
I am wondering if i need to set any other settings to be able to have a REALY responsive client. Any hints?
You are actually slowing down the client if you are doing some of these.
Setting the registration interval so low means the client will re-register with the relay and server every 5 mins. Not optimal to the rest of the infrastructure as you are dropping it from the default of 6 hours. The client does a lot of work to determine what relay to connect to and re-register with the server through the relay it selects so this is stealing processing power and placing your infrastructure under more strain.
Setting your client to command polling unless its required isn’t required either as the relay will send a UDP message to the client when it has new sites to fetch. This is generally only used when a firewall or some other system prevents UDP messages going from a relay to a client. UDP messages are the fasted way to get notified of new content.
When a site is gathered the new fixlets it gathers are placed first into the queue so they do get evaluated quickly. The only setting that can really help you evaluate the fixlets on the machines are the WorkIdle/SleepIdle settings which control how much of a single core the client will use.
Updating the client will also get you the best return on speed increases.
Yea, I know that overall networking will be bigtime affected. The thing is, im running 5 computers om this TEM (for testing before shipping for production), so in this case its on purpose, bringing down time spend waiting for clients to register/evaluate.
I started out as you indicated with only having the CPU upped and making the agents check in… and that kinda workd by evaluating faster … but it seemed that they did not register the changes i made in my custom site holding the fixlets and tasks i want to publish. The agent checked in allright, leaving reports and all every 10 minutes, but they did not seem to get info about the changed fixlets… until i lowered the CommandPoll-stuff. Before lowering it, it could take (maybe!) 5-10 hours before it would detect the changes on the custom site.
My test clients are running 9.0.787.0, so they should be good.
Based on the comment that the command polling helps a bit, I am thinking that Tim is on the right path with the UDP.
There is a fixlet called “Windows Firewall is Blocking BES Traffic - BES Client”, can you see if those are relevant? You can also manually check the firewall to see if it has an exception for “BES Client”.
Network wise, are these systems on the same subnet as the IEM server? If not, are the 5 systems on the same subnet? If they are, maybe try making one of them a relay and assign the systems to connect to that relay, then see what happens.
Another thing to try is use the “Send Refresh” then look at the log on the client system. You should see:
At 08:28:26 -0600 -
ForceRefresh command received. Version difference, gathering action site.
If you do not see that, then you have something blocking UDP.