Drupal Solr Performance Tuning Guide

Performance Tuning

💡 Content Type Matters

Indexing speed varies by content type. Taxonomy terms index faster (~300/s) than nodes (~100-150/s) because nodes have more fields, entity references, and rendered content. Don't be alarmed if speed drops as different content types are processed.

Worker Count

The optimal number of workers depends on your server resources and Solr capacity. Start with 3-4 workers and increase if your server can handle more.

Workers	Use Case
2-3	Shared hosting, limited resources
4-6	Dedicated server, typical workload
8+	High-performance server, fast Solr cluster

Batch Size

Larger batches reduce overhead but use more memory. Smaller batches are more responsive but have more overhead.

Batch Size	Use Case
50	Complex entities, limited memory
100	Default, good balance
200+	Simple entities, plenty of memory

Monitoring Resources

Check System Load

# CPU and memory overview
htop

# Or simpler
top -bn1 | head -20

# Memory usage
free -h

# Disk I/O
iostat -x 1 5

Signs of Overload

High load average (> 2x CPU cores) - reduce workers
High memory usage (> 90%) - reduce batch size or workers
High I/O wait (> 20%) - disk bottleneck, reduce batch size
Swap usage - reduce workers immediately

Optimizing for Speed

Database

Ensure MySQL/MariaDB is tuned for your workload:

# Key settings for indexing
innodb_buffer_pool_size = 4G    # 50-70% of RAM
innodb_io_capacity = 2000       # For SSD
innodb_flush_method = O_DIRECT  # Reduce double buffering

PHP

CLI PHP settings (in php.ini for CLI):

memory_limit = 512M     # Per worker
max_execution_time = 0  # No limit for CLI

Solr

Ensure Solr has adequate heap memory (2-4 GB minimum)
Use SSD storage for Solr data directory
Consider disabling autoCommit during bulk indexing

Benchmarking

Run a test to find optimal settings:

# Test with 4 workers, 100 batch
drush ost --workers=4 --batch=100

# Note the items/second rate
# Adjust and compare:
drush osstop
drush ost --workers=6 --batch=200

💡 Finding the Sweet Spot

Increase workers until the rate stops improving or system load becomes too high. The optimal is usually slightly below your CPU core count.