Log Search Performance Calculator
Estimate query response time when searching across a large log index.
About Log Search Performance Calculator
Log search time is a function of how much data must actually be scanned relative to the search cluster's throughput: search_time = index_size ÷ search_throughput, but effective scan volume shrinks dramatically once filters (time range, indexed fields, term filters) narrow the search space: search_time = (index_size × optimization_factor) ÷ search_throughput. A tight time-range filter combined with selective field queries is usually the single biggest lever for search latency.
Formula
search_time_sec = data_scanned_GB / scan_throughput_GBps
- data_scanned_GB
- Volume of log data scanned for the query (GB)
- scan_throughput_GBps
- Search engine scan throughput (GB/sec)
Worked example
With the default values below, Log Search Performance Calculator returns Estimated Search Time of 250.00. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Index Sizeaccepts 0–10,000,000 GB
- 500 GB
- Search Throughputaccepts 0.01–100,000 GB/sec
- 2 GB/sec
- Query Optimization Factoraccepts 0.05–1 ×
- 1 ×
Results
- Estimated Search Time
- 250.00 seconds
- Speedup vs Full Scan
- 1.00 ×
- Time Saved by Optimization
- 0.00 seconds
- Unoptimized Search Time
- 250.00 seconds
Step by step
- 1Effective scan volume: index × optimization factor= 500.00 GB
- 2Search time: effective scan ÷ throughput= 250.00s
- 3Unoptimized (full scan) search time= 250.00s
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
What's the single biggest lever for faster log search?
Narrowing the time range is usually the most effective optimization, since most log search backends partition data by time (daily/hourly indices) and can skip entire index segments outside the requested range without scanning them at all.
How does field selectivity affect the optimization factor?
Querying on low-cardinality, indexed fields (e.g. exact service name or log level) lets the search engine use inverted indices to jump directly to matching documents, versus full-text search across unindexed or highly variable fields which requires scanning much more data.
Does index size or shard count matter more for search speed?
Both matter — larger indices take proportionally longer to scan per this model, but poor shard sizing (too few large shards, or too many tiny shards) also hurts parallelism and can dominate actual query latency beyond what this simplified model captures.
Why is my actual search slower than this estimate?
Cluster resource contention (CPU, JVM heap pressure, concurrent queries), cold caches on infrequently-queried indices, and complex aggregations beyond a simple filtered scan can all add latency this linear throughput model doesn't capture.
Related Calculators
You might also need
- Log Parsing Performance CalculatorCommonly used together
- Log Ingestion CalculatorCommonly used together
- OpenSearch Index Size CalculatorCommonly used together
- Observability Cost CalculatorCommonly used together
- Fluent Bit Throughput CalculatorAlso in Logging & Observability
- Fluentd Buffer CalculatorAlso in Logging & Observability