Wondering if anyone has any insights into making the console more responsive and I know we are being encouraged to use WebUI but it unfortunately does not have all of the features the console has.
My gut tells me the console application is written on a runtime framework that has passed its usefulness. Might have been good in the 90’s and 00’s, but simply is not keeping up with the demands of customers.
Things I have tried.
Turn off show non-relevant content
Each caching option and turning off caching in File > Preferences has been tried
Show only the most important item as the ONLY column in things like, Fixlets and Tasks, Baselines, Actions and Computers
Using a windows 2016 machine that is idling that has 128GB of RAM and is a Dell r730xd
None of the things help. All that we see is java wait animation icons that spin for minutes, no matter what you click on or where you try to go.
Anyone else have/has this happen and did you get anywhere to make the console more responsive?
BigFix console performance should be great for most use-cases. Part of the problem HCL has is that the BigFix console works so well from a performance perspective that getting the same performance in the WebUI takes a lot of development work!
Here are the big recommendations that you should put into action before diving deeper:
You should have exactly 1 client reporting directly into the BigFix server. The Client on the BigFix Server is the only client that should be talking directly to the BigFix Server. Everything else should talk via a relay.
You should be accessing the BigFix Console via a high-powered Terminal Server that is as close to the BigFix Server as possible,
Avoid using Master Operator accounts for day-to-day activities in BigFix
From a hardware perspective the Disk used for the root server, terminal server, and the Database are very important and should use the highest performance and most local disks possible. Ideally you’d be using NVMe SSDs local to the server itself.
BigFix performance is my favorite area to work with so let me know if I can help with any of these!
One element I’ll just re-emphasize is that Console Performance depends not just on the resources/configuration of the machine on which the Console application is running, but also is highly dependent on the performance/configuration of the Root Server & database. Oftentimes if you see the Console not responding, it is because it is waiting for the Root Server (and potentially the underlying database server) to provide it with the updated data it is looking for.
Thanks for above provided hints. As our console(s) also doesn’t perform really smooth and fluent I tried to check in addition for “long running relevance” in debug menu. No I get some messages like:
At 10.11.2022 14:47:35 in site "BES Support" in file "BESSupport.BESDomain" in filter in relevance "set of all bes sites whose ((not operator site flag of it) or (if (exists property "fixlet" of it and exists property "site file" of it and exists property "operator" of it) of type "bes site" then ((not master flag of operatorof it) or exists fixlet of it or exists action of it or exists site file of it) else true))"
Long domain relevance evaluation (100 ms)
And of course I have no idea about the meaning. 100ms are in dev environment with only Besroot, one relay and a fistful of clients. In prod environment same message with >400ms.
UI applications should not lock up at the behest of another process that is updating some values. You could indicate an update/refresh is pending but you do NOT lock the console to do anything else.
Hi @strawgate
thanks for your explanation. Yes, in my personal opinion the performance feels not as smooth as I would expect.
As an example. in our dev environment, we run the console on a win server 2016 with 4 cores and 16GB RAM. This server hosts SCA as well, but is not the BES Root server. We have only between 5-10 computers connected to BigFix in this environment.
Eg: I have a custom site containing 2 fixlets, 1 analyse and 5 subscribed computers. If I open the tree on the left site in the console, expand the custom site and click on “analyses” I can countdown 4-3-2-1 and then the analyse appears on the right site of the console.
Lookingt at task manager in windows servers as well as in top on linux server running as bes root, both are doing more or less nothing.
What I can confirm: both servers are in the same network. Both are running as virtual machines on VMware. I can imagine that the disks are not super performant.
That kind of response time is very much out of the norm. If you’ve already been through the Capacity and Planning Guide, you may need to open a support ticket and provide further debug information. The first areas I’d check would be whether EDR or antivirus software are interfering with with the disk I/O on either the root server or console machine.
Every time we face issues with the Console we are advised to use BigFix WebUI but when we bring the things that WebUI can’t do then we are advise to go back to the old old BigFix Console.
It’s very frustrating how BigFix is pushing to use a replacement tool that is not ready and still being advised to use the console for the most critical stuff. During a meeting we had recently we were just told we need to wait but they won’t give us a roadmap or timeline for this.
We opened a ticket two years ago on the console response time and were told its because our database is remote. Not very helpful. I can be in the middle of editing a Fixlet and have it hang for 30 seconds while in the middle of typing something. Very frustrating. And I don’t believe I can create/edit fixlets using the WebUI.
You can create/edit fixlets using the WebUI (check the ‘Content’ App)…
When you say the database is remote, do you mean a high latency between the Root Server and the Database, or between the Console and the Root Server? Either of those could introduce some slowness, which would be especially bad if there’s high latency between the Root Server and the database.
Is there a matrix of items in the console and where they went in WebUI? Since WebUI at this time is not going to be modified to more easily transition from the console, customers need a road map to tell them where the same feature and functionality went.
Neither. Our Database is on our SQL Cluster and not on the same system as the BES Server and we were told that was the problem. As far as I can remember, there were no latency checks done within the ticket, but I’d have to check with my co-worker.
Wow. I just dug into the Content App more deeply than I ever did before. I had no idea I could modify Fixlets from here. Just wow. Thanks!