Cb Response 6.2.3 & 6.2.4 Server Configuration (cb.conf) Guide

[#1]

Note: This document applies to both version 6.2.3 and 6.2.4.

This document describes the contents of the cb.conf file, the primary configuration file for Cb Response. By changing the values of parameters in cb.conf, you can change the behavior and performance of Cb Response.

Before editing the cb.conf file, you should be sufficiently familiar with the features and operation of Cb Response to decide about when and whether to change its configuration. For details about using Cb Response, refer to the Cb Response User Guide for your version.

See the Comments section below for a brief summary of changes to this document since the previous edition.

[triordan]

Change log for the November 2018 Cb Response 6.2.3 & 6.2.4 Server Configuration (cb.conf) Guide:

1. Corrected CoreServicesProcessSearchPageSize and CoreServicesBinarySearchPageSize, which were missing "Search" in both cases. Note that these settings are not functional in the current releases but will be in a future release.
2. Relabeled the document to apply to both v6.2.3 and v6.2.4. The changes in the November 2018 version of the document are not due to any technical change in the product.

Change log for the August 2018 Cb Response 6.2.3 Server Configuration (cb.conf) Guide:

1. Added a description of the new ManageFirewall setting, which indicates whether or not the Cb Response server setup tools will manage the configuration of firewall on behalf of the user. This replaces the ManageIptables setting, which is now deprecated.
2. Added descriptions of new settings that interact with new features in the Cb Response console that block high-impact process searches. These are: ForceBlockLeadingWildcardsInSearchTo, ForceBlockCoreJoinsInSearchTo (block searches that include binary metadata with large binary stores), and ModuleCoreDocumentCountWarningThreshold (which determines the size at which a binary store is considered “large”.)
3. Other minor corrections and improvements were also made.

[vprevin]

how does adding extra binary terms to process searches impact the estimated performance vs

ModuleCoreDocumentCountWarningThreshold Default: 10,000,000 For process searches with binary joins, sets the number of module core documents that is considered “large” enough to potentially cause performance problems. Process searches involving binary metadata with large binary stores can be blocked using the ForceBlockCoreJoinsInSearchTo cb.conf setting and also through the “Block Searches that Include Binary Metadata with Large Binary Stores” setting on the Settings > Advanced Settings page. Change Note: New in version 6.2.3

e.g. divide 10Mln by number of binary meta keys used? Say we use 20  -> ~500mln binaries

also, how does negate affect it?

(re 20 terms - yes I'm sure that's horrifying number, but sometime for 'commonly used binaries' to effectively reduce search result sets you have large granular exclusion clauses)

how about for cloud instances? [what sort of server spec is the estimate for]?

[triordan]

vprevin, Did you post this anywhere else? This page is not really monitored for technical questions, and I'm not the guy to answer this.  But I'll see whether I can get someone else to respond. Sorry for the delay.

[dseidel]

Hi vprevin. The number of binary terms doesn't affect performance nearly as much as the fact that there are binary terms present in the query at all. Even a single binary term requires that a search is performed that does a join between the events and binary cores in the underlying Solr database. When this happens, Solr must do lookups across both cores, and the expense grows with the number of documents in those cores.

I would not expect negating a term to make much of a difference here, since the relevant term indexes still need to be utilized in the search.

10M is not specific to a cloud instance vs. an on-premise instance.