Optimize Bitrix Performance: Migrate Agents to Cron for Speed

Why Hit-Mode Agents Are a Bottleneck

Imagine: an online building materials store with a catalog of 200,000 products. During off-peak hours, pages load in a second, but during the day, 10% of requests slow down to 8 seconds. The cause: Bitrix agents running in 'hit mode'. Each HTTP request checks the b_agent table, and if the execution time is due, the agent runs synchronously, making the user wait. Under peak load (100+ concurrent users), this can cause a 'cascading slowdown' effect: response time grows exponentially, and server load increases by 2-3 times. "After migration, our site speed improved 10x" — one client noted.

We help migrate 1C-Bitrix agents to cron — this moves background tasks from HTTP requests to a separate scheduled process. Result: stable site speed regardless of traffic and savings on server resources (up to 30% CPU reduction, equivalent to $100–$200 per month on a typical VPS). Contact us for a diagnosis of the current state — we will assess the situation in one day.

Three Problems of Hit-Mode Operation

1. Unpredictability. An agent with a 300-second period only runs when the next visitor arrives. At night, with low traffic, execution can be delayed for hours. This is especially critical for 1C synchronization and notification tasks.
2. Page slowdowns. A heavy agent (1C sync, sending emails) executes during the request, increasing response time for a specific user. Result: up to 7% conversion loss for each second of delay.
3. Time limit. max_execution_time (usually 30-60 seconds) can interrupt an agent, leaving the task incomplete. This leads to data duplication and errors.

Cron Advantages: Comparison Table

Cron is up to 10 times more efficient than hit mode for heavy agents.

How to Migrate Agents to Cron Correctly

Step 1. Check Current Mode

In the admin panel: "Settings → Module Settings → Main Module". Parameter "Use Agents" — if set to "Hit mode", migration is needed. Also run SQL: SELECT NAME, LAST_EXEC, NEXT_EXEC FROM b_agent WHERE ACTIVE='Y' ORDER BY LAST_EXEC DESC LIMIT 20; — if NEXT_EXEC lags behind LAST_EXEC by more than an hour, it's an indirect sign of a problem.

Step 2. Configure Crontab

Connect via SSH and open crontab:

crontab -e -u bitrix 

Add lines:

# Агенты Битрикс — каждую минуту * * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1 # Очередь почтовых событий — каждые 5 минут */5 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/event_exec.php > /dev/null 2>&1 

Check PHP path with which php. To protect against parallel processes, add flock:

* * * * * /usr/bin/flock -n /tmp/bitrix_cron.lock /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1 

Step 3. Switch Mode in Bitrix

After setting up cron and testing (run script manually: /usr/bin/php -f /path/to/cron_events.php), switch the option to "Via Cron" and save. Clear the platform cache. It is recommended to test on a staging copy first.

Step 4. Verify Execution

Run SQL:

SELECT NAME, LAST_EXEC, NEXT_EXEC FROM b_agent WHERE ACTIVE='Y' ORDER BY LAST_EXEC DESC LIMIT 20; 

LAST_EXEC should update every minute. If not, check system cron log (/var/log/cron) and PHP error output. Also set up monitoring — for example, send a Telegram alert if an agent hasn't run for more than 5 minutes.

Why Cron Saves Server Resources?

In hit mode, every request loads the server by calling CAgent::CheckAgents(). On weak configurations (1-2 cores), this can take up to 200-300 ms per request. At 1000 requests per hour, that's an extra 50-80 seconds of CPU time per hour. Cron completely removes this load, and the background process runs for 1-2 seconds per minute.