Оптимизация mysql bitrix

Статьи

Перед внесением изменений остановите MySQL командой servicemysql stop.

innodb_flush_method= O_DIRECT
table_open_cache = 1200
transaction-isolation = READ-COMMITTED
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 8M
innodb_log_file_size = 32M

После изменения запускаем сервер service mysql start

innodb_flush_method — отключает двойную буферизацию mysql и операционной системы

table_open_cache — количество кэшированных открытых таблиц для всех потоков. Данное значение возможно потребуется увеличить (зависит от нагрузки и от используемой редакции для сайта)

transaction-isolation — уровень изоляции транзакций

innodb_flush_log_at_trx_commit — отменяет сброс данных на диск при каждой транзакции (ощутимое ускорение работы).

innodb_log_buffer_size — размер буфера лога, рекомендуемый размер 8Мб

innodb_log_file_size — максимальный размер одного лог-файла. Увеличение размера улучшит производительность, но и увеличит время восстановления данных. Рекомендуемый диапазон от 32 до 512 Мб

Возврат к списку

ИНТЕРВОЛГА – компетентный веб-интегратор.
Веб-интеграция это создание крупных информационных веб-систем, глубоко интегрированных в бизнес Заказчика. Это снижение затрат на работу с клиентами, рост продаж и автоматизация процессов.

Мы можем решить все задачи веб-интеграции собственными силами. Большинство наших проектов – комплексные, интеграционные.

Наш принцип: приносить пользу бизнесу клиента за счет осмысленного применения веб-технологий.

Ключевая компетенция веб-интегратора: создание сложных и хорошо работающих веб-проектов.

Сегодняшняя статья – об ускорении работы нагруженного интернет-магазина.

Этот интернет-магазин – mybox.ru. Внутри – 1C-Битрикс. Почитать об архитектуре проекта.

Сначала несколько слов о Битриксе

Есть два лагеря, между которыми – пламя войны.

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

Лишь малая доля веб-разработчиков думает не штампами, а головой. Например – мы.

Профессионалы понимают, что тиражируемый софт и промышленная разработка это не то же самое что “команда одного проекта”. Мы знаем для чего подходит Битрикс и почему он такой.

При этом мы не идеализируем платформу. Мы знаем о стольких странностях Битрикса, что людям “снаружи” и не снилось.

В каждом крупном проекте – Евраз, MYBOX, Альфа, многочисленные “Уберы маркетплейсов” – мы думаем “черт возьми, причем тут Битрикс!? Тут же все нетиповое!”. Каждый раз мы начинаем проект и осознанно делаем его на Битриксе.

Я понимаю что люди по ту стороны пламени войны сейчас скажут “мыши плакали, кололись, но продолжали жрать кактус”. Но – это неправда.

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

В статье — реальный кейс ускорения работы сайта на Битрикс, объемом в 3000+ часов и пример оптимизации его работы.

Кто пациент? Что умеет сайт mybox. ru?

Mybox.ru – сайт, highload проект на Битрикс, где можно заказать суши и другие блюда азиатской кухни в 100+ городах.

Сайт показывает доступность блюд в 250+ точках выдачи. Статусы заказов обновляются через веб-сервисы 2 раза в минуту. Обновление наличия товаров и меню идет почти непрерывно. На сайте делается ежедневно более 1000 заказов, в месяц – несколько десятков тысяч.

Ну хорошо, а нагрузка?

Утром (когда заказов почти нет) в минуту бывает около 35 хитов. Мало.

Днем в 14-00 по Москве (восточные регионы начинают активно работать) в минуту сайт обрабатывает 220 запросов. Уже не так мало.

Вечером — когда поток заказов максимальный — в минуту около 500 хитов.

Вечером в праздник (например 8 марта) обычный показатель перекрывается в 2-2.5 раза.

Итого до 1300 хитов в минуту. Это 22 хита в секунду.

Нагрузка эта – от покупателей, без признаков хакерских DDOS-атак, неумелого парсинга, буйных ботов Яндекса и всего такого.

Со временем сайт стал работать заметно медленнее. Особенно на некоторых страницах. В данных мусора нет, посещаемость здоровая, конверсия – обзавидуешься.

Ясно, что причины “тормозов” надо искать в коде и в обработке данных.

Начнем с истории.

Скорость работы после старта

Сайт был разработан нами и выпущен осенью 2015 года. После сдачи сайт был проверен на скорость – все было в пределах нормы.

Что такое норма?

