Mautic Campaign Performance and Queue Optimization

Mautic is an incredibly powerful tool, but as your database grows to tens of thousands of contacts, you will likely notice performance bottlenecks. Campaigns may trigger late, email delivery might slow down, and your server CPU usage could spike. Most of these issues stem from poor cron configurations, unoptimized queue systems, and database index bottlenecks. In this guide, we will cover the exact steps required to optimize Mautic's performance for large-scale operations.

1. Cron Job Best Practices: Splitting Tasks

By default, many developers set up a single cron job to handle all Mautic operations, or schedule them all to run every minute. This leads to process overlap and database deadlocks. Instead, you must separate Mautic's core commands and run them at staggered intervals:

# 1. Update contact segments (Every 15 mins, staggered)
*/15 * * * * php /path/to/mautic/bin/console mautic:segments:update > /dev/null 2>&1

# 2. Update campaigns (Every 15 mins, offset by 5 mins)
5,20,35,50 * * * * php /path/to/mautic/bin/console mautic:campaigns:update > /dev/null 2>&1

# 3. Trigger campaign events (Every 10 mins)
*/10 * * * * php /path/to/mautic/bin/console mautic:campaigns:trigger > /dev/null 2>&1

# 4. Process email queue (Every 5 mins)
*/5 * * * * php /path/to/mautic/bin/console mautic:emails:send > /dev/null 2>&1

Staggering your cron jobs ensures that the CPU has breathing room to complete one job before another begins, reducing database load significantly.

2. Setting Up a Queue System for Emails

If Mautic is configured to send emails "immediately" (Sync mode), it forces the PHP process to wait for the SMTP handshake for every single contact. This slows down form submissions and campaigns. You should always change your Mautic configuration to "Queue" mode. This writes the outgoing emails to a local directory or a message queue first.

To scale further, integrate an external queue provider like Redis or RabbitMQ using Symfony's Messenger component (supported in Mautic 4+). When a campaign triggers an email, the message is sent to a high-speed Redis queue. Staged worker daemons then process these messages in parallel, increasing email delivery throughput from a few hundred per hour to tens of thousands per hour.

3. Database Indexing and Performance Tuning

Mautic's database schema includes several tables that grow rapidly, particularly the lead_event_log, page_hits, and email_stats tables. Over time, queries on these tables can slow down. Here are the steps to keep your database healthy:

• Regular Cleanup: Use Mautic's cleanup commands to delete historical data that is no longer needed:

  php bin/console mautic:maintenance:cleanup --days-old=365

• InnoDB Buffer Pool: Ensure your MySQL server has enough memory allocated to the InnoDB Buffer Pool (ideally 60-70% of available RAM on a dedicated database server) to cache indexes in memory.
• Analyze Tables: Run OPTIMIZE TABLE on major log tables periodically to reclaim unused space and rebuild indexes.

4. Caching Assets and Dynamic Content

Make sure you use a CDN (like Cloudflare) to serve all tracking pixels (mtc.js) and landing page assets. Enable PHP's OPcache with optimized production settings to speed up Mautic's code execution, and use Redis to handle Mautic's internal system cache instead of the default filesystem cache. This reduces disk I/O bottlenecks, which are common on budget virtual servers.

For expert assistance in scaling your campaign infrastructure or troubleshooting performance issues, visit our Mautic Customization Services page.