Configuring deferred functions in 1C-Bitrix

A user clicks 'Place order' and sees a spinner for 4 seconds—the server synchronously sends three emails, recalculates bonuses, and calls the delivery API. Downtime increases, conversion drops. We encounter this on every second high-load project. Deferred functions solve the problem: the HTTP response returns in 200 ms, while heavy operations execute in the background after the connection is closed. This reduces server load and improves user satisfaction.

What problems do deferred functions solve?

Synchronous processing of all actions in a request leads to excessive waiting time for the client. Typical operations that can be offloaded: sending email/SMS (200–500 ms), logging to ELK or Sentry, invalidating tagged cache, external API calls (CRM, delivery services). Each such operation increases response time, and their sum can reach several seconds. Deferred functions isolate these tasks, returning control to the user instantly.

How do deferred functions work?

Starting from current PHP versions, Bitrix core supports register_shutdown_function and its own mechanism via Bitrix\Main\Application::getInstance()->addBackgroundJob(). The idea: the function is registered and executes after fastcgi_finish_request() (for PHP-FPM) or after sending a response for Apache mod_php via register_shutdown_function. The difference is critical: on PHP-FPM the connection is closed before task execution, on mod_php it is not.

use Bitrix\Main\Application;

Application::getInstance()->addBackgroundJob(function () {
    // Code executes AFTER sending the response to the client
    \Bitrix\Main\Mail\Event::send([...]);
    // Logging, API call, data recalculation
});

Critical nuance: addBackgroundJob works only if fastcgi_finish_request is available. Check: function_exists('fastcgi_finish_request'). On Apache mod_php the function will execute before the response is sent.

Step-by-step configuration of deferred functions

1. Check the environment. Run phpinfo() and find fastcgi_finish_request in the PHP-FPM section. If the function is missing, switch to PHP-FPM or use cron.
2. Identify heavy operations. Profile pages using Bitrix's built-in profiler. Identify blocks that take more than 100 ms: sending emails, logging, API calls.
3. Wrap them in addBackgroundJob. For each event handler (e.g., OnSaleOrderSaved), replace the synchronous call with a background one.
4. Configure timeouts. In the PHP-FPM pool configuration, set request_terminate_timeout=300 so background tasks are not terminated.
5. Test. Measure response time before and after. Compare using ab or JMeter.

For guaranteed execution on PHP-FPM, also check max_execution_time in php.ini—it should be at least as high. It's recommended to monitor logs for premature terminations.

Why are deferred functions better than synchronous processing?

Deferred functions reduce user response time by 3–5 times. In one project, we moved three emails and logging out of the synchronous flow—order execution time dropped from 4.5 seconds to 0.3 seconds. This directly affects conversion: every 100 ms delay reduces conversion by 1%. Server resource savings reach 40%.

Deferred functions win in speed of implementation and minimal infrastructure load. If the task is critical—use a queue.

When to use deferred functions?

• Sending email/SMS after order placement—delay 200–500 ms per message
• Logging to file or external service (ELK, Sentry)
• Invalidating tagged cache after catalog update
• External API calls: CRM notification, warehouse service update
• Re-indexing an element after modification

Typical setup mistakes

• Using deferred functions on Apache mod_php without checking fastcgi_finish_request—the function runs synchronously.
• Too short request_terminate_timeout—background tasks don't finish.
• Lack of error handling inside addBackgroundJob—exceptions may fall outside the context and not be logged.
• Offloading critical operations (e.g., fiscalization) without fallback—data loss on failure.

Practical example

On an e-commerce project with 50,000 orders per month, we offloaded sending emails (3 emails per order), logging, and CDEK API calls into deferred functions. Response time on the order placement page dropped from 4.5 seconds to 0.3 seconds. Server load decreased by 40%, allowing us to drop an additional node. The implementation paid back in less than a week due to reduced load.

What's included in the setup

• Checking server environment compatibility (PHP-FPM, fastcgi_finish_request)
• Moving heavy event handlers to addBackgroundJob
• Configuring request_terminate_timeout in PHP-FPM
• Monitoring: logging execution time of background tasks
• Testing: measuring response time before and after moving operations to deferred functions

How we help

We have implemented deferred functions on 30+ projects. Our engineers know all the nuances of fastcgi_finish_request and PHP-FPM configuration. We provide documentation and post-implementation support. Get a consultation—we will assess your project in 1 day. Contact us to find out if your site is suitable for this optimization.

According to the official PHP documentation, fastcgi_finish_request is only available when using FastCGI Process Manager. fastcgi_finish_request

Additionally, refer to the documentation for addBackgroundJob on the official 1C-Bitrix portal.

What Professional 1C-Bitrix Installation Includes

We start by checking innodb_buffer_pool_size. The default MySQL value (128 MB) is a death sentence for an online store with a catalog of 10,000+ items. We set 70–80% of available RAM on a dedicated server, 50% on VPS. This single setting speeds up the site by 2–3 times compared to the default. We'll assess your project in one day — get a consultation. Contact us to order turnkey installation with performance guarantee.

How to Choose Hosting and Edition for 1C-Bitrix Installation?

BitrixVM is a virtual machine with a pre-installed stack: nginx + Apache, PHP-FPM, MySQL/MariaDB, Sphinx, Push server. For VPS — the best start. Everything is already configured for Bitrix, including OPcache, log rotation, and firewall. Management via web panel on port 8890. Bitrix documentation recommends starting with BitrixVM for predictable performance.

