After shutting down DSA Primary server, I have been experiencing slow download ( prefetch ) from DSA Secondary server.
Config: DSA Pri/Sec server, 40 relays, and 700 clients per each relay
Looking into client logs, I can see every duration between DownloadsAvailable:false and true is getting long.
(From primary it is always shorter than 20 sec, but from secondary it is longer than 1 min, in most cases)
All of files to be downloaded are placed on both servers and each size of it is very small, less than 200KB.
I know that if the cache for the action is already available on relaly, DownloadsAvailable always returns true and this problem does not occur.
I set _BESClient_Download_CheckAvailabilitySeconds=60 as minimum but it did not work.
Are there anything else I can do to improve download performance from secondary server ?
I would check the communication between the relays and the DSA Secondary server.
In order to do this I would take action on a fixlet with a small download, then watch the download go from the cache in the Server, to the relay to the endpoint. I would review the relay diagnostics and check when the downloads become available for the action for the relay vs. the endpoint.
I would also run a blank action on the endpoints that show this behavior. Without a payload are the endpoints reporting in a timely manner. Are the endpoints recieving udp from the relay? Are the relays receiving TCP communication from the BigFix Server and the endpoints?
the setting _BESClient_Download_CheckAvailabilitySeconds has a default of 600 seconds.
Do your endpoints utilize command polling? Sometimes this can make the download process appear slower as it is only the endpoint making request of its parent.
A couple of other things to check…make sure your relays have actually selected over to the active server.
And check the active server’s performance in general, especially the network configuration. A misconfiguration such as a network speed/duplex mismatch may have gone unnoticed while the server was inactive. A general check of the server’s performance (direct download speed, cpu & memory utilization, disk i/o) would probably be in order.
Do your endpoints utilize command polling? Sometimes this can make the download process appear slower as it is only the endpoint making request of its parent.
Do you mean this can make prefetch download slower ?
Could you tell me for what reasons ?
I confirmed that clients receiving DownloadPing in each download.
So the “seeming to make downloads seem slower” is the gap in between communications based on the fact that the agent does not know about the work it has to do until it polls for commands. So it is a perception of timing.
The other piece you stated that the agents were receiving udp signals and set to enable command polling. I think I remember that setting command polling on, means that the client can no longer receive the udp pings. I will have to do a little checking on that.
Are your relays able to communicate to your secondary server fast?
-jgo
Does anybody know DownloadPing packet is UDP or TCP ? ( or ICMP ?)
Is it different from UDP Ping ?
I am now checking tcpdump of 52311 port traffic but I cannot identify which packet is DownloadPing …