Аудит производительности изнутри. Как самому научиться следить за производительностью сайта

Аудит производительности изнутри. Как самому научиться следить за производительностью сайта

Евгений ПотаповITSumma

Александр ЛыженковAero

Партнерская конференция «1С-Битрикс»

Евгений Потаповгенеральный директор компании ITSumma

• Круглосуточное администрирование и техническая поддержка

веб-сайтов

• На поддержке CarambaTV, Наше Радио, Aero, Бюро Пирогова,

ПостНаука, Marketium, Travelata, AlterGeo, Invisible, VseMayki,

AcademMedia

• 100 миллионов уникальных посетителей в сутки

• Штат – 50 человек

Партнерская конференция 2015

#bitrixconf2015

Александр Лыженковтехнический директор компании Aero Creative Agency

• Специализируемся на создании, поддержке и развитии

технологичных e-commerce проектов. Выводим крупнейшие

ритейл-бренды в онлайн.

• Среди наших клиентов: «Евросеть», «Мегафон-Ритейл», ЦУМ,

«ЦентрОбувь», «Технопарк», «Техносила», «АльфаСтрахование»,

СГ МСК, «1С», «Уральские авиалинии», Yota Devices, Forex Club.

• Постоянный штат – 20 человек


#bitrixconf2015

Типичные проблемы поддержки• Долгое время ответа веб-сайта.

• Критическое потребление ресурсов сервера (CPU, диски)

• Рост нагрузки при скачках посещаемости

• Проблемы при выкладке нового кода

• Проблемы с «железом»


#bitrixconf2015

Содержание• Когда пришло время делать аудит?

• Как проводить аудит? Какой есть инструментарий?

• Пример проведения аудита


#bitrixconf2015

Когда нужно делать аудит?два «полюса» в разработке

• Сначала все сделаем и «зарелизим», а там – посмотрим

• Заранее спланировать код так, чтобы он был высокопроизводительным


#bitrixconf2015


#bitrixconf2015

Сначала все сделаем…


#bitrixconf2015

…а там посмотрим


#bitrixconf2015

…А может детально проработать каждый момент?

«Быстро все сделаем»типичные проблемы

• Неоптимальный код на основе которого разработано много элементов сайта

• «Бомба замедленного действия» - неожиданное падение

производительности в процессе эксплуатации

• Плавное увеличение времени ответа с каждой новой «фичей»


#bitrixconf2015

Неоптимальный код на основе которого разработано много элементов сайта


#bitrixconf2015

Разработанная функциональность используется для

последующих доработок, и тогда, когда приходит

необходимость оптимизации кода – код уже очень не просто

изменить


#bitrixconf2015

«Бомба замедленного действия»Посещаемость выросла в 5 раз, а нагрузка на процессор – в 12


#bitrixconf2015

Время ответа незаметно увеличивается с каждой новой «фичей», пока не становится критическим

Как попытаться избежать проблем?Итеративный подход к аудиту

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

• Проводим аудит

• Дорабатываем самые «тормозные» моменты

• Разрабатываем дальше

• Проводим аудит


#bitrixconf2015

Аудит производительности – это не так сложно.

Состоит из:

• Аудита инфраструктуры

(Аудит серверного ПО и «железа», мониторинг)

• Аудита кода

(С использованием встроенного инструментария 1С-Битрикс)

• Аудита фронт-энда, скорость сайта

(Анализ времени загрузки страницы)


#bitrixconf2015

Аудит инфраструктурыКогда и как применять

• Цель – убедиться в том, что причина возможных проблем – не

«экосистема» сервера

• Чаще всего – в боевой эксплуатации.

• Часть 1: первичный анализ сервера

• Часть 2: мониторинг в течении продолжительного времени


#bitrixconf2015

Аудит инфраструктурыЧто анализируем? Факторы влияющие на время ответа сайта

• Специфика настройки веб-сервера.

• Нагрузка на процессор

• Нагрузка на дисковую подсистему

• Проблемы с работой базы данных

• Проблемы с сетевыми интерфейсами


#bitrixconf2015

Аудит инфраструктурыПервичный анализ.


#bitrixconf2015

• Какой хостинг использован?

Hetzner/FastVPS? Надо срочно проверить SMART состояние дисков.

• Каково значение TTL в DNS?

Оптимально <900 секунд. Больше – проблемы в случае срочного переезда.

Шаг 1. Анализ хостинга/DNS



