Self-Hosted Bitrix24 Performance Tuning: Make Your Portal Fast

Why Self-Hosted Portals Slow Down

The most common performance killers on a self-hosted Bitrix24 (Alaio) are preventable: wrong PHP version, disabled OPcache, an undersized InnoDB buffer pool, and caching layers left at their defaults - any one of them can double page-load times under real user load.

Unlike the cloud edition, on-premise deployments hand you full control of the stack - but that means every bottleneck is also your responsibility. Based on ACP Group's experience across 1,300+ Bitrix24 projects, slowdowns cluster around a predictable set of culprits:

• PHP running below version 8.2 (or with OPcache off)
• MySQL innodb_buffer_pool_size sized for a dev box, not production
• Managed cache and HTML cache disabled in the Bitrix performance panel
• Composite site mode turned off on public-facing pages
• Push & Pull server not configured, causing realtime features to poll on short intervals
• Static files served by PHP instead of the web server
• Modified core files that prevent updates and introduce unpredictable overhead
• Disk I/O contention when database files live on spinning HDD rather than SSD

The sections below address each layer in sequence, from hardware through application-level caching.

Right-Sizing Server Hardware

Match CPU, RAM, and storage tier to your actual concurrent user count before touching any software setting - under-provisioned hardware makes every other tuning effort irrelevant.

Bitrix24's own load-test data and field experience point to the following comfortable baseline configurations (as of 2026):

Key hardware rules:

• Database files must be on SSD (or NVMe). Spinning HDD for InnoDB data causes severe I/O wait under concurrent load.
• Portal/upload files can live on HDD to reduce cost, but separate the volumes.
• Minimum RAM for any production portal is 16 GB - the 2 GB minimum in the spec sheet is for installation only.
• For 1,000+ users, a two-tier cluster (dedicated DB servers + application servers) is the standard path. Load-test results from an Enterprise cluster showed sub-1-second response for thousands of concurrent sessions using two application servers and two database servers.

For a detailed sizing reference, see Self-Hosted Bitrix24: Hardware Sizing Guide for 50 to 1,000 Users.

PHP Runtime: Version and OPcache

Run PHP 8.2 at minimum - it is the hard floor for Bitrix24 updates as of 2026 - and enable OPcache; without it, every page request recompiles every file from source, typically adding 300-800 ms of pure CPU time.

Version requirements

• Minimum: PHP 8.2 (enforced since 1 March 2024; portals on older versions cannot receive platform updates)
• Recommended: PHP 8.3 or the latest stable release
• PHP 8.1 reached end-of-life upstream and receives no security fixes

Required extensions

Critical php.ini settings

memory_limit = 256M
default_charset = UTF-8
mbstring.func_overload = 0
session.use_trans_sid = 0
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.revalidate_freq = 60

Note: mbstring.func_overload must be exactly 0. Any other value blocks platform updates and causes unpredictable string-handling bugs. This is a common legacy misconfiguration found during audits.

Upgrade path

1. Back up the entire installation (database + files).
2. Update all platform modules and Marketplace solutions to latest versions.
3. Change the PHP version in your server environment (or via the VMBitrix menu: Manage servers → Update PHP and MySQL).
4. Re-run the update check after the PHP upgrade.

Database Tuning (MySQL / MariaDB)

The single highest-impact database change is sizing innodb_buffer_pool_size to 60-70 % of available RAM - this keeps the working dataset in memory and eliminates most random-read I/O on the database server.

Bitrix24 works with MySQL 8.x (Percona Server recommended) or MariaDB. PostgreSQL is supported only on the Enterprise for Postgres license. Oracle and MSSQL are not supported.

Key parameters to review

Slow query log

Enable the slow query log (slow_query_log = ON, long_query_time = 1) during a representative working period, then review the output. In typical projects, 80 % of query time comes from fewer than 10 query patterns - usually missing indexes on CRM entity tables or unoptimised custom modules.

Bitrix24 Caching Layers

Bitrix24 ships with three distinct caching tiers - managed cache, HTML cache, and composite mode - and leaving all three at defaults is the fastest free performance win available to any self-hosted portal.

A request flows through the caching stack before reaching PHP and the database.

flowchart LR
    BROWSER[Browser / Client] --> WEBSERVER[nginx / Apache]
    WEBSERVER -->|Static file hit| STATIC[Static File Cache\nlong expires + CDN]
    WEBSERVER -->|Composite page hit| COMPOSITE[Composite Mode\nFull-page HTML snapshot]
    COMPOSITE -->|Cache miss| PHP[PHP 8.2+ / OPcache]
    WEBSERVER -->|Dynamic request| PHP
    PHP -->|HTML cache hit| HTMLCACHE[HTML Cache\nPage fragment cache]
    HTMLCACHE -->|Cache miss| MANAGED[Managed Cache\nMemcached / Redis]
    MANAGED -->|Cache miss| DB[(MySQL / MariaDB\nInnoDB buffer pool)]
    PHP --> PUSHPULL[Push & Pull Server\nRealtime events]

Managed cache (Memcached / Redis)

Enable in Settings → Performance → Caching. Managed cache stores computed PHP objects - user sessions, CRM entity lookups, permission matrices - so they are not recalculated on every request. For portals with more than 100 users, allocate at least 512 MB of dedicated cache memory.

HTML cache

HTML cache stores rendered page fragments. Enable per-component or globally. Particularly effective for intranet news feeds, workgroup pages, and CRM list views that do not change on every load.

Composite site mode

Composite mode generates a full static HTML snapshot of a page and serves it instantly to returning visitors, with only dynamic widgets loaded asynchronously. It is most impactful for public-facing Bitrix24 sites and portals with many anonymous or lightly-personalised pages.

