Как делать highload на Битриксе. И надо ли

Степан Овчинников
Александр М.

Товаров — десятки миллионов, функций — много, и посещаемость — большая?

Как делать такой веб-проект на 1С-Битрикс?

Сразу брать “кластер”? Сразу переписывать с Битрикса на “то, что выдержит”?

Разбираемся в теме, даем советы, обобщаем опыт.

Тема емкая, начинаем традиционно с выводов:

  1. На Битриксе можно быстро запустить работающий прототип хайлоад-проекта.

  2. Такой прототип способен выдержать довольно большую нагрузку.

  3. Для успеха нужно включить светлую голову разработчика и ограничить фантазию Заказчика.
    Хайлоад-прототип – это серьезно.

Подробности и рекомендации – далее. Итоги нагрузочного тестирования — в следующей статье.

О чем речь вообще? Что такое высоконагруженные проекты?

Конечно, это в первую очередь e-commerce.

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

На втором месте корпоративные порталы на базе Битрикс24. Программный код тяжел, каждый пользователь выполняет сотни действий, кешировать в интранет-площадке почти нечего. Результат: несколько сотен активно работающих в корпоративном портале сотрудников создают нешуточную нагрузку.

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

Хайлоад в Битрикс-проектах. Цифры

Часто спрашивают: а вот у нас много товаров. Выдержит? Какой сервер нам покупать?

Каков предел работы сайта? Что такое высоконагруженный проект на Битриксе?

У каждого сайта свои особенности и структура нагрузки. Где-то много просмотров, где-то частые обновления, где-то нагруженная страница с вычислениями и статистикой (например, для онлайн-аукциона).

Поэтому точный ответ на этот вопрос может дать нагрузочное тестирование (до запуска, чтобы определить пределы) или проверка в боевых условиях (упадет – узнаете). Кстати, как своевременно узнавать о проблемах на своем сайте и обеспечить быстрое восстановление – читайте в статьях:

В “среднем” ситуация на Битриксе такова:

Если товаров в интернет-магазине до 100 тысяч, посещаемость не превышает 10 тысяч человек в сутки, и обмен с учетной системой 1С выполняется с разумной частотой, то выделенный сервер и аккуратно запрограммированный сайт справятся.

Это пока не Highload.

Параметры “объем базы, частота изменений, посещаемость” взаимосвязаны, и увеличение одного при уменьшении второго может сохранить нагрузку в тех же пределах.

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

“Highload” – когда несмотря на хорошо настроенный мощный сервер и грамотно написанный код, сайт не выдерживает нагрузку.

Нужно искать решение. Что можно сделать?

Решения проблемы высокой нагрузки

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


Первое решение быстрое и надежное: “кластер”.

Тот же Битрикс с тем же кодом разворачивается на “кластере” сначала из 2 серверов, потом из 4, 8, и так далее.
2 сервера допустимы на лицензии Бизнес, а дальше потребуется Энтерпрайз (стоимость 1.5 миллиона рублей).
Что это дает? Это позволяет очень быстро поднять во много раз пропускную способность вашего сайта.
Программистам придется немного поколдовать над настройкой, но – Битрикс это позволяет, и добавление серверов повышает возможности почти линейно.

Второе решение долгое и рискованное, но при успехе – экономит время, деньги, сервера: “оптимизация”.

Нужно найти то, что тормозит, и переделать. Это можно поручить только программисту, имеющему опыт работы с высокой нагрузкой. 1С-Битрикс тоже нужно знать, но главное – опыт работы “руками”.
Поможет только глубокая эрудиция и практический опыт.

Третье решение: “упрощение” логики сайта.
Порой нужно не переделывать реализацию, а убрать пару функций.
Например, убрать постраничную навигацию на странице списка товаров категории. Поможет.

Битрикс или “что-то другое”?

Напрашивается вопрос: зачем делать Highload на Битриксе? Давайте возьмем что-то полегче и побыстрее, да и “сами все сделаем”.

Этот вопрос требует понимания и техники, и экономики подобного проекта.

