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.

What Is Included in the Work

• Diagnostics of current agent mode and its impact on performance.
• Crontab setup with locks against parallel runs.
• Switching mode in Bitrix and clearing cache.
• Testing each critical agent (notifications, exports, indexing).
• Setting up execution monitoring with failure alerts (Telegram, email).
• Detailed documentation and maintenance guide.
• 30-day post-migration support.
• Training for your team on managing agents.

Timelines and How to Order

Basic setup takes 4–8 hours. If comprehensive diagnostics and optimization of slow agents are needed — 1–3 business days. The cost is calculated individually after an audit, but on average it pays for itself in 2-3 months due to reduced load. With over 8 years of Bitrix expertise and 150+ successful migrations, our certified team guarantees a smooth transition.

Get a consultation: contact us, and we will propose a work plan for your project. Evaluate your site's performance for free.

Problems We Solve

rsync -avz to production on Friday evening, restart php-fpm, and the site returns 502 — local database settings remain in .settings.php. Classic “deployment the old way” turns into a lottery. Another scenario: a module update from the admin panel breaks a custom component template — changes aren’t tracked in version control, recovery takes hours. Without a DevOps culture, every release is a gamble.

We design a predictable DevOps cycle for 1C-Bitrix: from Docker environment to Telegram alerts. Each deployment becomes routine, each incident triggers a context‑rich alert. Below is how we solve real Bitrix team problems — with numbers, tools, and proven configurations.

Why DevOps Is Critical for Bitrix Projects?

Bitrix projects carry specific infrastructure requirements: heavy e‑commerce catalogs, 1C exchange via CommerceML, dozens of agents and events. Without CI/CD and monitoring, every change introduces risk. A single stuck agent can silently break a 1C sync for hours; a manual deployment mistake can cost a client lost orders. We’ve seen teams spend 12 hours per month just on manual deployments and crash recovery — after our CI/CD pipeline, that drops to zero.

CI/CD Pipeline: From Commit to Production Without Hands

Git migration – we move the project from FTP to Git (GitLab, GitHub, Bitbucket). Branch structure: main (production), staging, develop, feature branches. A proper .gitignore for Bitrix is non‑trivial:

/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/upload/
/bitrix/php_interface/dbconn.php
/bitrix/.settings.php
/bitrix/license_key.php

Miss managed_cache/ → the repository bloats to gigabytes. Forget license_key.php → the key leaks.

CI pipeline – automatically runs PHPStan level 5+, PHP_CodeSniffer with Bitrix standard, PHPUnit for business logic, composer audit, frontend build.

CD pipeline – deploys without human intervention. Merge to staging → deploy to staging. Merge to main → deploy to production (with optional manual confirmation). Zero‑downtime via symlink strategy: new version in a separate folder, current → symlink switches in milliseconds. upload/ lives outside release directories. Healthcheck fails → symlink rolls back automatically. Tools: GitLab CI/CD, GitHub Actions, Deployer (PHP). Deployer’s built‑in recipes for Bitrix handle shared directories and symlink deployment out‑of‑the‑box.

Docker Environment: How We Eliminate “It Works on My Machine”

The Docker environment fixes versions of all components: nginx, PHP, MySQL, Redis. Configuration mirrors production — same PHP modules, same php.ini.

Local development – docker-compose.yml includes nginx + php‑fpm 8.1/8.2 + MySQL 8.0 (or MariaDB 10.6) + Redis + Memcached. New developer: git clone + docker-compose up -d → writes code within 5 minutes. Parallel work on different PHP versions via separate compose files.

Bitrix specifics in Docker:

• /upload/ mounted as a named volume (not bind mount — permission and speed issues on Windows/Mac).
• Cron jobs (/bitrix/modules/main/tools/cron_events.php) run via a separate container with supervisord.
• “Proactive Protection” module (security) blocks requests through reverse proxy — need set_real_ip_from and realip_module.
• Database config (dbconn.php, .settings.php) set via environment variables, never through a volume with production configs.

