Our automation uses the BigFix API to create actions and read their status. To gauge how many reads/writes our automation can send to BigFix, we did some performance tests and found that BigFix would accept 300 jobs / minute (1 small fixlet targeting 1 computer), and 150 action status reads / minute.
To be safe we then set our automation to limit half the number of writes/reads (so 150 writes/75 reads), however our automation is starting to max that out. My question is does IIBM or anyone else have any similar performance numbers for a fast BigFix deployment so we know if our configuration is fast/avg/slow?
Specs: Root server = Win20012, ProLiant BL460c Gen8 with 32GB RAM, local disk. SQL Server = ProLiant BL460c Gen8, 32GB RAM, SQL server installed on local C:, databases on remote NAS storage. 50k endpoint in this deployment.
We tested the similar performance tests against our BigFIx lab environment (physical server with local SQL light installed, but with only 4 endpoints) and the performance 6x better then the above environment.
The type of storage, storage design has significant impacts on your performance. Arguably storage architecture is the most significant part of a Bigfix server. Small block size, low latency, and the more IOPs the better.
We successfully use dedicated local enterprise-grade SSDs in RAID 10 for the root server and multiple RAID 10 arrays for the SQL database. This we found to work better than SAN storage (that wasn’t optimized for Bigfix).
There are some limits in place that do restrict the pool of API responses. This could also be limiting your response time but not sure if you are hitting those.
The DB being remote on NAS might not be helping as the DB access rate is probably the limiting factor for most things.
Add the DatabaseBoostLevel DWord value to the registry key HKLM\Software\Wow6432Node\BigFix\Enterprise Server\FillDB and set it to 1
Updated: apparantly it does help all FillDB writes because my FillDB performance went from 300 messages/sec to about 1000 messages/sec after setting this DatabaseBoostLevel=1 .
Can someone explain how this setting allows makes the FillDB send to SQL faster? I don’t think it will fix my limition on the number of action creates/reads per second so I’ll still need to investigate Root and SQL server future disk options (SSD).
I am usually a doubter on excluding directories from antivirus scanning (EVERYONE says their product works better without antivirus, but I’ll take security over performance any day). But a few weeks ago I finally relented and excluded some of their paths from realtime scanning, and I’m seeing 10x performance on the FillDB operations.
DatabaseBoostLevel helps with all FillDB operations, but that page references another setting called QueryDatabaseBoostLevel which is just for BigFix Query results.
DatabaseBoostLevel improves insertion rates by using different batch sizes and merge options on the various DB insertion calls. We’ve found in our testing that property results perform best with different insertion parameters than fixlet results. So this setting uses the best settings for each type of data being inserted, rather than the same settings for everything.