Лирическое отступление: в частных беседах сотрудники 1С-Битрикс говорят что сайт должен “без кеша” отдавать любую страницу за 0.1-0.5 секунды и это они считают нормой.

При этом сайт Битрикса контентные страницы отдает за 0.2-0.3 с, а страницу отфильтрованного списка партнеров — сначала за 0.8 с, потом за 0.25 с.

Штатная “мерилка” Битрикса (серверное + в браузере) помечает любое время свыше 1 с – “не быстро”.

Разумно считать около 0.5 секунды  серверного времени – допустимой нормой.

Иногда прямо в договоре на запуск сайта мы записываем требования к скорости работы и “на выходе” проводим нагрузочное тестирование: Яндекс. Танк + Munin, Nagios + штатные инструменты Битрикса.

На момент старта сайт был “бодрячком”: среднее время генерации страниц составляло около 0.3 секунды.

И через год расширения сети и развития сайта

За год посещаемость, число точек и городов выросли процентов на 30.

База данных имеет стандартную для Битрикса структуру – инфоблоки (товары, SKU, маркетинговый контент), немного хайлоадблоков. Данных немало: например, в инфоблоке SKU (“наличие по точкам”) хранится более 400 тысяч записей.

Кроме того, сайт хранит более 6 миллионов записей – позиций ранее сделанных заказов. Каждый раз когда сайт обращается к истории заказов, выполняет операции с корзинами – этот объем записей затрагивается.

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

За год на сайт было добавлено много новых функций. Вот неполный список:

Выросла и нагрузка. Сайт перестал быть “бодрячком”. Перед нами встал вопрос — как увеличить скорость загрузки сайта.

По самым продающим и самым нагруженным страницам время за год сильно выросло (на графике показано серверное время).

В сентябре 2016 года мы начали оптимизацию. Результаты видны на графике, далее — подробности.

Оптимизация скорости работы сайта, снижение нагрузки на сервер

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

Дальше много специальных терминов! Если вы не понимаете языка программистов, сразу читайте выводы и результаты.

Симптомы

Хозяйке на заметку: Даже если вы не специалист в веб-разработке, для определения медленно работающих частей сайта прекрасно подходит штатный монитор производительности Битрикса и его инструменты “Страницы”, “Хиты”, “SQL-запросы”. Запустите мониторинг на 20-60 минут и посмотрите статистику. Все как на ладони.

Выяснилось что узкое место — медленные запросы базы данных. Мы отобрали 500 самых долгих запросов, выбрали и сгруппировали по типам:

Вы спросите: как так вышло? Ответ прост:

Важно время от времени наводить порядок.

Еще вопрос: как при таких показателях вообще удавалось работать?

Нужно похвалить кеширование Битрикса: большинство медленных запросов работали редко.

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

А может сервер посильней?

Очевидная мысль — для ускорение работы сайта мало ресурсов, давайте добавим.

Но мы решили этого не делать до наведения порядка в коде. Добавлять мощности — значит консервировать проблему. Да и Антон Гойхман, ИТ-директор сети, совершенно разумно отказался “тушить пожар бензином”.

Сайт работает на обычном виртуальном сервере на SSD.

Сервер соответствует требованиям Битрикса, поэтому начинать надо не с него.
Мы нашли и устранили кучу мест “потери скорости”. Первая группа проблем называется

Ошибки программистов

API Битрикса – инструмент. Инструмент непростой. С его помощью очень легко написать такой код, который будет логически верен, но крайне непроизводителен. И требуется квалификация “сильно выше средней”  чтобы это найти и исправить быстро и изящно.

Логически это допустимо: если XML_ID уникален, то проблем нет.

В огромном учебном курсе Битрикса “разработчик на bitrix framework” этот момент четко не описан.

Эта не бросающаяся в глаза особенности стиля кодирования здорово тормозила многие запросы.

SQL в цикле вместо более сложной, но быстрой методики получения данных

Пример: Больное место — result_modifier компонента catalog.section.

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

В коде страницы каталога каждой коробки-вока в коде узнавали ее состав с помощью метода getBoxProductItems (в самом методе еще 2 раза вызывается Getlist по компонентам коробочек). Затем опять делали запрос для получения значения свойства. Все это для того чтобы узнать с чем коробка.

Работает, но неоптимально. Код избыточен.

Добавили интересующее нас свойство в параметр DISPLAY_PROPERTIES, собрали ID-записей и разом получили необходимые нам значения.

