Real-World Approaches for Improving Solr Search in Drupal

Introduction to Solr Search Performance in Drupal

This guide covers practical techniques for improving Solr search performance in Drupal 10 and 11 projects. You'll learn how to refine your schema design, configure query handlers for better relevance, set up proper caching, and monitor your search infrastructure in production. These approaches come from real implementations where search response times and result quality were measurable problems.

The current standard stack—Search API Solr 4.3.x with Solr 8 or 9—powers roughly 45,000 Drupal sites. The module actively supports Drupal 10 and 11, with security releases continuing through 2025. This gives you a stable foundation to build on.

Prerequisites

Before implementing these improvements, make sure you have:

• Drupal 10.2 or Drupal 11 installed and running
• Search API module (8.x-1.x) configured
• Search API Solr module (4.3.x) installed
• Solr 8.x or 9.x running (local, containerized, or managed service)
• Admin access to both Drupal and Solr configurations
• Basic familiarity with Solr's admin interface and config files

You should also have an existing search index that's working but underperforming. These techniques assume you've already verified basic connectivity between Drupal and Solr.

Step 1: Audit and Refine Your Schema Design

The biggest performance gains usually come from schema changes, not infrastructure upgrades. Start by examining what you're actually indexing.

1.1 Remove Unnecessary Fields

Open your Search API index configuration and review every indexed field. For each one, ask:

• Does this field appear in search results display?
• Do users search against this field directly?
• Is this field used for filtering or faceting?

If a field doesn't serve any of these purposes, remove it from the index. Smaller indexes mean faster queries and better cache utilization.

1.2 Configure Language-Specific Analyzers

Search API Solr ships config sets with language-aware field types. Use them instead of generic text_general fields.

For a multilingual site, configure field types like this in your schema:

<fieldType name="text_en" class="solr.TextField" positionIncrementGap="100">
  <analyzer type="index">
    <tokenizer class="solr.StandardTokenizerFactory"/>
    <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_en.txt"/>
    <filter class="solr.LowerCaseFilterFactory"/>
    <filter class="solr.EnglishPossessiveFilterFactory"/>
    <filter class="solr.PorterStemFilterFactory"/>
  </analyzer>
  <analyzer type="query">
    <tokenizer class="solr.StandardTokenizerFactory"/>
    <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_en.txt"/>
    <filter class="solr.LowerCaseFilterFactory"/>
    <filter class="solr.EnglishPossessiveFilterFactory"/>
    <filter class="solr.PorterStemFilterFactory"/>
  </analyzer>
</fieldType>

Our experience shows that switching from generic to language-specific analyzers typically improves relevance scores by 15-25% for sites with substantial text content.

1.3 Build Custom Synonym Lists

Create a synonyms.txt file with business-specific terms:

# Product abbreviations
CMS, content management system
API, application programming interface

# Industry terms
HR, human resources
SEO, search engine optimization

# Your specific terminology
widget, component, block

Place this in your Solr config directory and reference it in your field type analyzer. Review search logs quarterly to identify terms users search for that don't match your content vocabulary.

Step 2: Configure Query Handlers for Better Relevance

Default Solr query settings rarely match your specific content model. Tuning the query handler makes a significant difference in result quality.

2.1 Set Up edismax with Field Boosting

In your solrconfig.xml, configure a request handler with explicit field weights:

<requestHandler name="/select" class="solr.SearchHandler">
  <lst name="defaults">
    <str name="defType">edismax</str>
    <str name="qf">title^5.0 field_tags^3.0 field_summary^2.0 body^1.0</str>
    <str name="pf">title^10.0 field_summary^3.0</str>
    <str name="mm">2<-1 5<-2 6<90%</str>
    <int name="ps">3</int>
  </lst>
</requestHandler>

This configuration:

• Weights title matches 5x higher than body matches
• Applies phrase boosting to titles (10x) when words appear together
• Uses minimum match rules that become stricter with longer queries

2.2 Add Recency Boosting for Time-Sensitive Content

For news sites, blogs, or documentation where freshness matters:

<str name="bf">recip(ms(NOW,ds_created),3.16e-11,1,1)</str>

This applies a decay function based on the creation date. Content from yesterday scores higher than content from last year, all else being equal.

For more control, use a multiplicative boost:

<str name="boost">if(exists(bs_featured),2,1)</str>

This doubles the score for any content marked as "featured" in Drupal.

2.3 Configure Autocomplete Separately

Create a dedicated handler for typeahead suggestions:

<requestHandler name="/autocomplete" class="solr.SearchHandler">
  <lst name="defaults">
    <str name="defType">edismax</str>
    <str name="qf">title^3.0 spell</str>
    <str name="rows">10</str>
    <str name="fl">title,url</str>
  </lst>
</requestHandler>

Autocomplete should return minimal fields (title and URL only) and query a smaller field set for faster response times.

Step 3: Implement Effective Caching

Caching happens at multiple layers. Configure each one appropriately.

3.1 Tune Solr's Internal Caches

In solrconfig.xml, adjust cache sizes based on your query patterns:

<filterCache class="solr.FastLRUCache"
             size="512"
             initialSize="512"
             autowarmCount="256"/>

<queryResultCache class="solr.LRUCache"
                  size="512"
                  initialSize="512"
                  autowarmCount="256"/>

<documentCache class="solr.LRUCache"
               size="512"
               initialSize="512"/>

Monitor cache hit ratios through Solr's admin interface. If filter cache hits are below 80%, either increase the cache size or reduce facet cardinality.

