Browse your product documentation including release notes and installers
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.
Change log for the November 2018 Cb Response 6.2.3 & 6.2.4 Server Configuration (cb.conf) Guide:
Change log for the August 2018 Cb Response 6.2.3 Server Configuration (cb.conf) Guide:
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]?
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.
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.