Apache SolrMetricsolr_search_handler_request_times_95percentile
Request processing time in milliseconds (95percentile).Dimensions:None
Available on:
Datadog (1)
Datadog (1)Interface Metrics (1)
Datadog
Dimensions:None
Knowledge Base (4 documents, 0 chunks)
best practicesSearch index filtering best practices | DataStax Enterprise | DataStax Docs605 wordsscore: 0.72This page provides best practices for search query optimization in DataStax Enterprise Search (DSE Search), which is built on Apache Solr. It focuses on query filtering strategies, cache optimization, and performance tuning techniques for Solr-based search indexes.
best practicesSolrPerformanceFactors - Solr - Apache Software Foundation2049 wordsscore: 0.75This page covers Apache Solr performance optimization factors including schema design, configuration tuning, caching strategies, and indexing considerations. It provides detailed guidance on mergeFactor settings, cache autowarming, optimization timing, and commit frequency tradeoffs that directly impact system performance.
other[SOLR-1972] Need additional query stats in admin interface - median, 95th and 99th percentile - ASF Jira464 wordsscore: 0.75This is a JIRA issue tracking the implementation of enhanced query statistics in Apache Solr's admin interface, specifically adding percentile metrics (median, 95th, 99th percentile) for request times. The issue was resolved in Solr 4.1/6.0 and led to the integration of the Metrics library for more comprehensive performance monitoring.
troubleshootingjava - Solr search query time increases as the start keeps on increasing - Stack Overflow744 wordsscore: 0.65A Stack Overflow discussion about Solr query performance degradation with deep paging (high start values). The thread addresses the 'Deep Paging' problem where query response times increase significantly when retrieving results with high offset values (e.g., start=100000), and suggests solutions including filter queries and Solr 4.7+ cursor-based pagination.
Related Insights (2)
CPU Saturation Masking Simple Query Performancewarning
Simple, inexpensive queries (e.g., single-term searches) become slow when CPU is saturated by other operations like indexing spikes, causing queries that should complete in <100ms to take 400ms+.
▸
Commit Frequency vs. Indexing Throughput Trade-offwarning
Frequent hard commits ensure data durability but open new searchers that spike memory usage and can degrade performance. Infrequent commits risk data loss but improve throughput. Commit timing directly impacts query latency during indexing.
▸