So... BigFix Explorer... what is it for?

Reading the release information and documentation, I can see what BigFix Explorer does, but it’s not clear why I should be interested in using it. We make fair use of the BigFix REST API, but this appears to only replace the processing point of the /api/query endpoint and add a new /api/relevance endpoint. The other REST API endpoints are all still processed by the root server, I assume.

So, under what circumstances would I want to consider deploying a BigFix Explorer instance? Is this just sprinkles on the already-well-frosted BigFix cake? Or maybe a critical part of future platform components that will make extensive use of it? Or am I missing something obvious? :open_mouth:

I’m not sure that the Explorer capabilities are really meant to fulfill a customer-facing need.

You might be interested in it if you were sending so much REST Query traffic that your were bogging down your Web Reports server and wanted to offload that traffic.

Internally, decoupling the ‘Session Relevance’ and ‘User Reporting’ functions opens the door for us to change how the platform scales.


In my case, we heavily rely on the stability and performance of the BigFix REST API and our automation send continuos and sometimes expensive queries against it.
We have seen slow responses when the automation hits the api during a prod deployment of patching actions. We have programmatically throttled down the number of continuous calls to avoid requests to get delayed. Even after using a dedicated Web Reports for this we continue seeing performance issues. We are in the progress of renewing and sizing up our BigFix infra but still after that I think decoupling the api from other components may improve the stability and performance of our environment.


Improving performance and stability is certainly one of the goals. We wanted to break the service out from Web Reports, offer multi service capability, and new data integration options. We will be publishing a blog on this soon to provide more detail on the offering and the “seamless” integration. We expect additional capability will be forthcoming.

Bottom line, you should consider this a great new addition to one of the fundamental building blocks of BigFix. As always, we are happy to receive feedback.


Consider moving your \program files to NVM/e. We did and see incredible ROI from perfmon reports.

NVM/e always makes things better. :-). Our explorer improvements will complement this.

We describe in our NFR guide how to determine if you have storage issues:

Anecdotally, I would say around 80% of the performance issues we see are a combination of storage and virtualization. You can make both work extremely well.