Битрикс настолько сложная и большая система, что имеет свои особенности в работе практически во всех аспектах разработки и поддержки.
У каждого сайта есть свои требования к настройкам платформы, конфигурации и хостинга битрикс.
Из-за медленной загрузки сайта посетители могут с легкостью перейти на сайт конкурента, который загружается в разы быстрее.
Чтобы не происходило таких ситуаций, рассмотрим проблемы и решения, которые помогут ускорить работу сайта.
1. Проблемы с кэшированием
Кэширование каталога заключается в том, что так называемый «управляемый кэш» битрикса живет ровно до ближайшей записи. А после этого - стирается. Некоторые сайты работают достаточно активно, а изменения происходят почти непрерывно. Создается впечатление, что на сайте кэш отсутствует.
Варианты решения
Обновление кэша
Кэш нужно сбрасывать. Обновление сайта происходит довольно часто. И это отлично, так как при обновлении формируются свежие веб-ресурсы (URL). В данном случае они станут благополучно закэшированы у пользователей и провайдеров, и практически никаких дополнительных действий при обновлении веб-сайта не понадобится.
В случае если при обновлении веб-сайта изменяются уже разработанные файлы, появляется проблема кэширования: в коде сайта указаны ссылки на устаревшие ресурсы, а содержимое их видоизменилось. Пользователи обязаны получить свежее оглавление сайта по устаревшим ссылкам.
Чтобы преодолеть данную трудность — получения свежего содержания веб-ресурса по устаревшей ссылке — был введен механизм условного кэширования. В данном случае, браузер пользователя или же поисковый робот имеет возможность выслать особый HTTP-заголовок с датой последнего обновления файла или же хэшем последнего обновления. Сервер ответит, собственно что файл не поменялся (не пересылая содержимое файла), или же вышлет свежий файл (если файл был изменен впоследствии пришедшей даты или же хэш файла не совпадает с присланным).
Вроде все отлично, и устройство решает описанную делему обновления давних веб-ресурсов. Но данный механизм, к огорчению, довольно ресурсоемкий: он настоятельно просит запроса на сервер и любой запрос занимает некоторое количество (десятков) миллисекунд. В передовых критериях, когда для отражения странички потребуется сотни веб-ресурсов применения лишь только условного кэширования приводит к задержкам в сотни миллисекунд или же в том числе и секунд при отображении каждой интернет-страницы. Это неприемлемо.
Как раз по причине малой производительности условного кэширования более эффективной практикой считается строгий сброс кэша на всех промежуточных узлах сети, охватывая кэш браузера у конечного пользователя. Достигается это несколькими другими способами:
Смена физического имени файла. К примеру, main.css именуется main2015.css. В данном случае файл будет перезапрошен: для всех агентов это будет свежий файл. Стоит обозначить, что на сервере может быть настроен внутренний редирект: особая пометка в заглавии файла имеет возможность игнорироваться, и сервер станет выдавать иной физический файл. К примеру, при запросе main.v2015.css сервер вышлет содержимое файла main.css. В соответствии с этим, изменяя метку в шаблонах веб-сайта возможно достичь гарантированного сброса кэша у всех пользователей.
Изменение GET-строки после имени файла. К примеру, main.css вызвать как main.css. В данном случае, URL веб-ресурса поменяется и (почти) все агенты станут обязаны перезапросить файл. Но бывают исключения (для прокси-серверов), которые игнорируют GET-строку для статических файлов. Но для сайта маленькой или же средней посещаемости это не имеет большого значения.
2. Правильность выборки
Основная идея оптимизации в плане количества информации и кэширования, это выборка и сохранение в кэш только нужных данных, а не всех.
Выборка всех данных может потребовать большего времени и также заметно увеличить размер кэша.
Пример повышения производительности
1. Для получения элементов одного инфоблока нужно получить дополнительные свойства из другого, путем изменения шаблона или result modifier.
В таком случае это делается в цикле, но это не правильно. Такой цикл снижает производительность, созданием множеством запросов.
Правильный вариант - использовать один единственный запрос, в котором получаются данные для требуемых элементов.
2. Изменение основного API-вызова. Данные можно получить сразу.
3. Использование оптимального кода, который позволит сократить количество запросов.
4. Оптимизация размера кэша. Следует произвести анализ кэшируемых данных.
5. Кэширование только нужных данных. Ограничение результата работы компонента $arResult и установить ключи в SetResultCacheKeys.
Всегда минимизируйте запросы. Например, если в цикле идет запрос к элементу ИБ, то уже необходимо задуматься над минимизацией. Да, это займет больше времени, но вам скажут спасибо клиенты.
3. Композитный сайт
Технология «композитный сайт» – это усовершенствованная версия технологии html-кэширования веб-сайта. Не секрет, что высокая скорость загрузки способствует лучшему ранжированию веб-ресурса поисковыми системами.
Определение сайт, означает место, в котором располагается информация. Данная информация, делится на слои: HTML, изображения, CSS, Javaskript. HTML считается разметкой веб-сайта. Из полученных данных формируется образ страницы. HTML содержит данные о том, где какой элемент должен быть расположен. Параллельно c загрузкой HTML, с сервера загружаются и оставшиеся слои веб-сайта: CSS, Javaskript, изображения. Все это занимает конкретное время.
Данные композитного веб-сайта, в битриксе, именуются "статистическими данными", хранятся на сервере уже сформированными и для всех одинаковыми. То есть браузер загрузит страницу быстрее целиком из кэша, чем слоями. Таким образом, этап загрузки HTML сводится к минимуму.
Единственные данные которые могут различаться, это данные пользователя или те, которые быстро обновляются, для того чтобы оставлять их в кэше. Поэтому такие данные загружаются в фоновом режиме, при отображении HTML в браузере, и называются "динамическими данными".
Данная технология позволяет сайту буквально "парить", но только если не полениться настроить, так как это довольно просто.
Важно - эта технология не заменяет нормального кэширования компонентов. Работа будет в том случае, если кэш уже корректно настроено.
4. Правильная конфигурация сервера
1. Виртуальная машина, виртуальный хостинг, VPS/VDS
Виртуальный хостинг - это сервер, который разделен на аккаунты, делящих одни и те же IP-адреса и ресурсы.
VDS (virtual dedicated server) и VPS (virtual private server) - означают одно и то же.
VPS/VDS (виртуальный выделенный сервер) - это физический сервер, который поделен на несколько виртуальных серверов, имеющих свою ОС и может, независимо от других, быть перезагружен.
Таким образом, VPS/VDS лучше, чем виртуальный хостинг. Но в то же время имеет свои минусы и плюсы.
Минусы, например, заключаются в том, что настройки относительно сложные и цена в среднем выше, чем у виртуального хостинга. Однако, экономия на этом, не стоит того.
Плюсы же заключаются в большей стабильности, контроль над всеми процессами на VPS, настройкой ОС под свои нужды, root доступ к серверу.
2. Версии ПО на сервере
Битрикс разработан на языке программирования PHP и эффективно работает на любой платформе. База данных, которая используется на битрикс, называется MySQL.
Для ускорения времени генерации страницы, рекомендуется использование PHP версии 5.6 и выше (рекомендуемая версия PHP 7.1), и MySQL версии 5.0 и выше.
3. Оптимизатор PHP-кода
Для оптимизации PHP-кода, рекомендуется использовать расширение opcache (входит в комплект поставки PHP 5.5.0).
Данное расширение позволяет сохранять в памяти прекомпилированный байт-код скрипта. Каждый скрипт PHP преобразует понятный человеку код в код, который был бы ближе к машинному.
OpCache, делает это лишь только один раз — во время первого исполнения конкретного файла PHP. После этого прекомпилированный скрипт сохраняется в памяти, что должно привести к увеличению производительности.
4. Отладчик XDebug
XDebug - это средство профилирования и отладки PHP скриптов.
Данное расширение используется на серверах разработки. Позволяет выполнять профилировку приложения и находить те части, которые замедляют его работу.
В целом, расширение нужно, в первую очередь, для экономии времени программистов, так как позволяет быстро локализовать ошибку в коде.
Конечно, нет никакой необходимости использовать Xdebug, если ваш текущий инструментарий может обеспечить всё что он предоставляет, или если вам не нужны его возможности.
Если все таки XDebug используется, то не забывайте его выключать после запуска нового сайта, так как время выполнения кода замедляется.
5. Таблицы в MySQL
Таблицы составляют основу структуры базы данных MySQL. Таблицы содержат введенную в базу данных информацию и могут быть созданы для любых целей хранения данных.
MySQL поддерживает два различных типа таблиц: транзакционные и без поддержки транзакций. Для типовых задач используются транзакционные таблицы (InnoDB).
InnoDB — одна из выбираемых подсистем низкого уровня в СУБД MySQL, входит во все стандартные сборки для различных операционных систем. Основным отличием InnoDB от других подсистем низкого уровня MySQL является наличие механизма транзакций и внешних ключей.
В отличие от таблиц MyISAM, где для каждой таблицы создается один файл данных, данные InnoDB в настройках по умолчанию хранятся в больших совместно используемых файлах, что позволяет использовать постраничный кэш страниц базы данных. Формат данных InnoDB обеспечивает надежное хранение данных за счет транзакционности и блокировки данных на уровне строки.
InnoDB должен быть корректно настроен.
6. Корректность настройки InnoDB
Если использовать InnoDB таблицы, стоит установить максимально возможные значения для системы. Речь идет о размере buffer pool - внутреннем кэше MySQL. Буфер InnoDB кэширует и данные и индексы. Если размер данных не большой, а оперативной памяти предостаточно, то значение ключа стоит устанавливать в 70%...80% всей доступной памяти (с помощью этого кэшируются все данные).
7. Мониторинг работы сервера, проверка использования
Бывают моменты, что сайт перестает отвечать. Причиной тому является достижение предела дисковой подсистемы сервера.
Чтобы избежать данную проблему и выявить причину "торможения", нужен мониторинг работы сервера: использование дисковой подсистемы, пропускная способность сетевого интерфейса и CPU.