3.2 Configure Facets for Cache Efficiency

In Drupal's Facets configuration, prefer low-cardinality fields:

Good facet candidates:

• Content type (5-20 values typically)
• Category/taxonomy (dozens to low hundreds)
• Publication year (limited range)
• Author (if reasonable count)

Poor facet candidates:

• Tags (potentially thousands of values)
• Individual dates (unbounded)
• User-generated labels

Each unique facet combination creates a separate cache entry. Fewer facets with fewer values means better cache utilization.

3.3 Enable Drupal Render Caching for Results

Even when the search results page varies by query, individual result items can be cached:

function mymodule_preprocess_search_result(&$variables) {
  $variables['#cache']['keys'][] = 'search_result';
  $variables['#cache']['keys'][] = $variables['result']['node']->id();
  $variables['#cache']['contexts'][] = 'user.permissions';
  $variables['#cache']['tags'][] = 'node:' . $variables['result']['node']->id();
}

This caches the rendered HTML for each result item, only rebuilding when the underlying node changes.

Step 4: Set Up Indexing for Production Workloads

How and when you index content affects both search freshness and site performance.

4.1 Configure Commit Strategies

Use soft commits for near-real-time search availability:

<autoSoftCommit>
  <maxTime>1000</maxTime>
</autoSoftCommit>

<autoCommit>
  <maxTime>60000</maxTime>
  <openSearcher>false</openSearcher>
</autoCommit>

Soft commits make documents searchable within 1 second. Hard commits write to disk every 60 seconds but don't reopen the searcher (which would invalidate caches).

4.2 Manage Index Queue Processing

In Drupal, configure Search API's index processing:

// In settings.php or a custom module
$config['search_api.index.your_index']['options']['index_directly'] = FALSE;
$config['search_api.index.your_index']['options']['cron_limit'] = 100;

This queues items for batch processing rather than indexing on every node save. Process the queue during low-traffic periods:

# Run via cron at 2 AM
0 2 * * * drush search-api:index your_index --limit=5000

4.3 Schedule Full Reindexes Appropriately

Full reindexes should happen:

• After schema changes
• After major content migrations
• After Solr upgrades

Schedule them during maintenance windows:

drush search-api:reset-tracker your_index
drush search-api:index your_index --batch-size=100

Use --batch-size to control memory usage and prevent timeouts.

Common Mistakes to Avoid

After working on dozens of Drupal/Solr implementations, certain patterns consistently cause problems.

Indexing everything "just in case"

Adding fields to the index because they might be useful later creates bloated indexes and slower queries. We've found that aggressive pruning—removing any field not actively used for search, facets, or display—typically improves query performance by 30-50%.

Using high-cardinality facets

Faceting on a field with thousands of unique values (like free-form tags) destroys cache performance. Each combination of selected facets creates a new filter cache entry. Convert high-cardinality fields to curated taxonomies or remove them as facets.

Ignoring query logs

Solr logs every query. Export them monthly and review:

• Queries returning zero results (synonym candidates)
• Queries with high refinement rates (relevance issues)
• Slow queries (possible field or handler problems)

This data should drive your tuning decisions, not assumptions about user behavior.

Treating Solr as "set and forget"

Search performance degrades as content grows and user patterns change. Plan for quarterly review cycles: check cache hit ratios, review slow query logs, update synonyms, and adjust field boosts.

Running reindexes during peak traffic

Heavy indexing operations compete with queries for JVM resources. Always schedule bulk indexing during low-traffic windows, and use batch sizes that don't overwhelm available memory.

Testing and Verification

After implementing changes, verify they're working as expected.

Measure Query Performance

Use Solr's admin interface to test queries directly:

• Go to your Solr admin → your collection → Query
• Run sample queries matching real user searches
• Check QTime in the response (should be under 100ms for typical queries)
• Review the debug output to verify boost values are applied correctly

Verify Cache Effectiveness

In Solr admin → your collection → Plugins → Cache:

• Filter cache hit ratio should exceed 80%
• Query result cache hit ratio should exceed 70%
• If ratios are low, increase cache sizes or review query patterns

Test End-to-End Response Times

From Drupal, measure full search page load:

$start = microtime(true);
$results = $index->query($query)->execute();
$solr_time = microtime(true) - $start;
\Drupal::logger('search_perf')->info('Query time: @time ms', [
  '@time' => round($solr_time * 1000),
]);

Target P95 response times under 500ms for the complete search operation, including Drupal processing.

Monitor Ongoing Performance

Set up alerts for:

• Average query time exceeding baseline by 50%
• Index queue backlog exceeding 1000 items
• Cache hit ratios dropping below 70%
• Solr error rates increasing

Teams we work with report that proactive monitoring catches problems before users notice degraded search quality.

Conclusion

Improving Solr search in Drupal comes down to thoughtful configuration at every layer: schema design that matches your content model, query handlers tuned for your relevance requirements, caching configured for your traffic patterns, and operational practices that maintain performance as your site grows.

The techniques covered here—field pruning, language-specific analyzers, edismax tuning, cache configuration, and structured monitoring—address the most common performance issues we see in production Drupal sites. Start with schema changes and query handler tuning, as these typically deliver the largest improvements with the least infrastructure change.

Getting Solr search right requires understanding both how users actually search and how your content is structured. If your team is working through search performance issues or planning a search infrastructure upgrade, we can help you audit your current setup, identify the highest-impact improvements, and implement changes without disrupting your production environment. Contact us to discuss your specific search requirements.