VPS/VDS is the sweet spot. Minimum configuration for a medium online store: 2 vCPU, 4 GB RAM, SSD. Optimal: 4 vCPU, 8 GB RAM. OS: Ubuntu 22.04 or Debian 12. If not BitrixVM, we configure the stack manually for the task. Virtual hosting — only for business cards and landing pages. Requirements: PHP 8.0+, MySQL 5.7+ / MariaDB 10.0+, 512 MB RAM, .htaccess. 1C-Bitrix hosting partners guarantee compatibility. Dedicated server — for highload. Typical architecture: web server separate, database separate, Redis/Memcached separate. For Enterprise edition — web cluster with load balancer. Cloud (Yandex Cloud, VK Cloud, Selectel) — when load spikes: sales, seasonal peaks. Autoscaling via Managed Kubernetes or simple VM vertical scaling.

Choosing the edition is equally important. A common mistake: choosing "Small Business" for a store that grows to B2B with wholesale prices and three warehouses in six months. Upgrading to "Business" — pay the difference, data is not lost, but it's better to plan ahead. Our specialists select the edition for current tasks and with room for growth. For example, the "Business" license (about 35,000 RUB) pays off through multi-warehouse and 1C exchange, while the wrong choice can lead to a loss of up to 30,000 RUB monthly on excess resources.

What Server Settings Are Critical for 1C-Bitrix?

Web Server and PHP

nginx as reverse proxy + Apache (mod_php) or nginx + PHP-FPM directly. The second option saves memory — Apache is not needed. But some Bitrix modules use .htaccess, so for compatibility we sometimes keep Apache. nginx configuration: fastcgi_read_timeout 300 — for long operations (1C import), client_max_body_size 1024m — large file uploads. Block access to .settings.php, .settings_extra.php, bitrix/.settings.php — they contain database passwords. Rewrite rules from urlrewrite.php — Bitrix generates them, but with nginx + PHP-FPM they need to be duplicated. PHP 8.0–8.2 with extensions: mbstring, curl, gd, xml, json, opcache, redis/memcached. Key php.ini settings: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, max_execution_time=300, memory_limit=512M, upload_max_filesize=100M, post_max_size=128M.

Database and Caching

MySQL/MariaDB. Key my.cnf parameters: innodb_buffer_pool_size — 70–80% RAM, innodb_log_file_size=256M, tmp_table_size=256M, max_heap_table_size=256M, thread_pool_size — number of CPU cores. Encoding utf8mb4 mandatory, otherwise emoji and special characters break. Redis is preferable to Memcached for Bitrix — supports persistent connections and is more reliable. In production, Redis handles concurrent writes three times faster than Memcached under typical load. Configure in .settings_extra.php:

'cache' => ['value' => ['type' => ['class_name' => '\\Bitrix\\Main\\Data\\CacheEngineRedis']]]
'session' => ['value' => ['mode' => 'default', 'handlers' => ['general' => ['type' => 'redis']]]]

sudo apt install redis-server
sudo systemctl enable redis

SSL, Email, and Cron

SSL — Let's Encrypt via certbot in 90% of cases. Redirect HTTP → HTTPS (301), HSTS, TLS 1.2/1.3, OCSP Stapling. In Bitrix, switch to HTTPS in the main module settings. Email: abandon mail() — connect SMTP (Yandex.Mail for domain, Mail.ru for Business). Be sure to configure SPF, DKIM, DMARC. Without SPF, emails go to spam. Test deliverability via mail-tester.com — score 9+/10. Cron: Bitrix agents switch to system cron — * * * * * /usr/bin/php /var/www/bitrix/modules/main/tools/cron_events.php. Schedule 1C exchange (15–60 min), search reindex, backups (mysqldump + rsync, rotation 7+4), temporary file cleanup.

Security and Administration

File system: owner www-data, directories 755, files 644, upload 775. nginx blocks access to configuration files. Enable Bitrix Proactive Protection — WAF, activity control (block after 5 failed attempts), kernel integrity check. For admin panel: two-factor authentication via Google Authenticator or OTP, restrict access by IP via nginx for paranoid.

How Long Does 1C-Bitrix Installation and Configuration Take?

Post-Installation Checklist

1. Performance Monitor (/bitrix/admin/perfmon_panel.php) — aim for 30+ points. Below 20 means serious configuration issues.
2. System Check — automatic check of all parameters. Red items must be fixed, yellow — case by case.
3. Security Scanner — check for typical vulnerabilities.
4. PageSpeed Insights — TTFB < 200ms on VPS, LCP < 2.5s.
5. Test 1C exchange — if integration is planned, verify CommerceML exchange before launch.

Additionally, check software versions, caching settings, cron operation, SSL certificate, SPF/DKIM/DMARC, access rights, delete default users and pages. For projects with 54-FZ, ensure fiscalization is configured via OFD provider.

Deliverables

• Fully configured server for 1C-Bitrix with MySQL, PHP, nginx optimization.
• Installed and activated license of the required edition.
• SSL certificate, email settings, cron and backups.
• Documentation: all configuration parameters, access credentials, cron tasks.
• Content manager training: how to log into admin panel, add products, upload images.
• Post-installation support for 30 days — consultations on settings.

Why Trust Professionals with Installation?

Incorrect installation means lost time and money. We've seen projects where a store on "Start" couldn't handle 50 visitors because innodb_buffer_pool_size wasn't configured. After migrating to VPS with correct configuration, the site "flew". Incorrect configuration can cost 30,000 RUB monthly due to excessive resource consumption. You get a ready-made architecture that scales. Order turnkey 1C-Bitrix installation — get a reliable platform for business growth. Contact us for a free consultation: we'll calculate the cost and time for your project. Over 7 years of experience, 120+ Bitrix projects implemented, including highload stores with million-item catalogs. Get in touch — we'll help configure Bitrix for your project.