Production notes on Bitrix under load: PHP-FPM, OPcache, file sessions, slow query log, binlog, nginx fastcgi_cache, CDN versus composite cache, cron locks and PHP upgrades. With settings and numbers.
12 articles
PHP developers have three common approaches to preventing parallel cron execution: advisory locks in the database, Redis SETNX with TTL, or ignoring the problem and getting duplicate runs. There's a fourth option: atomic mkdir, a POSIX primitive available on any filesystem with no external dependencies.
Polling the database to check for catalog changes is one of those things that works fine until it doesn't. The threshold isn't a crash. It's a number on a spreadsheet you finally decide to calculate.
We added Cloudflare to a Bitrix store on Thursday evening. By Friday morning: "my cart is empty, I already added items." By Saturday: "the account page is showing someone else's data."
PHP has four language-level behaviors that cause production performance problems in Bitrix: session file locking, OPcache stale entries on deploy, array copy-on-write memory doubling, and non-deterministic destructor order. These aren't bugs — they're documented behavior — but they only become visible under production load.
The Bitrix release notes say "PHP 8.4 supported." Our first client to upgrade staging got 47 deprecated notices on a single homepage request and a broken payment module. None of it was in Bitrix core.
Most Bitrix deployments have TTFB above 700ms. Not because PHP is slow. Because the Nginx config is the one the hosting provider dropped in place years ago and nobody's touched since.
A client message: "We followed all your recommendations. OPcache is on, Redis sessions are running. We even fixed the SQL queries. But the site still goes down during evening traffic spikes."
pm.max_children is the PHP-FPM configuration parameter that sets the maximum number of worker processes in a pool. On a busy Bitrix installation, getting this wrong is the most reliable way to turn a promotional spike into a 504 error wave — and the most reliable way to miss it during normal traffic.
For three months we knew something was slow. LCP on the product catalog: 4.1 seconds. Where exactly — no idea.
Our server went down at 23:00. Right in the middle of a marketing promotion.
For three months we chased a bottleneck in a Bitrix store. Rewrote MySQL indexes. Added Redis caching where it hadn't been. Pages got a bit faster, but the catalog still hung at 800-900ms on production with no obvious reason.
Every night at 02:00, our cache resets.