Стоимость SPA-продедур

Алексей Андросов, Яндекс.Почта

Стоимость SPA-продедур

Алексей Андросов, Яндекс.Почта

У меня все тормозит!!11

Методология

  1. Собери факты
  2. Проанализируйте факты
  3. Постройте теорию
  4. Поменяйте один!!!! участок кода
  5. Проверьте теорию

Вам не нужны статьи
“10 советов…“

Вам нужны инструменты!

Без инструментов

Сколько стоит SPA-услуга

Собираем факты

В идеале нужно уметь измерять любой сценарий пользователя “от клика до реакции на это действие”.

Для этого пригодится единый API “сделай что-то и перерисуй страницу”.

Что нужно мерить

Что нужно мерить

Каждую стадию и общее время надо измерять отдельно. Если общее время считать как сумму микро-метрик, то вы рискуете потерять что-то важное.

Если общее время и сумма метрик не совпадает, значит у вас не считается какая-та стадия.

А теперь посчитаем среднее!

 

 

Медиана

Медиана – это серединное, а не среднее значение в выборке. Если у нас имеются числа 1, 2, 2, 3, 8, 10, 20, то медиана – 3, а среднее – 6,5.

Она хорошо отсекает слишком плохие или слишком хорошие данные.

Процентиль

Строим график по группам. Например

 

А еще хорошо следить за клиентом

Как отслеживать клиента

Случайно генерируем ключ, который выдается при загрузке SPA и идентифицирует его сессию (session_id).

Его надо пробрасывать во всех запросах во все бекенды.

В каждый запрос еще можно добавлять ID(request_id).

Зачем все это надо?!

  1. Отличаем действия вкладки/браузера/устройства одного пользователя.
  2. Легко отследить всю цепочку браузера->бекенд1->бекенд2->бекендN->БД.
  3. Легко собрать всю сессию пользователя и понять что пошло не так.

Анализ

Анализ и построение теории

Во-первых, надо четко понимать какие цифры вы считаете хорошими, а какие плохими.

Вот страница рисует за 500мс. Это хорошо или плохо? А если я потрачу день и будет 450мс?

У каждой оптимизации есть стоимость!

Анализ и построение теории

Хорошая цель: список рисуется за 100мс у 90% клиентов

Как искать проблему?

Профайлер вам не поможет!

Профайлер вам не поможет!

Профилировать запуск обновления SPA, в котором были сделаны десятки тысяч вызовов JS-функций немного сложновато…

Туда неизбежно попадут внутрении вызовы фреймворка, о которых вы ничего не знаете и не контроллируете.

А еще проблема в том, что сложно отследить к какому именно блоку относятся вызовы.

Как искать проблему?

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

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

Как искать проблему?

Не ленитесь и потратьте 10 минут времени на написание скрипта, который выполнит нужный вам сценарий действий.

Это сэкономит вам часы безтолкового кликанья по кнопкам и снятия метрик.

А еще даст возможность запускать этот сценари сколько угодно раз!

Инструменты в популярных фреймворках

Что не надо оптимизировать?

Микрооптимизации в реальных приложениях почти никогда ничего не дают.

Оптимизируйте то, что реально тормозит, а не то, что вы думаете, что тормозит!

Поставьте пределы

Например, не стоит делать оптимизацию, если она будет меньше 20мс или 10%.

Я хочу вас уберечь от бессмысленного проведения дня на jsperf и слов “Я тут заменил везде forEach на for и теперь все работает на целых 5мс быстрее!”

Немного советов

Как мерить микрооптимизации

Иногда видно, что происходит тысячи вызовов микрофункции и это занимает много времени.

Как же померить ее скорость?

Как мерить микрооптимизации

  1. Проверить скорость разных варинтов реализации на jsperf.com
  2. Проверить в разных браузерах!
  3. В своем приложении измеряем через performance.now()

Как мерить микрооптимизации

