Besclient Performance

Usage and Config
1

I need to find out why the Server2(Relay1) takes 2min longer to “Report posted successfully”.
Server1 - apache process stop/start
Server2 - java process stop/start

Server1/Server2 are not busy at all. Relay1 (wintel) is not busy. Besclient setting is same across the board. Persisteconnection is on. I haven’t turned on debugging to see why serve2(relay1) is slow in posting the report.

Server1(Relay1)
At 15:38:22 -0400 - opsite118 (http://XYZ:52311/cgi-bin/bfgather.exe/opsite118)
Not Relevant - PROD_t1apache (fixlet:1650095)
At 15:38:53 -0400 -
Report posted successfully

Server2(Relay1)
At 11:06:57 -0400 - opsite118 (http://XYZ:52311/cgi-bin/bfgather.exe/opsite118)
Not Relevant - PROD_oci_securetools (fixlet:1650083)
At 11:08:05 -0400 -
Report posted successfully

##Server1(Relay1)

At 15:38:19 -0400 -
GatherHashMV command received.
At 15:38:20 -0400 - opsite118 (http://XYZ:52311/cgi-bin/bfgather.exe/opsite118)
Downloaded ‘http://Relay1:52311/bfmirror/bfsites/manydirlists_78/__diffsite_49f868eea8d06be7a9f29b36a7ca311eb12bdfe0_to_f64fe51f602a324bcfcb079d285b972f4243c628’ as ‘__TempUpdateFilename’
Gather::SyncSiteByFile adding files - count: 1
At 15:38:21 -0400 -
Successful Synchronization with site ‘opsite118’ (version 22690,15,344) - ‘http://XYZ:52311/cgi-bin/bfgather.exe/opsite118’
Processing action site.
At 15:38:21 -0400 - opsite118 (http://XYZ:52311/cgi-bin/bfgather.exe/opsite118)
Relevant - PROD_t1apache (fixlet:1650095)
At 15:38:21 -0400 -
ActionLogMessage: (action:1650095) Action signature verified for Execution
ActionLogMessage: (action:1650095) starting action
At 15:38:21 -0400 - actionsite (http://XYZ:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded delete “/tmp/bfinfo_ocf_automation.log” (action:1650095)
Command succeeded delete /tmp/_ocf.sh (action:1650095)
Command succeeded delete No ‘/var/opt/BESClient/__BESData/CustomSite_YYY_OCI_Automation/__createfile’ exists to delete, no failure reported (action:1650095)
Command succeeded createfile until (action:1650095)
Command succeeded move __createfile /tmp/_ocf.sh (action:1650095)
Command started - wait /bin/sh /tmp/_ocf.sh (action:1650095)
At 15:38:22 -0400 - actionsite (http://XYZ:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded (Exit Code=1) wait /bin/sh /tmp/_ocf.sh (action:1650095)
At 15:38:22 -0400 -
ActionLogMessage: (action:1650095) ending action
At 15:38:22 -0400 - opsite118 (http://XYZ:52311/cgi-bin/bfgather.exe/opsite118)
Not Relevant - PROD_t1apache (fixlet:1650095)
At 15:38:53 -0400 -
Report posted successfully
At 15:39:06 -0400 -
[ThreadTime:15:39:05] Starting processing query id 7532
[ThreadTime:15:39:06] BigFix Query Report posted successfully
[ThreadTime:15:39:06] Successfully completed processing query with id 7532
At 15:42:52 -0400 -

##Server2(Relay1)

At 11:06:54 -0400 -
GatherHashMV command received.
At 11:06:56 -0400 - opsite118 (http://XYZ:52311/cgi-bin/bfgather.exe/opsite118)
Downloaded ‘http://Relay1:52311/bfmirror/bfsites/manydirlists_78/__diffsite_3b183cace2f0e2f5164d5c43456ae68774b6a8d6_to_41ee19ee348e4a0c1c0479904586418333f1c79a’ as ‘__TempUpdateFilename’
Gather::SyncSiteByFile adding files - count: 1
At 11:06:56 -0400 -
Successful Synchronization with site ‘opsite118’ (version 22658,15,344) - ‘http://XYZ:52311/cgi-bin/bfgather.exe/opsite118’
Processing action site.
At 11:06:56 -0400 - opsite118 (http://XYZ:52311/cgi-bin/bfgather.exe/opsite118)
Relevant - PROD_oci_securetools (fixlet:1650083)
At 11:06:56 -0400 -
ActionLogMessage: (action:1650083) Action signature verified for Execution
ActionLogMessage: (action:1650083) starting action
At 11:06:57 -0400 - actionsite (http://XYZ:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded delete “/tmp/bfinfo_ocf_automation.log” (action:1650083)
Command succeeded delete /tmp/_ocf.sh (action:1650083)
Command succeeded delete No ‘/var/opt/BESClient/__BESData/CustomSite_YYY_OCI_Automation/__createfile’ exists to delete, no failure reported (action:1650083)
Command succeeded createfile until (action:1650083)
Command succeeded move __createfile /tmp/_ocf.sh (action:1650083)
Command started - wait /bin/sh /tmp/_ocf.sh (action:1650083)
At 11:06:57 -0400 -
Report posted successfully
At 11:06:57 -0400 - actionsite (http://XYZ:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded (Exit Code=0) wait /bin/sh /tmp/_ocf.sh (action:1650083)
At 11:06:57 -0400 -
ActionLogMessage: (action:1650083) ending action
At 11:06:57 -0400 - opsite118 (http://XYZ:52311/cgi-bin/bfgather.exe/opsite118)
Not Relevant - PROD_oci_securetools (fixlet:1650083)
At 11:08:05 -0400 -
Report posted successfully
At 11:08:13 -0400 -
[ThreadTime:11:08:12] Starting processing query id 7522
[ThreadTime:11:08:12] BigFix Query Report posted successfully
[ThreadTime:11:08:12] Query with id 7522 completed the processing, but an error occurred

3

A delay of 1 minute on a report is not at all unusual. If every client were constantly streaming reports we could quickly overwhelm Root Servers, Relays, and your network bandwidth itself. I’m not sure the size of your deployment, but properly tuned it is not at all uncommon for BigFix to handle hundreds of thousands of endpoints.

For this specific log, I expect the second server’s report was limited by the minimum client reporting interval.

At 11:06:57 -0400 -
Report posted successfully
At 11:06:57 -0400 - actionsite (http://XYZ:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded (Exit Code=0) wait /bin/sh /tmp/_ocf.sh (action:1650083)
At 11:06:57 -0400 -
ActionLogMessage: (action:1650083) ending action
At 11:06:57 -0400 - opsite118 (http://XYZ:52311/cgi-bin/bfgather.exe/opsite118)
Not Relevant - PROD_oci_securetools (fixlet:1650083)
At 11:08:05 -0400 -
Report posted successfully

The second report came just 1 minute 8 seconds after the earlier report. The default value for _BESClient_Report_MinimumInterval is 60 seconds as described at
https://help.hcltechsw.com/bigfix/9.5/platform/Platform/Config/r_client_set.html

I don’t see the previous report from the first log, so it was probably more than a minute earlier, so it just sent the report when the action completed and it had something worth reporting.

4

That make sense what you are saying about “_BESClient_Report_MinimumInterval”.
Sever2 did posted the 1 report before the report of “PROD_oci_securetools” which has delay of 60secs.

Does these client settings can make any difference?

_BESClient_Resource_WorkIdle=50
_BESClient_Resource_SleepIdle=500

On other thing i noticed about Server2(Relay1) , it takes while to show up in the console when the action is taken on the server but in case of Server1(Relay1), it shows up very quickly. I can’t figure out why the server2(relay1) takes longer to show up in the console action.

5

Any other specific besclient tuning parameter we need to set?

6

Any idea what’s client is doing between “Not relevant - Report posted sucessfully”. Besclient sits for at least few secs before posting the “report posted successfuly”

At 08:27:16 -0400 - opsite118 (http://xyz:52311/cgi-bin/bfgather.exe/opsite118)
Not Relevant - PROD_oci_quickendownload (fixlet:1650471)
At 08:28:23 -0400 -
Report posted successfully
At 08:28:38 -0400 -
[ThreadTime:08:28:38] Starting processing query id 7638

At 08:38:10 -0400 - opsite118 (http://xyz:52311/cgi-bin/bfgather.exe/opsite118)
Not Relevant - PROD_oci_quickendownload (fixlet:1650472)
At 08:39:14 -0400 -
Report posted successfully
At 08:39:27 -0400 -
[ThreadTime:08:39:27] Starting processing query id 7639

At 09:12:04 -0400 - opsite118 (http://xyz:52311/cgi-bin/bfgather.exe/opsite118)
Not Relevant - PROD_oci_quickendownload (fixlet:1650475)
At 09:13:11 -0400 -
Report posted successfully

At 09:15:52 -0400 - opsite118 (http://xyz:52311/cgi-bin/bfgather.exe/opsite118)
Not Relevant - PROD_oci_quickendownload (fixlet:1650478)
At 09:16:58 -0400 -
Report posted successfully
At 09:17:12 -0400 -
[ThreadTime:09:17:12] Starting processing query id 7641