Результат: Ускорение этого логического блока в сотни раз.

Запросы с пустой фильтрацией

Фильтры при отборах иногда формируются по сложной логике “в пару экранов кода”.

Завершается все это getlist’ом.

При исследованиях мы нашли несколько случаев, когда фильтр оказывался пустым. Getlist считает это вариантом нормы и срабатывает запрос вида «выбери мне все элементы всех инфоблоков».

Совет: при больших (или даже при любых) объемах данных проверяйте, не пустой ли у вас фильтр.

Повторный запрос тех же данных

В проект вложено примерно 3400 часов работы, участвовало много людей, и порой следующий программист писал в result_modifier примерно то же, что уже делалось в компоненте, с чуть измененной под новую логику структурой данных.

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

Результат – накопилось вот такое: если на странице выводилось 50 товаров, то для каждого товара выполнялся запрос, определяющий текущий тип цены, одинаковый у всех.

Отсутствие нужных индексов на нагружающие запросы select

Пример: при работе с товарами наиболее часто производятся выборки по городу.

Город в нашей структуре данных — свойство инфоблока товарных предложений. Получается “запрос через 2 ступени”: товар-предложение-город. Запросы сложные, данных много, все тормозит.

Для ускорения сайта на Битрикс, сконвертировали в Инфоблоки 2.0 и добавили индекс на поле “город”.

Еще пример: довольно много данных хранится в highload-блоках, например расширенные профили покупателей — сотни тысяч записей, по которым часто ведется поиск и отбор.

Проанализировав запросы, мы добавили индексы почти на все highload-блоки.

Следующая группа проблем интереснее.

Неоптимальная работа стандартных компонентов и страниц Битрикса

Что необходимо дорабатывать

GetOffersArray используемый в компоненте Catalog. Section

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

Делает он это довольно странным образом.

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

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

Работа со свойствами элементов инфоблока в компонентах

Стандартные компоненты каталога делают “лишние” для нас операции при извлечении свойств товаров.

В идеале хочется чтобы свойства доставались в одном запросе вместе с элементами, но в стандартных компонентах свойства достаются отдельно, причем опять же довольно странно.

Чем больше свойств нам надо получить, тем медленнее метод работает.

В каталоге нам требуется всего 12 свойств, для интернет-магазина это не много.

На скриншоте профилировщика XHprof видно, что вызовы методов получения свойств (внешние) занимают очень много времени.

Следите за руками.

В методе GetPropertyValuesArray мы (в смысле код Битрикса) получаем значения всех активных свойств, причем двумя отдельными запросами: сначала список существующих свойств,

затем сами значения для выбранных элементов каталога

Далее если свойство имеет тип свойства “привязка” и свойство указано в параметре PROPERTY_CODE идет получение привязанного элемента, причем запросом в цикле (метод GetDisplayValue).

Время затраченное на исполнение функции GetDisplayValue

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

Тогда этот связанный элемент не будет извлекаться из базы без толку.

Удивительная страница sale_buyers. php

На малых данных все отлично, а на больших — нет.

Она генерирует такой вот запрос:

Любители пописать SQL-запросы спросят — почему бы сумму и число заказов не получить одним подзапросом, а не двумя одинаковыми? Причина известна: так работает автоматический построитель запросов на основе настраиваемого визуального представления.

И черт с этим, проблема не в двух запросах вместо одного.

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

Пришлось сообщить в техподдержку и временно заблокировать эту страницу.

Update: Трудами сотрудников компании Битрикс Дениса Шаромова и Николая Рыжонина пример 20+ — минутного запроса был стремительно исследован, в продукт внесены изменения, которые придут с обновлениями. Ждем.

Результаты оптимизации

После переработки структуры данных, оптимизации запросов и кода (нашего и Битриксового), при той же (и даже растущей нагрузке) не осталось запросов, которые бы исполнялись более 0.2 секунды (условия измерения те же — 500 самых нагружающих запросов вечером).

Сравните результаты “до и после”. Среднее время нагружающих запросов:

Даже самые тяжелые страницы теперь отдаются менее чем за 0.4 секунды (напомню, при 10+ хитах в секунду).

Сайт снова стал бодрячком.

Осталось еще одно “место потери времени” – проблемы клиентская оптимизация, работы в браузере.

Ей мы займемся в ближайшее время.

На диаграмме внизу зеленое — серверное время, синее – время на клиенте, в браузере.

Выводы

