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

• О чем речь вообще? Что такое высоконагруженные проекты?
• Хайлоад в Битрикс-проектах. Цифры
• Решения проблемы высокой нагрузки
• Битрикс или “что-то другое”?
• Прототип, итерации и организация процесса
• Как снизить требования к ресурсам в highload-проекте в 100 раз 17 “точек ада” в хайлоаде
• Вывод

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Автоматизированное тестирование и поддержка сайта 24/7

• "Черная пятница" для Вашего сервера

• Автоматический функциональный мониторинг

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

Если товаров в интернет-магазине до 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С-Битрикс