Чем хорош Битрикс для Highload-прототипа:

  • Быстрый запуск прототипа (пример довольно сложного проекта: 2 месяца, 600 часов работы, и функциональный прототип готов и запущен);

  • Готовые компоненты со стандартной и очень обширной логикой (торговый каталог, интернет-магазин со всеми скидками, комплектами, рассылкой и прочими прелестями);
    Меньше творчества – меньше ошибок.

  • Панель администратора, в которой есть все что может прийти в голову заказчику (а если без Битрикса, вам придется написать нечто в этом духе);
    Менеджеры и маркетологи не будут мучить разработчиков “обвесом” highload-проекта;

  • Существующая интеграция с 1С и CRM-платформой Битрикс24.

Что будет дальше, когда проект из прототипа перейдет в боевую эксплуатацию, и нагрузка вырастет в 100 раз? Битрикс справится?

Читайте дальше.

Прототип, итерации и организация процесса

Сначала надо сделать прототип. Все на стандартных механизмах, чтобы не тратить сил понапрасну и запуститься.

Структуру данных нужно продумывать сразу, но далеко от инфоблоков вы не уйдете.

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

Нагрузка растет постепенно.

Потом нужно оптимизировать программный код под структуру нагрузки именно вашего проекта.
Как – чуть дальше.

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

Принимая это решение, понимайте что трудозатраты на сопровождение и развитие на порядок выше, чем поддержка кода, основанного на стандартах Битрикса.

Потом… Потом постепенно окажется, что все сильно тормозящее в Битрикс-архитектуре вы оптимизировали и переделали, а вся красота и “буйство маркетинга” работает.

Вы спросите: а почему эти тормоза не устранили сами разработчики Битрикса?

Потому что тормоза у каждого свои.

“10 миллионов товаров”, “100 тысяч свойств с умными фильтрами” и “10 миллионов хитов в сутки” – требуют трех разных подходов к оптимизации.

Программисту: Оставьте Битриксу стандартное, займитесь решением нетривиальных задач.
Руководителю: Посчитайте деньги.

Как снизить требования к ресурсам в highload-проекте в 100 раз
17 “точек ада” в хайлоаде

На сайте бывают функции, бездумная реализация которых парализует highload-проект. Пользы от них 10%, а нагрузки 90%.

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

Для интернет-магазинов на Битриксе мы советуем:

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

  2. Не “показывать количество в категории”.
    Если вам это число позарез нужно, сделайте поле у категории, пересчитывайте агентом, и показывайте данные из этого поля.
    Денормализация – друг оптимизатора.

  3. Обойтись без конструктора скидок и попробовать не пользоваться несколькими типами цен.

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

  5. В настройках свойств не ставить галочку "Выводить на странице списка элементов поле для фильтрации по этому свойству".

  6. Использовать штатные свойств таблицы инфоблоков: Created by, ID, XML_ID и CODE вместо собственных свойств для связи сущностей.
    Эти свойства имеют встроенные индексы:
    KEY `ix_iblock_element_1` (`IBLOCK_ID`,`IBLOCK_SECTION_ID`),
    KEY `ix_iblock_element_4` (`IBLOCK_ID`,`XML_ID`,`WF_PARENT_ELEMENT_ID`),
    KEY `ix_iblock_element_3` (`WF_PARENT_ELEMENT_ID`),
    KEY `ix_iblock_element_code` (`IBLOCK_ID`,`CODE`)

  7. Не использовать пользовательские поля (UF) категорий.

  8. Не хранить большой объем текстовой информации в preview text и detail text, это делает одну строку таблицы элементов инфоблока легче и ускоряет выборки. Вынести поля описаний в таблицу свойств.
    Можно даже посоветовать написать обработчик события или агента, который будет чистить эти поля.

  9. Для полнотекстового поиска по сайту использовать sphinx. Он намного ускоряет поиск и снижает нагрузку. Правда, качество поиска не меняется.

  10. Делать индексы на все, по чему выполняется медленная сортировка или поиск. Да, и поменьше сортировок и поисков.
    Не стоит бездумно добавлять индексы “на все”. Включите логирование медленных запросов, анализируйте и добавляйте индексы.

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

  12. Постараться не допускать превышения 50 свойств в одном инфоблоке, чтобы использовать инфоблоки 2.0. Это позволит вынести свойства этого инфоблока в отдельную таблицу штатным переключателем.
    Во многих случаях это быстрее и удобнее.

  13. Свойства, по которым не выполняется фильтрация, объединяйте и храните в сериализованном виде. Кешируйте при выводе.

  14. При создании свойста типа “Строка” в mysql таблице создается поле типа “TEXT”, поэтому при поиске или сортировке по этому свойству необходимо вручную изменять тип поля на varchar и добавить индекс.

  15. При большом объеме данных умный фильтр будет работать только с фасетным индексом. Включайте фасетный поиск для умного и для обычного фильтра.

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

  17. Обсуждая любую “мелочь” на лице сайта, думайте какие запросы к базе данных она отправит, можно ли их закешировать надолго.