Универсальность Битрикса, гибкость инфоблоков и буйство фантазии заказчика позволяет многим веб-разработчикам забыть, как платформа устроена внутри. Забыть про уровень протокола, сессий, индексов, таймаутов.

А забывать не надо.

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

И если в простых случаях можно программировать “спинным мозгом”, то нагруженный проект не позволит этого.

Затраты времени на рефакторинг составили около 60 часов.

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

Важно как компания работает над ними.

Вам может быть интересно:
Топ проблем сайтов на Битриксе из аудитов ИНТЕРВОЛГИ

За последние три года мы оптимизировали производительность многих проектов на 1С-Битрикс. Среди них были как новые сайты, которые размещались на хостинге впервые, так и проекты, перенесённые с других хостингов и корпоративных серверов.

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

На какой результат можно рассчитывать?

Если пройти эти шаги последовательно, то можно увеличить производительность даже очень медленных сайтов, которые показывают 20-30 пунктов по шкале Битрикс, до 100 пунктов и выше.

С помощью правильных настроек вполне реально сделать так, чтобы “тормозной” сайт стал “летать” и радовать посетителей удобством и высокой скоростью.

Итак, вот 14 шагов для оптимизации сайта на 1С-Битрикс:

Рассмотрим каждый из этих шагов подробнее.

Подобрать более мощное железо на хостинге

Производительность сайта зависит от серверных мощностей – количества ядер и частоты процессора, объёма оперативной памяти, типа и ёмкости дисков.

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

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

Для сайтов компаний и интернет-магазинов с небольшой посещаемостью будет достаточно 1-2 ядер процессора, 2 Гб оперативной памяти и до 30 Гб на SSD-диске. Эта конфигурация подойдет и для тех, кто только запустил сайт и ещё не замерил нагрузку от посещаемости.

Если же ваш сайт достаточно “тяжёлый”, понадобится больше ресурсов. Так, для сайтов с высокой посещаемостью, а также интернет-магазинов с большим каталогом товаров или порталов, например, Битрикс24, мы рекомендуем использовать тариф “MIDDLE” с 4 ядрами процессора, 4 Гб RAM и 80 Гб на SSD-диске.

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

После усиления или оптимизации “железа” переходим к настройке окружения и самого сайта.

Использовать специализированное серверное окружение Битрикс

Мы рекомендуем использовать на хостинге специализированное окружение – виртуальную машину BitrixVM, рекомендованную разработчиками платформы 1С-Битрикс.

Что даёт использование специализированного окружения?

«1C-Битрикс: Виртуальная машина» – это виртуальный сервер, полностью настроенный, протестированный и предназначенный для оптимальной работы с сайтами на «1С-Битрикс».

В нём уже учтены многие параметры, влияющие на производительность. Набор ПО и связка веб-сервисов уже настроена, чтобы обеспечить оптимальную работу сайта на 1С-Битрикс или портала Битрикс24.

Если же вы не используете окружение Битрикс, а самостоятельно конфигурируете среду на своём VPS-сервере, обратите внимание на режим использования php как модуль apache. Эту опцию вы увидите в настройках и можете использовать её для ускорения работы Битрикс. При этом есть много нюансов, так как при высокой нагрузке предпочтительным окажется другой режим, и придётся привлекать специалиста.

Поэтому для удобства и скорости развёртывания мы рекомендуем использовать готовое и многократно протестированное окружение BitrixVM. Мы используем его для всех клиентских проектов на платформе Битрикс.

Обновить версию PHP до 7

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

Нужно проверить версию PHP и обновить её до 7.x, т.к. новые версии работают быстрее.

Когда основа серверной части настроена, пора переходить к настройкам, которые делаются из админ-панели 1С-Битрикс.

Минимизировать скрипты и стили

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

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

Очень важно учесть момент подключения файлов скриптов и стилей, они должны быть подключены следующим образом:

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

Уже только это может дать ощутимое ускорение загрузки страниц сайта.

Сжать изображения

Основным «тяжелым» ресурсом на веб-странице являются изображения. Чем больше их вес, тем медленнее загружается страница.

Для Битрикса существует отличное бесплатное решение для оптимизации изображений без потери качества. Работает оно буквально в один клик.

Часто веб-мастера упускают оптимизацию изображений, а зря. Нам приходилось встречать сайты, где в плейсхолдеры 300х400 пикселей вставлены картинки размером 1200х1600.

Представьте, насколько медленно грузится такой интернет-магазин, если в его каталоге 40 тысяч товаров.