Production – multi‑stage Dockerfile (build stage for assets, production stage with lightweight image), Docker Registry for tagged images, orchestration via Docker Swarm or Kubernetes for large projects.

Nginx and PHP‑FPM Configuration for Bitrix Performance

The difference between “site is slow” and 200 ms TTFB lies in configuration. nginx:

• location blocks for Bitrix handle urlrewrite.php for friendly URLs.
• /bitrix/admin/ IP‑restricted via allow/deny.
• expires 30d for static files — CSS, JS, images cached by the browser.
• Brotli compression (15‑20% better than gzip): brotli on; brotli_comp_level 6;.
• Rate limiting on /bitrix/tools/ protects against brute force.
• HTTP/2 push for critical resources.

php‑fpm: pm = dynamic. Calculate pm.max_children: (RAM - RAM_other_services) / avg_memory_per_process. For Bitrix, avg is 40–80 MB. OPcache: opcache.memory_consumption=256 (default 128 is insufficient — Bitrix loads thousands of files), opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 in production (reset via cachetool opcache:reset on deployment). php.ini: memory_limit=256M (up to 512M for heavy imports), max_execution_time=60, upload_max_filesize=100M. Slowlog with request_slowlog_timeout=5s catches bottlenecks before users complain.

Monitoring and Logging: What We Track

Infrastructure – Prometheus + Grafana: metrics for CPU, RAM, disk, network, service status. Alerts: CPU > 80% for 5 minutes, free RAM < 500 MB, disk > 85%, php‑fpm queue > 0 (worker shortage). Node Exporter, MySQL Exporter, PHP‑FPM Exporter collect data.

Application – Uptime check every 60 seconds → Telegram alert within a minute of downtime. Response time of key URLs: /, /catalog/, /personal/order/make/. Sentry for PHP errors — structured errors with context. Bitrix agents (b_agent): we check NEXT_EXEC < NOW() - INTERVAL 1 HOUR — a stuck agent silently breaks 1C exchange.

Logging – ELK Stack or Loki + Grafana: nginx access/error, php‑fpm slow log, MySQL slow query log, Bitrix errors. Rotation via logrotate — without it, access.log takes 50 GB after six months.

Backup Strategy and Disaster Recovery

Geographic distribution — S3‑compatible storage + separate server in another datacenter. Test restoration monthly — a backup never restored is just an illusion of security. Cron with notifications: if backup fails, alert immediately.

What’s Included in the Service

Our team brings 5+ years of Bitrix DevOps experience (over 50 successful projects) and certified engineers. The service provides:

• DevOps process documentation (deployment scheme, branch policy, infrastructure description)
• Configured CI/CD pipelines (GitLab CI / GitHub Actions) with working triggers
• Docker environment (docker-compose.yml, Dockerfile, configs)
• Ansible playbooks for server reproduction
• Monitoring (Grafana dashboards, alerts in Telegram / Slack)
• Secured access with role‑based model
• Team training: two sessions on CI/CD, Docker, and deployment
• Support during implementation (two weeks after launch)

Infrastructure‑as‑code with Ansible is 5× faster than manual server configuration and eliminates human errors.

Implementation Process and Timelines

1. Audit of current state – assess infrastructure, software, processes (2–3 days).
2. Architecture design – choose stack (Docker / K8s / Ansible), agree on CI/CD policies, set up repository.
3. Environment setup – Docker for local development, staging, production servers.
4. CI/CD implementation – write pipelines, test deployment, integrate with monitoring.
5. Monitoring and alerting – install Prometheus + Grafana, configure dashboards and notifications.
6. Team training – two sessions on tool usage.

DevOps is not a project with an end date — it’s a transition from “upload via FTP and pray” to predictable processes. Each deployment is routine, each incident carries context, each new developer does docker-compose up instead of a three‑day environment setup.

Get a consultation – we’ll prepare a tailored implementation plan within 2–3 days. Order a turnkey DevOps implementation – gain stability and full control over your infrastructure.