Нужно понимать как работает ваш и чужой код. Это позволить снизить нагрузку на ресурсы.
Многое из написанного выше применимо не только к Битриксу.

В следующей статье мы покажем как эти рекомендации снижают нагрузку в реальном проекте. Нагрузочное тестирование — в процессе.

Вывод

Highload на Битриксе делать можно.
Важно разбираться в технологиях и уметь считать деньги.

Вам может быть интересно:

Умный фильтр 1С-Битрикс

Оцените статью
18.07.2016
Понравилась статья?
Поделитесь ссылкой с друзьями и коллегами!

Статьи по теме

07.03.2023
Дорожная карта внедрения платформы автоматизации оптовых продаж Про построение эффективных отделов продаж написано много крутых статей. Одни эксперты готовы сделать это за 10 шагов, другие предлагают многоэтапную эволюц...
16.02.2023
Как начать B2B-продажи онлайн - особенности и методы оптовой торговли После пандемии рынок e-commerce начал стремительно расти. Мы говорим не только о B2C, но и о B2B-сегменте. Многие крупные компании уже разглядели потенциал...
10.01.2023
Как битриксоиды в React уходили Приятно познакомиться, мы битриксоиды. Да-да, те самые которые: вообще не модные, пишут НЕ на Laravel и Symfony, ...
10.01.2023
Товарная дистрибуция 30 лет спустя. Как программисты изменили продажи крупного бизнеса «Я думал, что буду строить банк, а на самом деле построил ИТ-компанию» Олег Тиньков, безработный Есть такая штука — товарная дистри...
10.01.2023
Как мы решили выпускать собственный продукт через CustDev и у нас получилось Собственный продукт как фиксация компетенции  В развитии крупных компаний-аутсорсеров наступает момент, когда они уже обросли опытом и компетенциями ...
19.12.2022
Учимся настраивать свою почту, не наступая на чужие грабли: Postfix + msmtp + сайт Привет, меня зовут Никита, я backend-разработчик в компании ИНТЕРВОЛГА. Работаю в компании уже 3 года, и за этот срок достаточно часто мне приходилось вози...

Мы работаем по одному из двух форматов:

  • аренда команды (от 2 человек, не менее 3 месяцев);
  • итерации с фиксированной ценой (1-3 месяца длительностью).

ИНТЕРВОЛГА предоставляет:

  • регулярные онлайн-планерки с заказчиком;
  • квалифицированных специалистов;
  • организованную команду (находятся в одном помещении, что упрощает решение рабочих вопросов);
  • полную прозрачность и регулярность отчетов о результатах.

Для доработок и развития мы предлагаем формат 100 часов в месяц. Что можно сделать за это время:

  • новые нетиповые страницы или раздел;
  • 2 отчета с индивидуальными настройками;
  • 3-5 веб-сервисов интеграции;
  • замудренный калькулятор и т.п.

Поддержка «чтобы все работало как часы» стоит 45 тысяч рублей в месяц и описана тут.

Хочешь получать лучшие статьи от INTERVOLGA раз в месяц?
Подпишись на рассылку — спамить не будем