Отложить загрузку медиа-контента

Что пользователю важнее увидеть в первую очередь: красивые картинки или основной контент сайта? Картинки, безусловно, важны, но лучше первым делом показать структуру и контент. Для решения этой задачи можете воспользоваться плагином JQuery Lazy. Для его работы также необходимо использовать библиотеку JQuery.

Подключение плагина в шаблоне сайта

Инициализация плагина для выбранного класса изображений

Изображениям необходимо добавить выбранный класс .lazy-img, а также заменить атрибут src на data-src

Для решения проблемы с изображениями являющимися background-ом, вместо css свойства background: url(/images/cloud.jpg) следует добавить класс .lazy-img и атрибут data-src для блока

Настроить время жизни кеша

Эта настройка определяет частоту обновления информации на странице.

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

Этот параметр важно учитывать и выставлять с учётом периода реального обновления информации на сервере.

Проверить, что подключён механизм кеширования memcached

Memcached – это сервис кэширования данных в оперативной памяти на основе хеш-таблицы. Это самый быстрый способ кеширования, так как ОС при наличии ресурсов будет держать последние открытые файлы в памяти. Поэтому убедитесь, что он подключён.

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

Подключить CDN

Битрикс предоставляет возможность использовать технологию CDN (Content Delivery Network), которая позволяет загружать картинки, стили и скрипты с сервера, находящегося ближе всего к пользователю. Это увеличивает скорость загрузки всей страницы.

Для включения данной опции необходимо перейти в Настройки — Облако 1С-Битрикс — Ускорение сайта (CDN).

После включения CDN произведите замер скорости загрузки для исключения противоположного эффекта.

В Также в панели есть инструмент измерения скорости загрузки отклика сайта. Он измеряет скорость загрузки сайта у посетителей.

Этот тест показывает четыре зоны — “Очень быстро”, “Быстро”, “Медленно” и “Очень медленно”, а также среднее время загрузки. Рассчитывается для 1000 последних посетителей вашего сайта. Скорость сайта фактически показывает, как быстро отобразился ваш сайт для большинства из этих 1000 посетителей.

Также можно тестировать скорость загрузки и с помощью сервиса

или с помощью средств разработчика в одном из современных браузеров.

Оптимизировать настройки БД

В настройках БД важно проверить несколько параметров.

Настроить тип таблиц

Если мы говорим про современные проекты, которые переносим с других серверов, проверьте, что тип таблиц в базе – InnoDB.

Сайты с этим типом таблиц работают быстрее и надёжнее с точки зрения сохранности данных. Это соответствует рекомендациям Битрикс.

Настроить параметр buffer pool size

Общая рекомендация — проверять и выставлять innodb buffer pool size примерно равным объёму БД.

В шаблоне BitrixVM он настраивается автоматически в зависимости от объема оперативной памяти на сервере.

Создать фасетные индексы

Данный механизм позволяет сэкономить время на выдаче результата запроса.

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

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

Включить композитный режим работы сайта

Заходим в панель управления сайтом. Переходим в раздел

Нажимаем «Включить композит»

Также нужно установить время жизни кэша сутки (86400 сек), так как 120 секунд ухудшат производительность.

Включаем настройки nginx для композитного сайта через утилиту командной строки

/opt/webdir/bin/bx-sites -o json -a composite —enable —site=default

(вместо default, если нужно, вписываем имя требуемого сайта)

Для отключения, соответственно:

/opt/webdir/bin/bx-sites -o json -a composite —disable —site=default

Отключить лишние модули

В Битриксе есть модули, которые не все используют.  Они включены по умолчанию, но нужны далеко не каждому сайту.

К ним можно отнести AD/LDAP интеграцию, Push and Pull, Wiki, А/B-тестирование, Веб-аналитику, Веб-кластер, Веб-мессенджер, Веб-сервисы, Дизайнер бизнес-процессов, Документооборот, Календарь событий, Конструктор отчетов, Менеджер идей, Мобильную платформу, Мобильное приложение для интернет-магазина, Обучение, Перевод, Почту, Техподдержку, Универсальные списки, Управление масштабированием, а также модуль интеграции с “Битрикс24”. Все они отрицательно влияют на производительность. Поэтому неиспользуемые модули важно отключить.

Другой пример такого модуля – “Сайты24”, который позволяет быстро создавать простые сайты на 1С-Битрикс без веб-разработчика. Его тоже можно отключить, чтобы ускорить работу основного сайта.

