Console response time

RichCampbell 2022-12-01 22:15:56 UTC #21

When was this introduced? I had two guys go to Big Fix Operator training this year, the latest one in September, and Fixlet modification was taught using the console. WebUI was used for deploying and reports.

JasonWalker 2022-12-01 23:39:45 UTC #22

It’s been three or four years…the Console is still usually preferred if doing heavy Fixlet customizations, I just wanted to point out the WebUI is faster for doing a quick edit.

The WebUI version cannot yet handle Parameterized Fixlets, FYI.

strawgate 2022-12-02 14:33:59 UTC #23

If you are seeing multi-minute delays in the console then i would file another ticket and let them know that “because you’re using a remote database” is a totally unacceptable answer.

An acceptable answer might be “Performance on your corporate SQL farm is not adequate for BigFix, we’re seeing basic queries taking 2-4 seconds” or “There is a 4 second latency between the BigFix server and the SQL cluster it’s attached to.”

but “Because you’re using a remote database” is not an acceptable answer. There are tons of people, including myself, who use remote databases who do not suffer from performance problems as you’ve described them. Get your BigFix reseller / account exec involved if you have to.

atlauren 2022-12-02 19:05:08 UTC #24

Any BigFix installation of a reasonable size will move from a colocated database to a remote database. It is entirely inappropriate for support to disavow remote databases. A helpful support engagement should include paths to discover root causes for horrid delays.

I suggest asking your sales/support reps about a health check. (Tagging: @jgo, @RhondaSTK_HCL )

Meanwhile, review the sizing/performance documentation.

(FWIW, our installation is entirely virtual, on VMWare in an on-site datacenter: root server, database, relays, WebUI, etc. Everything. The database is on a dedicated SQL server. Inside the virtual environment, resource affiliation keeps the SQL server and root server colocated to the same physical host. The backline storage is… I dunno. Something nifty. I rarely need to get involved that deeply.)

bigfix.mark 2022-12-02 21:30:28 UTC #25

There are arguments for and against collocating your database with the root server. We can make either approach work. As indicated by the previous poster, any “large” installation is expected to have an anti-collocated database. The benefit is this usually comes with DBA support (and database specific resource allocation etc.). Net is, I would not let an unfortunate answer in the past carry forward. I would also add our capacity planning pretty much assumes virtual deployments. We publish an NFR guide that breaks down how to know if things ain’t working for you.

Let me also say we are well aware of the pain around the console. We are partnering with some customers on addressing these concerns. At this time, I will refrain from saying more publicly. You are welcome to message me directly if you want to discuss.

RichCampbell 2022-12-06 13:20:06 UTC #26

Thanks everyone. We have a small installation (~4000) Linux systems but went with the anti-collocated database since I didn’t want my team to be DBAs as we have real DBAs. Same reason we installed the server on Windows instead of Linux as we have no DB2 experience. I’m going to go through the keylist and other performance docs as soon as I have the opportunity.