Console response time

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.

  1. Turn off show non-relevant content
  2. Each caching option and turning off caching in File > Preferences has been tried
  3. Show only the most important item as the ONLY column in things like, Fixlets and Tasks, Baselines, Actions and Computers
  4. 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:

  1. 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.
  2. You should be accessing the BigFix Console via a high-powered Terminal Server that is as close to the BigFix Server as possible,
  3. You should increase minimum reporting frequency for the clients in your environment.
  4. Whether you’re using Windows Defender or a third-party antivirus you should exclude the BESClient, BESRootServer, BESConsole and SQL Server processes and folders from real-time monitoring on the root server and the console server.
  5. 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!

4 Likes

Agreed on all of the above.

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.

2 Likes

Look for poorly written analysis properties as well. This could cause console freeze every refresh

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 operator of 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.

A complete rewrite is in order.

We did that. It’s the WebUI.

Unfortunately, the WebUI does not do all that the console does/did.

1 Like

This is probably not an impactful message as I believe domain relevance only re-evaluates on console login and updates to the site.

It’s unlikely that console session relevance is causing console slowness – more likely to do with the items referenced above.

When the person above referenced poorly written analyses they were mostly referring to client analysis properties.

Are you asking because your dev environment and your prod environment both have poor performance?

1 Like

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.

Faster disks faster console :slight_smile:

Please check the BigFix Health Checks Dashboard , which items are showing with the Failed status?

We installed NVM/e on application \Program Files and SQL and console still takes 30-120s between mouse clicks.

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.

1 Like

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.

1 Like

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!

1 Like

Hence the need for a road map of if you can do this in console, here is how you do the same thing in WebUI.