Speeding up a sluggish Bitrix online store

The problem

A large Bitrix online store was noticeably slow. The cart page took 6.5–13.5 seconds to open, catalog sections fired heavy SQL queries, and the server was short on RAM — swap usage spiked to nearly 100% and monitoring kept alerting. All of it on a live store with steady traffic, where downtime wasn't an option and the Bitrix core couldn't be touched.

Before

• The cart took up to 13 seconds to open: almost all of it was spent by a single component recomputing order data that the cart page didn't need.
• Section pages ran two heavy JOINs every time for prices that a background agent had already computed but nobody was reading.
• The server's memory was maxed out: swap usage reached 99%, which slowed down everything.
• Bitrix background agents ran in «on-hit» mode, loading every user request.

What we did

• Every change went through a local-override layer, with no core modification whatsoever: Bitrix updates are survived without losing the work.
• On the cart page we switched off the calculation of data that isn't needed there (delivery and payment options are computed at checkout) — the heavy call was gone.
• Section prices are now read from already-computed fields instead of two JOINs on every page view.
• We moved Bitrix background agents from «on-hit» mode to a proper cron — the load came off user-facing pages.
• We tuned Apache and MySQL through override layers so the server's memory stopped spilling into swap.

Results

• Opening the cart sped up from 6.5 seconds to 0.19 seconds inside the component — roughly 34 times faster.
• 1,888 section pages (76% of the catalog) stopped running heavy JOINs on every view.
• Swap usage dropped from 99% to virtually zero — the server stopped hitting its memory wall.
• All of it with no store downtime and no core edits — the work lives in a separate layer.