Быстродействие и нормальная работа сайтов является первостепенной задачей для многих людей, так или иначе связанных с бизнесом в сети. Наша компания с 2017 года предоставляет услугу «1С-Битрикс», которая подразумевает аудит продуктивности интернет-проектов. В аудите производится изучение настроек серверов, а также кода. Иными словами, происходит тщательное изучение компонентов для достижения максимальной скорости страниц ресурса.
Но прежде чем затрагивать перенастройку кодов, важно понять, от чего в принципе зависит скорость загрузки страниц, а соответственно производительность интернет-проекта. Существует множество видов решения проблем, но, к сожалению, присутствуют и ложные мнения, одним из которых является возможность ускорения загрузки сайта за счет оптимизации настроек либо сменой хостинга. На самом деле это помогает только при нескольких стандартных ошибках, но основными проблемами в большинстве случаев являются неоптимальные алгоритмы, настройки «1С-Битрикс» или трудности с кэшированием.
Все это можно объяснить достаточно легко: современные технологии уже достигли максимальной частоты ядра. Это значит, что в условиях наличия одного запроса на ядро процессора почти отсутствуют варианты ускорения выполнения задачи. Чаще всего у процессора на анализируемом сервере уже и так достаточно высокая частота, и при замене одного процессора на другой его скорость просто не увеличиться, тем более в два раза. Серверы хостинговых площадок, в большинстве своем, различаются количеством памяти и ядер, располагающихся на них.
Сложившуюся ситуацию можно сопоставить с кассами в любом супермаркете, когда касса может обработать конкретное количество покупок за конкретный промежуток времени. Если в момент покупки кассир будет вносить каждый пробиваемый код товара вручную, то его замена, конечно, может немного изменить ситуацию, но сама процедура не станет значительно быстрее. Отсюда следует, что нужно менять сам метод покупки. В случае работы с сайтами это означает необходимость оптимизации кода. Увеличение количества ядер и процессоров также можно сравнить с кассами, но в данном случае с их количеством. Несколько работающих касс могут обслужить значительно больше покупателей, но по отдельности каждый из клиентов все же будет недоволен.
Отсюда следует, что правильный и продуманный анализ производительности интернет-ресурса должен включить:
ü Анализ сервера, его мощностей и настроек (для того чтобы проанализировать работу самой системы, и если сам сервер работает медленно, то будет достаточно тяжело разобраться в том, что именно нужно оптимизировать);
ü Анализ алгоритмов проекта, работы страниц (с кэшированием или без), времени загрузки страниц;
ü Анализ загрузки проекта через браузер и оптимальности фронтенда.
Но не только сам анализ является важным аспектом настройки и оптимизации работы сайтов, а и понимание каждого шага. Именно поэтому нужно рассмотреть пункты более подробно.
Проверка серверных конфигураций
Прежде чем начинать проверку производительности, требуется проанализировать синхронизацию raid-массива, иными словами проверить зеркалирование жестких дисков и их наличие. Также важно изучить работу системы резервирования на наличие ошибок. К сожалению, достаточно часто встречается проблема одноразовой настройки резервного копирования и зеркалирования, то есть после проведения всех необходимых манипуляций проверка работоспособности больше не проводится. Это считается определенной проблемой, так как, согласно статистическим данным, резервирование выходит из строя приблизительно раз в месяц. Если не была проведена проверка бэкапа больше этого срока, то очень вероятно, что его просто больше нет. Затем проверяем производительность, которая состоит из конкретных и достаточно критичных элементов чеклиста:
ü Расположение ресурса на виртуальном хостинге виртуальной машины.
К большому сожалению, чаще всего виртуальный хостинг нацелен на продажу клиенту большего количества аппаратных мощностей, которые имеет в действительности. Вследствие этого наблюдается недостаток дисковой системы и процессорного времени в самые загруженные часы активности на ресурсах. Помимо единичных ситуаций, специалистами рекомендуется использование так называемого выделенного сервера на физической аппаратной базе для проекта e-commerce. Разница в цене на виртуальный и реальный сервер может отличаться в десятки раз. Но именно эта экономия действительно не стоит вероятной угрозы, которая может появится в связи с проблемами на хостинге.
ü Информация о версиях ПО на сервере.
В данный момент по апгрейду специалистами рекомендуются PHP и MySQL версий до 5.5. Тем не менее, важно заметить, проблемы ресурса изначально связаны с кодом, то обновление PHP не будет способствовать ускорению активности загрузки сайта. Если же в коде отсутствуют ошибки и он поддерживает переход, то обновление PHP до версий 5.5 и выше, может способствовать ускорению загрузки страницы приблизительно на 25%. В случае совместимости проекта с PHP7 будет наблюдаться двукратное увеличение скорости загрузки ресурса на уровне PHP. Стоит акцентировать внимание, что если страница загружается за 2000 мс, из которых почти 1800 мс – это запросы к БД, то даже использование PHP7 с его возможностями не приведет к значительному улучшению ситуации, а скорость генерации увеличится все лишь на 100 мс. Это означает, что время ответа страницы будет составлять не 2000 мс, как было изначально задумано, а 1900 мс. Время, затрачиваемое на работу с БЗ, даже при смене версии PHP не улучшится.
ü Наличие оптимизатора PHP-кодов.
В настоящее время стандартным оптимизатором PHP считается opcache. Этого оптимизатор настоятельно рекомендуется использовать, конечно, помимо абсолютно уникальных случаев. За счет прекомпиляции кода, осуществляющейся при помощи оптимизатора, ускоряется обработка скриптов приблизительно на 85%. Оптимизатор преобразует PHP-код в байт-код, считающийся более схожим с машинным. При применении оптимизатора такое преобразование становится одноразовой манипуляцией, а в случае отсутствия PHP преобразование возможно при запросе пользователя.
ü Отладчик XDebug.
Данный отладчик считается достаточно популярным модулем у разработчиков и предназначается для отладки кода. Разумеется, его удобно, а главное полезно применять на практике в работе с серверами, но, к сожалению, на работающих сайтах отладчик может заметно замедлять работу кода. Такая ситуация наблюдается часто, особенно при запуске новых сайтов, потому как он остается активным после срочной отладки. Отсюда можно сделать один простой, но очень важный вывод: отладчик XDebug нужно отключать.
ü Анализ engine таблиц в MySQL.
Несмотря на то, что еще с 2016 года MyISAM является устаревшим «движком» таблиц, специалисты даже сейчас могут обнаружить его на современных ресурсах. Возможно, дело связано с переносом таблиц с, использующейся во время разработки, БД, где разновидность двигателя не играет особой роли. А, возможно, создатели и разработчики не сконцентрировали на этом внимание. Для типовых задач настоятельно рекомендуется использование InnoDB и его последователей. Конечно, MyISAM по структуре не очень отличается от файлов формата dbf, который не подходит для применения в многопользовательской сфере. MyISAM достаточно часто подвергается блокировкам на табличном уровне, когда происходит блокировка одного запроса ресурсом всех остальных. Также MyISAM максимально чувствителен к различным изменениям MySQL, которые могут привести к утрате информации и тем более тяжело поддается резервированию, в результате чего при копировании габаритной таблицы может стать следствием блокировки интернет-ресурса. Вышеперечисленных проблем в InnoDB просто нет, но при работе с ним важна его корректная настройка.
ü Правильная настройка InnoDB.
Изначально речь пойдет о внутреннем кэше MySQL. При небольшом объеме данных и необходимой величине оперативной памяти, специалистами рекомендуется проведение вставки кэша выше директории с информацией. Таким образом будет происходить кэширование всех данных находящихся под buffer pool. При проверке хорошо выручают инструменты Persona Tools.
ü Анализ работы сервера и проверка swap.
Оптимизация будет неэффективна, если сервер регулярно подвергается колоссальным нагрузкам из-за с наплыва клиентов или же недостатка памяти для процессов, часть которых перемещена в swap. Swap является файлом, работающим от жесткого диска, который медлительней чем оперативная память. Помимо этого, чаще всего процессы невероятно активно "едят оперативку", поэтому при переносе на диск, подсистема мгновенно зашкаливает и ресурс просто прекращает отвечать. На любом сайте, в обязательном порядке, должен быть внедрен мониторинг, потому что в момент остановки работы сайта важно четко понять, что именно стало тому причиной. Основными причинами так и считаются чрезмерное обращение к дисковой подсистеме, недостатка мощности процессора или же израсходование пропускной способности интерфейса сети.
Проверка кода ресурса
После того как были проверены предыдущие возможные проблемы и ничего не изменилось, следует перейти к анализу кода. Чаще всего может случиться так, что даже в грамотно созданном проекте могут отсутствовать ошибки в коде. Но, опираясь на опыт специалистов, проблема появляется не из-за одноразовой ошибки, а из-за ряда произведенных преобразований, каждое из которых привело к небольшому, но замедлению работы ресурса, и в сумме все эти притормаживания привели к огромной задержке.
Перед тем, как заниматься поиском проблем в коде, необходимо четко определиться с инструментами, которые будут использоваться для этих задач. А также важно заранее определиться со степенью применения этих инструментов и информацией, которую они будут предоставлять при их использовании.
Для проведения изначального поиска задерживающих мест на сайте используется мониторинг продуктивности 1С-Битрикс. С его помощью можно обнаружить самые популярные из задерживающихся страниц, ускорение которых приведет к внушительному уменьшению загрузки сервера. Если же обойти вниманием популярные страницы и сконцентрироваться только на скорости генерации, можно зациклиться на разгоне страницы, к которой обращаются крайне редко, при этом нагрузка на сервисе так и будет зашкаливать, а скорость загрузок совершенно не изменится.
Монитор производительности можно включить при помощи кнопки тестирования. Для этого необходимо:
ü «Настройки»;
ü «Панель производительности»;
ü «Тестировать производительность».
Как видно, найти ее достаточно просто. По завершению сбора необходимых сведений во вкладке «Разработка» будет предоставлена таблица, в которой будет выведена информация о всех помещенных страницах и времени их загрузки.
После выбора долгих страниц на отдельно взятом сервере и, конечно, при условии владения информацией о его мощности и не загруженности происходит анализ времени создания страниц в отладке. Важно акцентироваться на загрузке отдельных составляющих и анализе кода страниц. В первых интеграциях проверяется работоспособность страниц с применением кэша, а в дальнейших – без его использования. Часто страницы, открывающиеся достаточно быстро с применением кэширования, без него загружаются в среднем за 45-50 секунд. Кажется, что отсутствие кэша на редко посещаемых страницах не является большой проблемой, но поисковый бот, пришедший в каталог, перегружает сервер и попросту игнорирует подобные страницы.
Отладка запускается со страницы ресурса:
ü На панели администратора «Отладка»;
ü В следующем меню выбирается «Суммарная статистика».
При необходимости тестирования работоспособности кэша требуется также отмечать для выбора пункт «Детальная статистика кэша».
Разумеется, существуют случаи, когда полученной информации недостаточно. Такая ситуация наблюдается, когда определенные отрезки кода не отображаются при отладке или же когда существует необходимость дательного изучения формирования вызовов PHP. В этом случае необходимо дополнительное подключение к модулю профилирования XHProf. Он предоставит отслеживать время реализации не только скрипта PHP, но и вложенного функционала.
К примеру, можно проанализировать отладку и работу программы XHProf на странице с разделами поэтапно. Проблема кроется в активном кэшировании, компонент которого реализуется достаточно медленно.
ü Первый этап: концентрация на том, что компонент подвергается кэшированию и при этом реализуется невероятно медленно. Помимо этого, запросы выполняются, ориентировочно, за 15% от продолжительности реализации компонента. Сразу заметно присутствие ошибки в самом воспроизведении компонента.
ü Второй этап: отладка PHP происходит с использованием XHProf. Требуется обернуть необходимый компонент в код утилиты.
ü Третий этап: обновление анализируемой страницы для того, чтобы утилита смогла собрать необходимые данные.
ü Четвертый этап: открытие страницы с данными, собранными утилитой.
ü Пятый этап: необходимо найти подключение компонента и открыть его. Выполнение шаблона Bitrix:catalog.section происходит за 1,5 сек., что является основной частью времени загрузки страницы.
ü Шестой этап: по стеклу выводов необходимо найти обращение к скрипту, а при дальнейшем продвижении можно обнаружить пользовательскую функцию выполнения запросов.
ü В результате получаются данные о том, что именно надстройка скрипта и есть той самой причиной медленной загрузки. После исправления этой ошибки кода решается и длительная загрузка страницы с разделами каталога.
Проверка конфигураций «1С-Битрикс»
Ошибочная структурная организация информационных блоков является одной из самых распространенных проблем, которая встречается более чем 85% все существующих проектов. Она связана с сосредоточением всех товаров в одном информационном блоке. Такой блок накапливает огромный объем свойств всех, занесенных в него товаров, что в дальнейшем может привести к колоссальным выработкам и замедленному импорту. Можно проанализировать подобную ситуацию на примере магазина спортинвентаря, имеющего в своем каталоге одежду, принадлежности для горнолыжного и велосипедного спорта, при этом весь представленный товар обладает собственными свойствами. Все свойства наименований переносят в один информационных блок, в результате велосипедам предоставляются свойства лыж и одежды и наоборот. Можно только представить, какое количество лишних свойств накапливается в случае наличия множества категорий наименований у одного магазина.
Также можно обнаружить проблему, когда у проекта относительно продуманная структура блоков, но, при этом, было множество агрегирующих выборок в виде новинок, хитов и акционных предложений. В результате получалось, что помимо одного запроса в блок направлялось более 50, а после этого отмечалось их слияние в коде. В связи с этим компонент сам по себе стал работать достаточно медленно. Поэтому, в случае необходимости в такой функциональности, нужно разрабатывать дополнительные решения в виде создания отдельной таблицы в БД или внешнюю агрегацию.
Самописные компоненты также могут являться проблемой при необходимости ускорения загрузки страниц. Такая ситуация может часто наблюдаться, когда разработчики или веб-студии прибегают к помощи, сторонних компонентов, которые не задействуют внутренние резервы платформы 1С-Битрикс. К примеру, самописными фильтрами не используются фасетные индексы, что существенно увеличивает временной интервал выполнения компонента. Также случается так, что программисты просто не изучают внедряемый компонент и не замечают возникающие вследствие этого ошибки и проблемы. Поэтому специалисты советуют проводить основательный анализ устанавливаемых компонентов.
Существуют трудности с внешними серверами, которые никак не контактируют с кодом 1С-Битрикс, но, к сожалению, встречаются у большинства людей. Многие ресурсы используют внешние серверы для задействования вспомогательного функционала на проекте:
ü Курс валют;
ü Подсчет сроков и тарифов доставки заказов и другое.
Когда такой сервер начинает «тормозить» и долго обрабатываться, может наблюдаться аналогичная проблема и на самом сайте. К большому сожалению, долгие ответы внешних серверов — это достаточно распространенная проблема. Вероятным решением такой проблемы может стать своевременная загрузка сведений через cron, и лучше всего, если все это будет проделываться в самые загруженные часы для сайта. Когда внешний сервер "притормаживает" — "подвисает" загрузка и самого сайта. Большинство современных внешних сервисов всегда "тормозят" при загрузке. Вероятное решение — периодическое обновление информации через cron, и лучше, чтобы это случалось в "свободное" время работы ресурса, то есть когда активность на нем незначительная.
Ошибки задействования фасетных индексов
Ошибки работы с фасетными индексами возникают при их не задействовании в умном фильтре. Чаще всего это несознательна ошибка, а обычный недосмотр. Такие индексы просто необходимо применять потому, что они максимально ускоряют действия разумного фильтра, за счет чего происходит снижение загрузки процессора и уменьшение времени генерации страниц. При использовании новых функций фасетный индекс целесообразно перенастраивать, но такие действия при пике активности на сайте, может спровоцировать циклический процесс. Это связано с тем, что при отключении индекса, нагрузка на сервер будет достигать критичных размеров, вследствие чего пересоздать фасет будет невозможно. Единственным разумным решением проблемы является перестройка индексов в моменты минимальных нагрузок.
Ошибочное использование API 1С-Битрикс
В API 1С-Битрикс присутствует множество функций, которые оптимальны при нагрузках на сервер. Разработчикам важно знать и понимать эти функции, а главное уметь их правильно применять. Самой распространенной ошибкой является, к примеру, получение определенного списка товаров, а в дальнейшем их свойств в цикле, когда все необходимое можно получить из основного запроса. Соответственно, получив 200 товаров, дополнительно создается 200 запросов к БД для сбора данных о свойствах. Так же не нужно выбирать товары для их дальнейшего подсчета, потому что в API 1С-Битрикс присутствует вся необходимая для этого функциональная начинка. Поразительным наблюдением является то, что часто выбираются товары, подсчет которых необходимо произвести по какому-либо определенному свойству.
Неправильное использование или настройка меню
Формирование меню или подсчет количества элементов к категориям также может стать определенной проблемой в преобладающем большинстве проектов. Опираясь на количество элементов и происходит построение вышеупомянутой области. Для того чтобы оптимизировать скорость работы ресурса, не рекомендуется использование данной информации.
Также достаточно часто можно встретить проблемы с обновленным меню. Например, разработчики не заметили, что меню не подвергается кэшированию и выводу шаблона, и создали меню, в содержание которого входит самые популярные наименования из каждой категории. Следствием такой ошибки является то, что при осмотре клиентом меню на каждый его выбор формируются запросы к БД, что в дальнейшем замедляет работу всего проекта. API 1С-Битрикс в свою очередь реализует такой функционал через включение специальных компонентов параллельно с элементами в result_modifier.php.
Сетевой антивирус
Сетевой антивирус проверяет страницы ресурсов на наличие вредоносного контента, который мог быть внедрен в следствии взлома или модификаций страниц. Несмотря на видимую полезность этой функции, обычно специалистами рекомендуется отключать такой модуль, оставив, при этом, функционирующим модуль проактивной защиты. Деактивация антивируса способствует увеличению скорости загрузки страниц приблизительно на 100-200 мс.
Ошибочно активированный модуль компрессии
Модуль компрессии используется для хостинговых платформ, в которых невозможно включить компрессию на уровне веб-мастера. Чаще всего такая проблема встречается на достаточно старых shared-хостингах. При наличии возможности включения хостинга специалисты рекомендуют отключать данный модуль вручную.
Используемые агенты на хитах
Еще одна функциональность, которую можно встретить на проектах - это агенты, выполняющиеся на хитах. Они регулярно выполняют задания в Битрикс либо через привычный cron или же внутри кода, который был вызван пользователем при запросе. В данном режиме Битрикс проверяет каждый запрос пользователя на наличие регулярных процедур, которые требуют выполнить, к примеру, рассылку. Если же сработало время, то 1С-Битрикс осуществляет эту задачу. Проблема в том, что весь период выполнения заданных действий пользователь не сможет получить данные со страницы, а если еще и в настройках сервера внедрены определенные лимиты на время активности скрипта, то такой агент не реализуется, а рассылка не будет совершена. Агенты создавались для площадок, на которых можно запрограммировать регулярное выполнение агентов cron. К сожалению, на данный момент таких площадок сохранилось предельно мало, поэтому от агентов на хитах лучше всего отказаться.
Ошибки работы с кэшем
При многих проверках можно столкнуться с ситуацией отключения кэширования в целях отладки, которое после проведения необходимых манипуляций больше не активизировалось. Также бывают случаи, когда при проверке можно обнаружить некэшируемые элементы на странице. Трудность кроется в том, что после обращения к страницам, необходимый файл кэша формировался, а при последующих уже отсутствовал. Результатом таких исчезновений может быть счетчик на просмотры наименований в клише компонента, который и заносил преобразования в информационных блок при обновлении, что уничтожало кэш.
В некоторых самописных компонентах можно встретить занесение слишком большого объема выборки информации. В кэше Битрикс располагается сериализованный массив. На случай, если величина одной сущности, находящейся в кэше, увеличивается более чем заданный в системе объем, накладные траты на перенос сведений из кэша интегрировались, экономя обращения к БЗ.
Композитный кэш
Трудности с композитным кэшем также могут замедлять быстродействие отзыва страницы, но, несмотря на это, он является достаточно удобной технологией. К сожалению, несмотря на хорошую идею, ее часто используют неправильно. Самая обычная, но распространенная ошибка — это сохранение ограничений на кэш с заданным по умолчание объемом в 100 мб.
Достаточно часто за счет разработки дополнительно внедряется новый небольшой компонент, который не поддерживает композит. Из-за этого, сам композит на страницах «слетает». Нужно тщательно следить за его работой.
Проверка клиентского сегмента
Данная проверка заключается в нескольких шагах, к которым относятся:
ü Неоптимизированные изображения – это означает лучше использовать сжатые изображения, так как чем меньше картинка весит, тем быстрее она грузится.
ü Трудности с JS/CSS файлами – эта проблема заключается в подключении нестандартных или необъединенных для Битрикса файлов.
ü Статистика, отдаваемая сетевым сервером Apache – это проблема возникает из-за раздачи динамики, вследствие чего запрос может создавать дополнительное использование памяти и загруженности процессора.
ü Отсутствие компрессии на уроне сетевого сервера – эта проблема заключается к игнорированию необходимости отдачи статистики с gzip-компрессией.
Выводы
В последнее время наблюдается то, что поисковики стали штрафовать медленные ресурсы позициями выдачи, соответственно, пользователи перестают их посещать. Чтобы избежать таких проблем, рекомендуется задействовать ресурсы хостинга и платформы 1С-Битрикс максимально продуманно для того, чтобы получить высококачественный проект. После проверки всех вышеуказанных проблем и их решения можно наблюдать значительное увеличение скорости загрузки сайтов.
В случае отсутствия необходимых знаний для настройки у обычных пользователей настоятельно рекомендуется обращаться за помощью к специалистам для того, чтобы не усугубить ситуацию. Часто именно из-за необдуманных поступков можно наблюдать блокировки сайтов или прекращение их активности.Назад в раздел