#bitrixconf2015

• Какова частота процессора? Сколько ядер?

Если нужно быстро отдавать страницу пользователю – важна частота (>2.5 ггц)

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

число ядер (как минимум >=4)

Шаг 2. Анализ аппаратной конфигурации - Процессор



#bitrixconf2015

• Каков тип жестких дисков – SATA или SSD?

Есть возможность поставить SSD? Если да – запланировать использование SSD

для базы данных.

Шаг 3. Анализ аппаратной конфигурации – Жесткие диски



#bitrixconf2015

Шаг 4. Анализ ПО сервера. Инструменты – проверка системы



#bitrixconf2015

• Open files limit (https://rtcamp.com/tutorials/linux/increase-open-files-limit/)

• PHP – убедиться что есть opcache (apc/zend opcache)

• PHP – убедиться, что память опкэш-акселератора не заполнена

• Nginx+apache? Убедиться в том, что статика отдается с nginx

• Nginx+apache? Убедиться в том, что стоит оптимальное количество worker

• Только apache? Поставить nginx.

• PHP-FPM? Проверить лимиты max_children

Шаг 5. Анализ настроек операционной системы и веб-части

https://rtcamp.com/tutorials/linux/increase-open-files-limit/

https://rtcamp.com/tutorials/linux/increase-open-files-limit/



#bitrixconf2015

Шаг 6. Настройки – Производительность – Сервер БД



#bitrixconf2015

Шаг 7. Дополнительные настройки бд

• Какова версия MySQL? Минимум 5.1 идеально >=5.5

• Таблицы – обязательно InnoDB

• innodb_file_per_table должен быть включен.

• innodb-flush-log-at-trx-commit выставить в 2

• Сервер под нагрузкой? Если да - Посчитать рекомендуемый innodb_log_size

(http://www.percona.com/blog/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/)

http://www.percona.com/blog/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/

http://www.percona.com/blog/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/

Аудит инфраструктурыПервичный анализ. Bonus-track


#bitrixconf2015

• Убедиться в том, что создание бэкапов работает

• Убедиться в том, что бэкапы создаются на внешний сервер

• Убедиться в том, что из бэкапов можно восстановиться

• Убедиться в том, что на сервере есть RAID контроллер

• Убедиться в том, что массив не RAID-0

• Убедиться в том, что массив не находиться в аварийном состоянии

Аудит инфраструктурыМониторинг в течении 24-48 часов


#bitrixconf2015

• Время ответа страниц сайта

• Число запросов в секунду на веб-сервер

• Нагрузка на процессор/Load Average

• Нагрузка на дисковую подсистему

• Работа web-сервера

• Работа MySQL

Аудит инфраструктурыТипичные примеры «серверных проблем» – код не виноват1. Периодическая нагрузка создаваемая кроном или агентами


#bitrixconf2015

Проблема: «Сайт иногда работает очень медленно».



#bitrixconf2015

Число запросов при этом не растет.



#bitrixconf2015

Причина: бэкап в кроне, создающий высокую нагрузку на диск

Аудит инфраструктурыТипичные примеры «серверных проблем» – код не виноват2. Скорость на сетевом интерфейсе упирается в «потолок»


#bitrixconf2015

Новостной сайт. Проблема: резко замедляется скорость сайта при выходе новости.

Аудит инфраструктурыТипичные примеры «серверных проблем» – код не виноват2. Скорость на сетевом интерфейсе упирается в «потолок»


#bitrixconf2015

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

Аудит инфраструктурыТипичные примеры «серверных проблем» – код не виноват3. Хост-машина забирает ресурсы


#bitrixconf2015

Проблема: неожиданно начинает тормозить весь сервер

Аудит инфраструктурыТипичные примеры «серверных проблем» – код не виноват3. Хост-машина забирает ресурсы


#bitrixconf2015

Причина: виртуальный сервер с «прожорливыми соседями»

Аудит инфраструктурыСимптомы проблем в коде


#bitrixconf2015

Время ответа увеличилось в момент выкладки кода и осталось неизменным

Аудит инфраструктурыСимптомы проблем в коде


#bitrixconf2015

Время ответа в целом очень большое

Аудит кодаМетодика проведения

• Первичный анализ

монитор производительности на боевом сервере

• Изоляция проекта на «стенде»

Позволит провести анализ кода в ненагруженной экосистеме

• Постраничный поиск «долгих» компонентов + исследование кода

Детальный анализ самых медленных страниц


#bitrixconf2015

Аудит кодаПервичный анализ – монитор производительности на боевом сервере

• Цель: понять как работает сайт для большого числа пользователей

• Какие страницы/компоненты создают суммарно наибольшую

нагрузку на сервер

• Что можно оптимизировать в первую очередь, а что – впоследствии?


#bitrixconf2015

Аудит кодаПервичный анализ – монитор производительности на боевом сервере

• Убеждаемся что нет внешних причин для

«тормозов»

• Настройки – Настройки продукта – Настройки

модулей – Монитор производительности

• Вести журнал SQL запросов

• Сохранять стек вызова SQL запросов


#bitrixconf2015

Аудит кодаМонитор производительности - страницы

Позволяет найти:

• Страницы которые создают максимальную

нагрузку на процессор (если

оптимизировать – нагрузка на сервер будет

меньше)

• Страницы которые дольше всего грузятся

пользователю («скорость сайта» выше)


#bitrixconf2015

Аудит кодаМонитор производительности - страницы

Как включить:

• Фильтр – «+» - административный раздел

«нет»

• Для скорости загрузки страницы: страница-

время (среднее)

• Для снижения нагрузки на процессор

страница-время (сумма)


#bitrixconf2015

Аудит кодаМонитор производительности - компоненты


• Самые «тяжелые» компоненты

• Посмотреть самые тяжелые

запросы в них (перейдя по клику на

число запросов)

• Найти откуда запрос вызывается (в

разделе «SQL запросы»)


#bitrixconf2015

Аудит кодаМонитор производительности – SQL запросы


• Самые «тяжелые» запросы

• Компоненты, откуда они вызваны

• Непосредственное место вызова в

компонентах

• План выполнения запросов


#bitrixconf2015

Аудит кодаМонитор производительности – SQL запросы

Наведение мыши на SQL-запрос при

включенной в настройках Монитора

записи стэка вызовов покажет стек-

трейс вызова SQL запроса (места в

компоненте, откуда он вызывается)


#bitrixconf2015

Аудит кодаИзоляция кода на стенде


#bitrixconf2015

Цель: проверить работу кода на

ненагруженной инфраструктуре

• Отдельная виртуальная машина 1С-Битрикс

• Опционально: X-Windows с удобным

редактором кода

• Опционально: Установленный XHProf для

профилирования PHP

Аудит кодаИзоляция кода на стенде


#bitrixconf2015

• Rsync директории c 1С-Битрикс (и исключением

кэша, картинок и других больших файлов)

• Перенос БД

• До открытия сайта: переведение агентов на крон

SQL-запросом

• Ссылка на виртуальную машину (подробные

инструкции и больше материалов – позже)

www.itsumma.ru/bitrixtools

http://www.itsumma.ru/bitrixtools

http://www.itsumma.ru/bitrixtools

Аудит кодаПостраничный поиск долгих компонентов


#bitrixconf2015

Инструменты отладки

• Позволяет легко проанализировать

эффективность кэша

• Позволяют проанализировать структуру

выполнения компонентов на странице по

времени



#bitrixconf2015

Поиск неработающего кэша

• Обходим все основные страницы

• Сбрасываем кэш, но не отключаем его в

инструментах отладки

• Если кэш работает эффективно – время

работы страницы должно быть в

приемлемых значениях (как минимум

<1.0с) и ниже «некэшированной версии»



#bitrixconf2015

Поиск долгих компонентов


• Отключаем кэш в инструментах отладки

• Смотрим за структурой вызовов

компонентов



#bitrixconf2015

Поиск долгих компонентов


• Отключаем кэш в инструментах отладки

• Смотрим за структурой вызовов

компонентов

Аудит кодаXHProf


#bitrixconf2015

Детальный аудит PHP-кода

• Профилировщик от Facebook

• https://github.com/phacility/xhprof

• Удобная процедура исследования кода

• Стоит использовать для анализа кода, когда проблема

не на стороне долгого обращения к базе данных

https://github.com/phacility/xhprof

Пример аудитаnew.texenergo.ru


#bitrixconf2015



#bitrixconf2015



#bitrixconf2015



#bitrixconf2015



#bitrixconf2015



#bitrixconf2015



#bitrixconf2015

Шаг 1 – проверяем сервер

• Ставим сервер на мониторинг (24-48 часов)

• Ставим на мониторинг внешнее время ответа веб-

страниц сайта

• Смотрим все базовые настройки операционной системы

• Смотрим не «развалился» ли RAID, работают ли бэкапы



#bitrixconf2015

Шаг 2 – копируем проект на «стенд»

• Rsync кода

• Перенос БД

• Выключение агентов



#bitrixconf2015

Шаг 3 – включаем монитор

производительности на боевом сервере

• Вести журнал SQL вызовов

• Сохранять стек вызова SQL запросов

• Включить монитор на 30 минут

• Удалить ранее собранные данные



#bitrixconf2015

Шаг 4 – на стенде проверяем

работоспособность кэша

• Отладка – Суммарная статистика

• Отладка – Статистика SQL запросов

• Отладка – Статистика включаемых областей

• Отладка – Время исполнения страницы



#bitrixconf2015

Шаг 4 – выбираем часто используемые

страницы (на глаз или по данным монитора

производительности)

• Главная

• Специальные предложения

• Каталог

• Раздел каталога

• Элемент каталога



#bitrixconf2015

Шаг 4 – проверяем работоспособность кэша

для каждой выбранной страницы – Главная

• Выключаем кэш



#bitrixconf2015




• Обновляем страницу, смотрим время

исполнения



#bitrixconf2015




• Обновляем страницу, смотрим время

исполнения

• Включаем кэш, обновляем страницу,

смотрим время исполнения - работает



#bitrixconf2015


для каждой выбранной страницы –

Специальные предложения

Время ответа обновленной страницы с кэшом

не отличается от страницы без использования

кэша – кэш не работает.



#bitrixconf2015


для каждой выбранной страницы –

Специальные предложения

Время ответа обновленной страницы с кэшом

не отличается от страницы без использования

кэша – кэш не работает.



#bitrixconf2015

Шаг 5 – для проблемных страниц

анализируем причины неиспользования

кэша

• Идем в раздел «время создания страницы»



#bitrixconf2015



кэша


• Смотрим структуру вызова компонентов и

локализуем проблемный компонент



#bitrixconf2015



кэша




• Смотрим в шаблон/компонент и

локализуем причину



#bitrixconf2015



кэша








#bitrixconf2015



кэша








#bitrixconf2015



кэша








#bitrixconf2015

Шаг 6 – анализируем результаты монитора

производительности

• Раздел «Страницы»

• Суммарное время – нагрузка на сервер

• Среднее время – скорость сайта

• Имеет смысл оптимизировать главную

страницу сайта и страницу каталога



#bitrixconf2015

Шаг 6 – оптимизируем главную

• Смотрим время вызова компонентов



#bitrixconf2015

Шаг 6 – продолжаем анализ страниц


• Локализуем место долгой загрузки



#bitrixconf2015

Шаг 6 – продолжаем анализ страниц


• Локализуем место долгой загрузки

• Исследуем



#bitrixconf2015

Шаг 7 – анализируем проблемы с php-кодом

• Включаем XHProf

• Идем по пути вызова функций



#bitrixconf2015






#bitrixconf2015






#bitrixconf2015




Аудит new.texenergo.ruИтоги


#bitrixconf2015

Простой аудит, продолжительность – 2 рабочих дня

• Снижение времени ответа некэшированных страниц с 3-5 секунд до 0.5

секунд в среднем

• Ускорение повторно загруженных страниц до 0.25 секунд в среднем

• Скорость сайта: быстро

Аудит new.texenergo.ruПути развития процедуры аудита


#bitrixconf2015

• Максимальная автоматизация – постобработка результатов сбора

данных монитором производительности

(акцент на долгих страницах, сводка по проблемным местам в коде)

• Сводка по компонентам в которых не был использован кэш

• База знаний по стандартным проблемам связанным с

производительностью

Евгений Потапов

• http://itsumma.ru

• [email protected]

• http://facebook.com/eapotapov

http://itsumma.ru/bitrixtools


#bitrixconf2015

Александр Лыженков

• http://aeroidea.ru

• [email protected]

• http://www.facebook.com/a.lyzhenkov

http://itsumma.ru/

mailto:[email protected]

http://facebook.com/eapotapov

http://facebook.com/eapotapov

http://itsumma.ru/bitrixtools

http://aeroidea.ru/

http://aeroidea.ru/

http://aeroidea.ru/




https://www.facebook.com/a.lyzhenkov



Internet

Аудит производительности изнутри. Как самому научиться следить за производительностью сайта