Built-in performance panel

Navigate to Settings → Performance in the admin panel. This panel shows cache hit rates, slow component timings, and flags common misconfigurations. Review it before making any other change - it often surfaces the highest-impact issue within seconds.

Push & Pull Server: Realtime Without Polling

Without a properly configured Push & Pull server, every Bitrix24 realtime feature - chats, task updates, telephony, calendars - falls back to short-interval HTTP polling, generating 5-20× more database and PHP load than a properly configured push connection.

As of early 2021, Push & Pull is mandatory for the web messenger module. The supported options are:

• Bitrix Push Server 2.0 (local, self-hosted on the same or a dedicated server) - recommended for on-premise deployments with data-sovereignty requirements
• Bitrix24 cloud push - simpler to configure but routes realtime traffic through an external server

Older push server versions (Nginx-PushStreamModule 0.3.4/0.4.0 and Bitrix Push Server 1.0) are no longer supported. If you are running either, migrate to Push Server 2.0 immediately.

Push & Pull serves: chats, tasks, calendars, news feed, workgroups, RPA, mobile app, telephony, sales centre, document generator.

Configure at: Settings → Product settings → Module settings → Push and Pull.

Static Files, Long Expires, and CDN

Serving static assets (JS, CSS, images) with long Cache-Control: max-age headers and offloading them to a CDN removes the single largest share of repeated load from your application server - typically 60-80 % of HTTP requests by count.

Recommendations:

• Configure nginx to serve all /bitrix/js/, /bitrix/css/, /upload/, and /bitrix/images/ paths directly, bypassing PHP entirely.
• Set Cache-Control: max-age=31536000, immutable for versioned assets.
• Enable Gzip or Brotli compression on the web server for all text assets.
• For portals with geographically distributed users (common in MENA and international deployments), put a CDN in front of static paths. The dynamic portal itself stays on-premise; only static files are edge-cached.
• Use the Bitrix24 site-boost settings (Optimize page load time and Defer image loading) for any public-facing Bitrix24 site - these defer non-critical rendering and lazy-load off-screen images without code changes.

Common Bottlenecks: Symptoms, Causes, and Fixes

Use this table as a first-response diagnostic when users report slowness - matching the symptom to the right layer saves hours of unfocused investigation.

Performance Quick-Wins Checklist

Run through this checklist on any slow portal before engaging in deeper investigation - in ACP Group's audit practice, at least half of performance complaints are resolved by items in this list alone.

✅ PHP layer

• PHP version is 8.2 or higher (8.3 recommended as of 2026)
• OPcache is enabled with ≥ 256 MB memory and opcache.max_accelerated_files ≥ 20000
• memory_limit = 256M or higher in php.ini
• mbstring.func_overload = 0 confirmed
• session.use_trans_sid = 0 confirmed

✅ Database layer

• MySQL 8.x / Percona Server (or MariaDB equivalent) in use
• innodb_buffer_pool_size set to 60-70 % of DB server RAM
• innodb_log_file_size ≥ 1 GB
• Query cache disabled (query_cache_type = 0)
• local_infile = OFF
• Slow query log enabled and reviewed
• Database files on SSD/NVMe storage

✅ Bitrix24 caching

• Managed cache (Memcached/Redis) enabled in Performance panel
• HTML cache enabled for high-traffic components
• Composite mode enabled for public/semi-static pages
• Performance panel reviewed for flagged issues

✅ Realtime and push

• Push & Pull server configured (Bitrix Push Server 2.0 or cloud)
• No legacy push server versions (0.3.x or 1.0) in use

✅ Web server and static files

• nginx (or Apache) serves static paths directly, bypassing PHP
• Cache-Control: max-age set for static assets
• Gzip or Brotli compression enabled
• CDN in front of static assets (for distributed or international teams)
• Site-boost options (optimize load time + lazy image loading) enabled on public sites

✅ Hardware and OS

• Server RAM meets the sizing table for your user count
• DB volume is on SSD; portal files may be on HDD
• TCP socket reuse settings tuned for high-concurrency (tcp_tw_reuse)

✅ Code and customisation

• Core file modification audit run (built-in Quality Monitor tool)
• Modified core files documented and planned for migration to custom modules
• All third-party Marketplace solutions updated to latest versions

When to Call in an Expert

If the checklist above does not resolve the slowdown, the bottleneck is almost always either a deep database query pattern from custom code or an architectural constraint - both require profiling tools and portal-specific knowledge to diagnose quickly.

Signs that a structured audit is worthwhile:

• Response time is above 2 seconds for standard CRM operations after basic tuning
• Slowness only appears under concurrent load (20+ simultaneous users), not in isolation
• Core files have been modified and cannot be cleanly updated
• The portal is approaching a user-count tier that requires a cluster topology

ACP Group, a Bitrix24 Gold partner with 1,300+ completed projects, offers performance audits that cover the full stack: hardware sizing, PHP/DB configuration, caching architecture, and custom-code profiling. The Self-Hosted Bitrix24 High Availability guide covers the cluster path for portals that have outgrown a single server.

For context on the broader decision between cloud and on-premise, see Self-Hosted vs Cloud Bitrix24: Complete 3-Year TCO Analysis and Self-Hosted Bitrix24 Security Hardening: 25-Point Checklist for the security side of the same stack.

Working with a partner on self-hosting. Want the control of self-hosted Bitrix24 without running the server yourself? ACP Group can deploy and operate it for you - see managed self-hosted Bitrix24, support & maintenance plans, or request a turnkey deployment quote.