Немного теории
Даже если сайт создан по всем стандартам и рекомендациям, рано или поздно, на нем возникают проблемы с производительностью. С ростом нагрузки на аппаратное обеспечение сервера, растет и время обработки входящих HTTP-запросов и частота отказов (ошибки семейства 5хх).
Работы с производительностью можно разделить на два вида: поиск и устранение причин замедления. В платформе «1С-Битрикс: Управление сайтом» есть как устоявшиеся практики, так и готовые инструменты для обеих задач.
Поиск проблем производительности
Первый готовый инструмент для разработчика — Проверка системы. Вы уже познакомились с ней в одном из предыдущих уроков. Возьмите за правило в случае любой нештатной ситуации первым делом запускать эту проверку. И хотя, в первую очередь, он помогает находить ошибки в коде и логике сайта, они могут влиять и на производительность. Эта быстрая проверка избавит вас от многих примитивных, но неприятных проблем.
Второй инструмент — режим отладки сайта в публичной части. С его помощью разработчик (и администратор) может увидеть важнейшие показатели, влияющие на скорость загрузки текущей страницы:
- Количество SQL-запросов (каждого компонента и суммарно на странице).
- Время выполнения каждого SQL-запроса.
- Текст каждого SQL-запроса.
- Стек вызова каждого SQL-запроса.
- Объем кеша (каждого компонента и суммарно на странице).
- Время выполнения каждого компонента и PHP-кода на странице/в шаблоне.
Если разработчику заранее известно, в каких разделах есть проблемы с производительностью и он может самостоятельно воспроизвести их, то исследовать страницу в режиме отладки — правильный следующий шаг после общей проверки системы.
Но не делайте выводы по одному замеру. Сделайте несколько, в том числе и со сброшенным кешем. И не считайте кеш панацеей. Если при наличии кеша компонент отрабатывает мгновенно, а при отсутствии — за 10 секунд, то проблема с производительностью есть, пусть и не такая острая.
Также помните, что отладка в публичной части сайта показывает проблемы только для текущего пользователя, только на конкретной странице и в конкретный момент времени. У пользователя с другим набором прав в другое время дня могут быть совершенно другие показатели.
Ошибки, которые проще всего обнаружить именно этим способом:
- Долгие неэффективные SQL-запросы в компонентах (содержащие LIKE, полный обход таблицы без индексов, выборка всех данных по ошибке с “пустым” фильтром).
- Лишние SQL-запросы, которые можно устранить или объединить несколько запросов в один.
- Отсутствие кеша компонента или его неэффективное использование (формально кеш есть, но и SQL-запросы все равно оказываются нужны).
- Неэффективная работа кода самого компонента (результат SQL-запроса сортируется/пересчитывается силами PHP).
Третий инструмент «Панель производительности» даст наиболее полную картину производительности сайта. Информация в панели разбита на несколько вкладок.
Конфигурация
На этой вкладке собраны все аппаратные показатели и приведены их эталонные значения. На основе этих данных можно сделать выводы о скорости работы дисков, конфигурации PHP и процессоре. Измерение этих показателей занимает меньше минуты.Битрикс
На этой вкладке собраны проверки настроек платформы. По всем обнаруженным проблемам Панель производительности рекомендует тематические справочные материалы и конкретные действия. Это верхнеуровневые общие проверки, надо понимать, что не всегда отсутствие ошибок на этой вкладке означает идеальную производительность сайта. И наоборот, отличная производительность может быть достигнута даже с замечаниями на этой вкладке.Разработка
На этой вкладке собраны рекомендации по самым медленным страницам и компонентам на них.Масштабирование
На этой вкладке можно провести нагрузочный тест любой страницы сайта и увидеть, как деградирует время генерации страницы при росте количества одновременных HTTP-запросов.
Также в «Панели производительности» и из настроек модуля «Монитор производительности» можно запустить полный тест производительности. Это переведет сайт на ограниченное время в особый режим работы, при котором все страницы, компоненты и SQL-запросы для всех пользователей сохраняются в журнале тестирования.
Тест производительности можно запустить максимум на 1 час, если необходимо полное логирование активности и на 1 неделю, если установлена опция «Записывать только медленные SQL запросы».
Собранные за время теста данные анализируются автоматически в «Панели производительности» (там выводятся проблемы 20 самых нагружающих страниц). Опытный разработчик может исследовать записи самостоятельно на следующих страницах административного раздела:
- Настройки > Производительность > Страницы.
- Настройки > Производительность > Хиты.
- Настройки > Производительность > Компоненты.
- Настройки > Производительность > Запросы SQL.
Рекомендуем после сбора данных теста производительности посмотреть сохраненные SQL-запросы, отсортированные по убыванию времени выполнения. Часто именно в этом месте обнаруживаются проблемы производительности (LIKE-запросы или обращения к таблицам, которые вовсе не нужны).
Также полезными в мониторинге работы сайта и поиске причин медленной работы будут распространенные общие инструменты веб-разработки:
- Xhprof.
- Xdebug.
- Munin.
- Nagios.
- Zabbix.
Решение проблем производительности
Каждая обнаруженная проблема производительности может быть решена разными способами с разным эффектом. Расскажем о самых популярных и эффективных.
Кеширование и Композитный сайт
Это самый быстрый способ решить проблему с производительностью “прямо сейчас”. Мы подробно останавливались на нюансах кеширования ранее, но дополним предыдущие советы важным примечанием. Если в незнакомом для вас проекте полностью отключено кеширование, его включение (действие “в лоб”) может быть неправильным решением.
Код самописных компонентов (и даже result_modifier.php в шаблоне стандартных компонентов) может быть написан так, что включение кеширования мгновенно сломает бизнес-логику, заложенную предыдущим разработчиком, который по какой-то причине решил, что кешированием пользоваться тут не стоит. Поэтому прежде стоит изучить компонент.
Это правило распространяется на глобальную настройку “Автокеширование компонентов” и на режим кеширования компонентов. В редких случаях системное кеширование действительно стоит отключать — если ему разработана грамотная замена.
И напомним, что какой бы быстрой ни была работа компонента с актуальным кешем, это не должно быть единственным средством обеспечения высокой производительности сайта. Даже без кеша работа компонентов должна выполняться с достаточной скоростью. Относитесь к кешированию компонентов, как к последнему средству, которое призвано поднять скорость хорошо оптимизированного сайта до максимума. Использовать кеширование вместо рассматриваемых далее вариантов оптимизации — неправильно.
Технологию “Композитный сайт” надо применять для оптимизации с аналогичными оговорками. Разумеется, это подводит нас к разговору о более серьезных технических решениях, принимаемых при разработке сайта.
Оптимизация хранения данных
Правильный выбор СУБД и ее структуры — залог удачной оптимизации и изящных технических решений. Платформа «1С-Битрикс: Управление сайтом» предоставляет большинство таблиц БД для сущностей готовыми, но выбрать все за разработчика невозможно. Например, именно разработчик выбирает, как хранить данные собственных сущностей (об этом мы говорили ранее в этом курсе — о выборе между Инфоблоком, HL-блоком и собственной таблицей БД).
Если анализ производительности выявил проблему с скоростью работы Инфоблока и другие средства испробованы — рассмотрите вариант перенести данные из Инфоблока в HL-блок или сразу в свою таблицу СУБД. В предыдущих уроках мы обозначали основные различия между способами хранения данных и повторим главную мысль здесь снова: чем “ниже” уровень решения в техническом плане, тем больше контроля и ответственности у вас появляется. Данные из собственной таблицы не попадают в поисковый индекс, не проверяют при работе права пользователя, не имеют готовых компонентов, но позволяют разработчику управлять даже типом колонок в таблице БД.
Иногда в погоне за производительностью команды могут решиться не только на смену хранилища данных, но и на переезд в другую СУБД, например PostgreSQL, который устроен иначе, чем MySQL и может больше подходить для решаемой задачи.
Кроме смены хранилища и переезда в другую СУБД эффективным может быть и менее радикальное решение — например, реорганизация таблиц. Анализируя SQL-запросы и устройство компонентов медленного сайта составьте структуру базы данных (например, в нотации ER) и решите для себя — годится ли такая структура для потребностей пользователей сайта. Частое следствие постоянных итераций доработок сайта без единого технического задания — едва ли не полное противоречие между структурой БД и функциями сайта. Возможно, какие-то таблицы можно объединить, какие-то разделить, какие-то транспонировать.
Оптимизация запросов
Если вопросов к хранению данных нет, но SQL-запросы все равно выполняются медленно, стоит присмотреться к тому, что и как они делают.
Частая причина медленной скорости SQL-запроса — LIKE-выборка там, где разработчику на самом деле нужна была эквивалентность. Чтобы не допускать таких ошибок, повторите синтаксис getList-методов.
Также лишнюю нагрузку могут давать запросы в цикле. Эти проблемы также можно решить, “насмотренностью” хороших решений и повышая культуру кода — один такой случай мы покажем в видео к этому уроку. Заменяйте запросы в цикле на один пакетный запрос или даже полностью избавляйтесь от них, задействуя JOIN.
Но, как и любое решение в отдельности, JOIN — не серебряная пуля для любой проблемы. Более того, в MySQL есть лимит на количество JOIN в SQL-запросе.
Если в запросе не видно LIKE-сравнения, нет лишних JOIN’ов, но он все равно работает медленнее, чем вы ждете, то самый простой способ понять, что не так с запросом — попросить СУБД показать план исполнения (ключевое слово EXPLAIN).
EXPLAIN покажет, какие операции будут выполнены для поиска искомых строк, какие таблицы и индексы будут использоваться. Разработчик может самостоятельно принимать решение об оптимизации запроса или может довериться инструменту «Анализ индексов», который подскажет, по каким столбцам имеет смысл создать индексы.
Индексы — низкоуровневый механизм СУБД. Правильный индекс может повысить скорость SELECT-запроса в десятки раз, но всегда помните о побочных эффектах от создания индексов.
Во-первых, появляются накладные расходы при INSERT и UPDATE-запросах на обновление индексов. И чем больше индексов — тем медленнее будут выполняться такие запросы.
Во-вторых, индексы будут занимать место на диске.
Практика
Одним из основополагающих критериев хорошего сайта как для пользователя, так и для владельца является его производительность. По мере разрастания ваш сайт может начать тормозить и долго открывать запрашиваемые страницы. В особо тяжелых случаях запрос вообще может не успеть обрабатываться. Тогда пользователь увидит 504-ую ошибку о превышении максимального времени ожидания ответа от сервера.
Вообще задумываться о производительности кода, который вы пишите, нужно сразу, еще на этапе разработки. Но бывает и так, что замедление скорости работы сайта проявляется не сразу, а со временем. О том, каким образом можно отследить просадку в скорости и как повысить производительность мы и расскажем в этом уроке.
Первое, с чего мы начнём – это знакомство с режимом отладки в панели управления сайтом.
Производительность
30 мин