Отследить медленные запросы и узкие места в структуре сайта и БД

Часто к нам обращаются клиенты с такой проблемой: начал тормозить сайт, который до этого работал хорошо.

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

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

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

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

Что-то из этого можно увидеть в админке Битрикса самостоятельно, включив отслеживание производительности и не обращаясь к инженерам. Это поможет понять, какие изменения на сайте или в логике его работы приводят к таким тормозящим запросам.

В панели производительности есть возможность посмотреть на показатели и проанализировать детально скорость загрузки страниц.

Несколько вариантов конфига mysql, где включить логирование:

Рекомендуется включить режим диагностики и походить по своему сайту. Битрикс фиксирует это в диагностическом модуле и показывает, что вызвало задержки. Также можно посмотреть самые частые и самые медленные запросы к БД. И на основе этих данных решить, что можно оптимизировать в коде сайта.

На какой прирост производительности можно рассчитывать?

При отключении неиспользуемых модулей можно сразу получить прирост производительности в 10-20 пунктов.

Оптимизация запросов MySQL может дать очень много в зависимости от самих запросов. Если сайт работал совсем медленно, показывая индекс 20-30, то после ликвидации медленного запроса индекс может подняться до 100 пунктов.

Вот один из примеров:

Заказчик обратился к нам с интернет-магазином автозапчастей с большим каталогом. Сайт открывался очень медленно. Посмотрели производительность по страницам.

Главная открывалась быстро, переход по разделам тоже. А при открытии карточек товаров сайт начинал тормозить. Так, страница с товаром загружалась  25-30 секунд. Посмотрели на сервере – особенной нагрузки при этом не было.

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

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

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

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

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

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

Использовать масштабируемый кластер серверов без покупки дорогостоящего решения

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

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

Конечно, есть коробочное решение – пакет Битрикс Enterprise, который позволяет размещать сайты на нескольких серверах, чтобы справляться с высокой нагрузкой. Но это решение очень дорогостоящее, стоимостью в сотни тысяч рублей. Заказчик пока не рассматривал такие инвестиции.

Поэтому мы предложили создать простую версию масштабируемого кластера без необходимости покупать дорогую лицензию.

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

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

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

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

Двойной эффект от ускорения сайта

Увеличение скорости работы сайта имеет двойной эффект.

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

И во-вторых, как отмечают многие из наших клиентов, ускорение загрузки страниц сайта повышает его позиции в поисковой выдаче Google и Яндекс. А это уже прямая коммерческая выгода.

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

Если у вас есть что добавить к этим способам или вы захотите поделиться своими – напишите в комментариях. Будет полезно всем, кто работает в этом направлении.

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

Вы можете выполнить перенос самостоятельно или обратиться к нашим специалистам. Все подробности можно найти в статье Перенос сайта на сервер

После переноса сайта можно приступить к настройке CMS.

Откройте файл в текстовом редакторе, например, nano:

Если nano отсутствует, можно установить его командой yum install nano либо использовать имеющийся на сервере редактор (например,

Задайте следующие параметры:

# количество одновременных подключений (по умолчанию 1024)MAXCONN = «1024»# объем выделяемой памяти для кэша (по умолчанию 64MB)CACHESIZE=»1024″# количество потоков memcachedOPTIONS=»-t 4″

systemctl restart memcached.service

укажите корректное значение для вашей системы.

Укажите в файле следующие параметры:

Укажите в нем следующие параметры:

Обратите внимание, что некорректная настройка memcached может негативно влиять на показатели производительности. Если вы наблюдаете снижение индекса производительности, можно поэкспериментировать со значениями в конфигурационном файле , который настраивался на шаге 5.

Для этого выполните следующие действия:

9.1. Создайте папку для хранения временных файлов, например,

9.2. Измените владельца папки и группу на mysql:

chown mysql:mysql /var/lib/mysql/tmp

9.3. Определите идентификатор пользователя (uid) и группы (gid) mysql:

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

tmpfs /var/lib/mysql/tmp tmpfs rw,gid=27,uid=27,size=1G,nr_inodes=10k,mode=0700 0 0

Параметр size необходимо установить в зависимости от количества имеющейся оперативной памяти.

9.5. Примонтируйте новый tmpfs-раздел:

9.6. В файл конфигурации MySQL

systemctl restart mysqld

innodb_flush_log_at_trx_commit = 0

Данный параметр позволит использовать отложенные транзакции.