var sum = 0; function myFn() {    var start = performance.now();    callMicroFn();    var end = performance.now();    sum += (end - start);

Оптимизация методом замедления

WAT??

Очень часто надо оптимизировать небольшие элементы страницы. Скажем, по 10мс каждый.

Если вы случайно сделаете 9мc, то не поймете это погрешность или оптимизация.

Замедлеяем элементы

Техника очень простая - сделайте одно и тоже действие много раз.

Например, вместо 20 элементов коллекции отрисуйте 200 или 1000.

Единичный элемент страницы - это просто коллекция с одним элементом :)

Замедлеяем элементы

Важно понимать, что скорость должна увеличиваться как минимум линейно.

Если это не так, то большой список не отрисуется никогда.

 

Замедлеяем элементы

Допустим, у нас есть стадии:

  1. Подготовка
  2. Шаблонизация
  3. Выполнение callback

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

Закончили анализы

Что получили?

У нас есть метрики и мы нашли возможное место, которое тормозит.

Мы его даже как-то оптимизировали. Как проверить?

Проверяем теорию

Только не на локалке!!1

Проблемы локалки

  1. Нечестное окружение
  2. Влияние несжатого или нескомплированного кода (JIT, инлайниг)
  3. В дев-окружении обычно больше логов
  4. У вашего соседа будут другие результаты
  5. Завтра вы не сможете повторить свой же результат

Что нужно делать на локалке?

Нужно профилировать и искать проблемные места.

Но проверять эффективность оптимазации можно только на независимом стенде (или в продакшене на реальных логах).

Зачем нужен тестовый стенд?

  1. Дает чистое окружение
  2. Уменьшает внешнее воздействие
  3. Оптимизации должны быть воспроизводимыми и стабильными. Никакого разброса от 50 до 500мс.
  4. Оптимизации должны появиться у реальных пользователей, а не у вас на локалке.
  5. Надо много раз запускать один и тот же тест в разных браузерах

Как сделать тестовый стенд

Берем два одинаковых сервера.

Один с прод-окружением, другой - с тестовым пакетом.

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

Что делает тест?

  1. Открыть браузер
  2. Открыть SPA
  3. Сделать нужные операции
  4. Операции отправляют метрики
  5. Закрыть браузер

Что делает тест?

Прогоняем эти шаги, скажем, 50 раз.

Считаем медиану и процентили по метрикам.

Это и есть показатель эффективности оптимизации.

Как отслеживать продакшен?

Как не утонуть в графиках

Вы уже научились мерить скорость приложения и построили кучу графиков.

Чтобы в них не утонуть, вам нужен APDEX

APDEX

APDEX – интеграционная метрика, которая сразу говорит: хорошо или плохо.

Значение от 0 до 1, по сути индекс удовлетворенности пользователей.

APDEX

Выбираем временной интервал [0; t] - пользователь счастлив.

Берем еще один интервал (t; 4t] - пользователь удовлетворен.

APDEX = (количество счастливых пользователей + количество удовлетворенных/2) / (количество всех пользователей).

APDEX

  1. Вместо непонятных цифр дает четкий ответ
  2. Можно обрабатывать автоматически
  3. Может агрегировать разные графики

Но не отменяет детальных графиков.

one more thing

В метриках бывают ошибки :)

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

Чтобы такого не было, надо устраивать стресс-тестирование.

Замедляйте код, добавляйте timeout, генерируйте ошибки и смотрите как меняются цифры.

В заключении

  1. Собери факты
  2. Проанализируйте факты
  3. Постройте теорию
  4. Поменяйте один участок кода
  5. Проверьте теорию

В заключении

Постройте графики и наладьте процесс вокруг анализа скорости.

Не делайте ничего наобум, цените свое время.

Следите за жизнью проекта со стороны пользователя, а не из консоли браузера.

Спасибо!

Алексей Андросов, Яндекс.Почта

Email: doochik@ya.ru

Twitter: @doochik

Fork me on Github