Алексей Андросов, Яндекс.Почта
Алексей Андросов, Яндекс.Почта
В идеале нужно уметь измерять любой сценарий пользователя “от клика до реакции на это действие”.
Для этого пригодится единый API “сделай что-то и перерисуй страницу”.
Каждую стадию и общее время надо измерять отдельно. Если общее время считать как сумму микро-метрик, то вы рискуете потерять что-то важное.
Если общее время и сумма метрик не совпадает, значит у вас не считается какая-та стадия.
Медиана – это серединное, а не среднее значение в выборке. Если у нас имеются числа 1, 2, 2, 3, 8, 10, 20, то медиана – 3, а среднее – 6,5.
Она хорошо отсекает слишком плохие или слишком хорошие данные.
Строим график по группам. Например
Случайно генерируем ключ, который выдается при загрузке SPA и идентифицирует его сессию (session_id).
Его надо пробрасывать во всех запросах во все бекенды.
В каждый запрос еще можно добавлять ID(request_id).
Во-первых, надо четко понимать какие цифры вы считаете хорошими, а какие плохими.
Вот страница рисует за 500мс. Это хорошо или плохо? А если я потрачу день и будет 450мс?
У каждой оптимизации есть стоимость!
Хорошая цель: список рисуется за 100мс у 90% клиентов
Профилировать запуск обновления SPA, в котором были сделаны десятки тысяч вызовов JS-функций немного сложновато…
Туда неизбежно попадут внутрении вызовы фреймворка, о которых вы ничего не знаете и не контроллируете.
А еще проблема в том, что сложно отследить к какому именно блоку относятся вызовы.
Вам помогут метрики стадий, чтобы узнать где большего всего потеряли времени. Фреймворки иногда имеют встроенные метрики производительности.
Надо проектировать сценарии в тестах так, чтобы избежать внешнего влияния. Можно отключать какие-то view и смотреть насколько ускоряется приложение.
Не ленитесь и потратьте 10 минут времени на написание скрипта, который выполнит нужный вам сценарий действий.
Это сэкономит вам часы безтолкового кликанья по кнопкам и снятия метрик.
А еще даст возможность запускать этот сценари сколько угодно раз!
Микрооптимизации в реальных приложениях почти никогда ничего не дают.
Оптимизируйте то, что реально тормозит, а не то, что вы думаете, что тормозит!
Например, не стоит делать оптимизацию, если она будет меньше 20мс или 10%.
Я хочу вас уберечь от бессмысленного проведения дня на jsperf и слов “Я тут заменил везде forEach на for и теперь все работает на целых 5мс быстрее!”
Иногда видно, что происходит тысячи вызовов микрофункции и это занимает много времени.
Как же померить ее скорость?
var sum = 0;
function myFn() {
var start = performance.now();
callMicroFn();
var end = performance.now();
sum += (end - start);
Очень часто надо оптимизировать небольшие элементы страницы. Скажем, по 10мс каждый.
Если вы случайно сделаете 9мc, то не поймете это погрешность или оптимизация.
Техника очень простая - сделайте одно и тоже действие много раз.
Например, вместо 20 элементов коллекции отрисуйте 200 или 1000.
Единичный элемент страницы - это просто коллекция с одним элементом :)
Важно понимать, что скорость должна увеличиваться как минимум линейно.
Если это не так, то большой список не отрисуется никогда.
Допустим, у нас есть стадии:
Увеличивая количество элементов, можно увидеть какая стадия растет непропорционально. В ней и заключается проблема!
У нас есть метрики и мы нашли возможное место, которое тормозит.
Мы его даже как-то оптимизировали. Как проверить?
Нужно профилировать и искать проблемные места.
Но проверять эффективность оптимазации можно только на независимом стенде (или в продакшене на реальных логах).
Берем два одинаковых сервера.
Один с прод-окружением, другой - с тестовым пакетом.
Запускаем одни и те же сценарии, сравниваем результаты.
Прогоняем эти шаги, скажем, 50 раз.
Считаем медиану и процентили по метрикам.
Это и есть показатель эффективности оптимизации.
Вы уже научились мерить скорость приложения и построили кучу графиков.
Чтобы в них не утонуть, вам нужен APDEX
APDEX – интеграционная метрика, которая сразу говорит: хорошо или плохо.
Значение от 0 до 1, по сути индекс удовлетворенности пользователей.
Выбираем временной интервал [0; t] - пользователь счастлив.
Берем еще один интервал (t; 4t] - пользователь удовлетворен.
APDEX = (количество счастливых пользователей + количество удовлетворенных/2) / (количество всех пользователей).
Но не отменяет детальных графиков.
Если графики ровные, а пользователи жалуются, значит у вас ошибки в метриках.
Чтобы такого не было, надо устраивать стресс-тестирование.
Замедляйте код, добавляйте timeout, генерируйте ошибки и смотрите как меняются цифры.
Постройте графики и наладьте процесс вокруг анализа скорости.
Не делайте ничего наобум, цените свое время.
Следите за жизнью проекта со стороны пользователя, а не из консоли браузера.
Алексей Андросов, Яндекс.Почта
Email: doochik@ya.ru
Twitter: @doochik