From initial install of the agent to it showing up in the console for a master operator should be between 30 seconds and 120 seconds if using client settings to speed up the initial registration / provisioning, at least in my experience. It will always take longer for a non-master operator to see the system in the console than a master operator, but even that time can be greatly reduced, but that depends on the complexity of the logic that causes an operator to get the computer assignment.
For Linux hosts, they do not use the clientsettings.cfg file like Windows/Mac, so that doesn’t work.
I have a script that solves this problem: tools/bash/install_bigfix.sh at master · jgstew/tools · GitHub
It creates a clientsettings.cfg if one does not exist, but then it also populates /var/opt/BESClient/besclient.config with the settings from it on Linux using awk.
The goal of the script is to greatly simplify the process of installing bigfix on ANY linux host that has an internet connection.
I have an example clientsettings.cfg file here: An example clientsettings.cfg to set the default BigFix client settings at install time. Only works with the Windows EXE installer or the OS X installer. For linux, see here: https://github.com/jgstew/tools/blob/master/bash/install_bigfix.sh · GitHub
I try to populate it with settings that I think are a good idea as defaults in general, as well as those that would speed up initial provisioning. The workidle setting should probably be lowered after initial provisioning to lower idle CPU usage, but there is a power save mode setting that actually makes it possible to have a higher work idle without impacting the CPU usage as negatively. If an aggressive command polling setting is used, it should also be set to something less often after initial provisioning.
The settings that will affect initial provisioning / registration the most are:
_BESClient_Resource_StartupNormalSpeed=1
_BESClient_Resource_WorkIdle=20
_BESClient_Download_RetryMinutes=1
_BESClient_Download_CheckAvailabilitySeconds=120
_BESClient_Resource_AccelerateForPendingMessage=1
_BESClient_Comm_CommandPollEnable=1
_BESClient_Comm_CommandPollIntervalSeconds=600
This also helps: Delay BigFix site subscription to speed up client provisioning
In my opinion, delaying a client subscribing to patching sites makes sense because the highest priority when BigFix is first installed is processing all of the operator stuff so that the system shows up in the console for a particular operator as fast as possible. The next most important thing is for the system to start processing policy actions for configuration and software installation. It is only some time later that patches really matter. It is usually a given that a newly installed client is going to find tons of relevant patches, but by delaying that processing by an hour or more you can greatly speed up the other initial work that I feel is more important to accomplish as quickly as possible in the first few hours after BigFix client installation.
I implemented this approach on my own testing root servers, as well as those at a previous employer and definitely saw improvements.
At a previous employer, we had ~250 custom sites and ~350 operators. If using the clientsettings.cfg our initial registration / provisioning time was much shorter than you are experiencing.