Почему ваш Bitrix тормозит, когда заходит 50 менеджеров?

Пока в CRM работает 10–15 человек, всё может быть нормально. Менеджеры открывают сделки, меняют статусы, создают задачи — никто особенно не задумывается о скорости.

А потом начинается понедельник.

В 9:30 в систему одновременно заходят несколько десятков сотрудников. Кто-то открывает список сделок, кто-то строит отчёт, кто-то загружает документы. И внезапно карточка клиента открывается не за секунду, а за пять. Отчёт думает минуту. А иногда Bitrix вообще перестаёт отвечать.

Первое, что обычно говорят в такой ситуации: «Сервер не справляется. Давайте поставим мощнее».

Иногда это действительно так. Но довольно часто — нет.

Условно Bitrix можно представить как офис. Если в офисе работают 20 человек, всё организовано удобно: один принтер, одна переговорная, один ресепшен — никаких проблем.

Если завтра сотрудников станет 100, просто купить ещё один принтер недостаточно. Нужно понять, что именно создаёт очередь.

С сервером примерно то же самое. Можно поставить больше процессоров и памяти, но если система делает много лишней работы, новый сервер просто будет выполнять её быстрее. А через некоторое время нагрузка снова вырастет.

Поэтому прежде чем увеличивать ресурсы, стоит разобраться, что именно их съедает.

Допустим, менеджер открывает список сделок. Bitrix должен получить данные, обратиться к базе, выполнить необходимые операции, сформировать страницу и вернуть результат браузеру.

Теперь представим, что таких запросов не один, а несколько сотен одновременно. Плюс пара сотрудников запустила тяжёлые отчёты. Плюс работает обмен с другими системами. Плюс запустился бизнес-процесс. Плюс кто-то загружает большой файл.

В этот момент нагрузка складывается из множества небольших операций. И если инфраструктура или сама конфигурация проекта не рассчитаны на такой режим работы, система начинает тормозить.

Причём пользователь видит только одно: «Bitrix тупит». А причина может находиться совсем в другом месте.

Одна из вещей, которую часто можно улучшить, — кеширование. Если одни и те же данные постоянно запрашиваются и обрабатываются заново, это лишняя работа для системы. Часть результатов можно сохранить и использовать повторно.

Представим, что 50 менеджеров открывают один и тот же раздел. Нет особого смысла каждый раз начинать вычисления с нуля, если результат можно получить из кеша.

Но здесь тоже нельзя просто сказать: «Включим кеш — и всё станет быстро». Кеширование нужно настроить с учётом конкретного проекта. Где-то проблема действительно решается этим способом. Где-то кеш почти ничего не изменит, потому что узкое место находится в базе данных или в конкретном запросе.

Это особенно заметно на больших проектах. Когда в CRM несколько тысяч сделок, многие проблемы вообще незаметны. Когда их становится сотни тысяч, ситуация меняется.

Простой на первый взгляд фильтр может заставить систему обработать огромное количество данных. А если такие запросы одновременно выполняют десятки пользователей, база начинает работать на пределе.

И снова получается знакомая картина: менеджер нажал кнопку → ждёт → нажимает ещё раз → ждёт ещё дольше. При этом сервер может выглядеть вполне прилично по своим характеристикам.

То есть покупать ещё 32 ГБ оперативной памяти в такой ситуации не всегда имеет смысл. Сначала нужно найти конкретный тяжёлый запрос и понять, почему он таким стал.

На некоторых проектах именно отчёты становятся причиной проблем в часы пик. Например, компания хочет, чтобы каждый менеджер мог посмотреть продажи за месяц, выбрать несколько фильтров и получить подробную статистику.

Для одного пользователя это может занимать секунду. Для ста одновременно — уже совсем другая история. Если каждый такой запрос заставляет систему заново собирать большой объём данных, нагрузка быстро растёт.

В итоге один сотрудник открывает отчёт и почти не замечает проблемы. А когда это делают одновременно 50 человек, начинает тормозить уже весь портал.

И здесь вопрос не в том, что «Bitrix плохой». Вопрос в том, как реализована конкретная задача и рассчитана ли система на такой сценарий использования.

Слово DevOps часто звучит так, будто речь идёт исключительно о программистах и серверах. На практике для бизнеса всё проще. DevOps помогает сделать так, чтобы приложение нормально работало не только в спокойный момент, но и тогда, когда на него действительно идёт нагрузка.

Мы смотрим на всю цепочку:

пользователь → веб-сервер → PHP → Bitrix → база данных → кеш → внешние сервисы.

Ищем место, где образуется очередь. Потому что без этого можно очень долго покупать оборудование и менять настройки наугад.

Здесь интереснее всего посчитать не стоимость сервера, а стоимость ожидания.

Допустим, в компании 50 менеджеров. Каждый из них из-за медленной CRM теряет всего 10 минут рабочего времени в день. Это:

50 × 10 минут = 500 минут в день.

Или больше 8 часов. За рабочий месяц — около 180 часов.

Причём мы взяли довольно скромный пример. Если CRM регулярно заставляет сотрудников ждать по 20–30 минут в течение дня, цифры становятся совсем другими.

И это уже не вопрос удобства работы сотрудников. Это обычные операционные расходы.

Не начинать с покупки нового сервера. Сначала стоит посмотреть, что происходит с системой под нагрузкой. Например:

• сколько пользователей работает одновременно;
• какие операции создают максимальную нагрузку;
• что происходит с CPU и оперативной памятью;
• как ведёт себя база данных;
• какие запросы выполняются дольше всего;
• правильно ли используется кеш;
• какие страницы и отчёты самые тяжёлые;
• есть ли проблемы в доработках или интеграциях.

После этого уже можно принимать решение. Иногда достаточно изменить настройки серверного окружения. Иногда нужно разобраться с базой. Иногда проблема находится в конкретной доработке. А иногда действительно приходит время менять архитектуру и разделять нагрузку.

Главное — понимать, за что именно вы платите.

Для нас задача начинается не с конфигурации сервера. Сначала нужно понять текущую нагрузку и найти причину.

Если достаточно настройки кеширования — нет смысла покупать дополнительное оборудование. Если проблема в базе — увеличение оперативной памяти её не исправит. Если проект действительно упёрся в инфраструктуру — тогда уже можно говорить о масштабировании.

Такой подход позволяет не тратить деньги на ресурсы, которые проблему не решат.

Можно не гадать, нужен ли вам новый сервер. Рассчитайте нагрузку вашего проекта и получите предложение по оптимизации.

Посмотрим, сколько пользователей и операций система должна выдерживать, где сейчас возникает нагрузка и что можно изменить, чтобы Bitrix работал стабильнее.