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.
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.
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.
4 Likes
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.)
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.
4 Likes
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.