Как вы мониторите скорость работы интерфейса у ваших клиентов?

Question

[Alexander Gutnikov]

Допустим вы выложили обновление, которое ускоряет работу сайта у ваших клиентов. Как вы узнаете, насколько успешным оно было? В том числе, очень интересно услышать ребят из Mail, Yandex, Avito

Comments

[Андрей Б.]

В performance не гуру, но разве инспектора хрома не достаточно? network + timeline

[Алексей Уколов]

Андрей Б.: клиентские данные всё же намного репрезентативнее. В DevTools есть всякие "замедлялки" скорости сети и процессора, но это всего лишь эмуляторы и реальной картины не дают.

[Алексей Уколов]

Отличное видео на эту тему - https://www.youtube.com/watch?v=4bZvq3nodf4

[Alexander Gutnikov]

Андрей Б.: Вы можете конечно в инспекторе посмотреть что там в таймлайне, но это будет "нерепрезентативная выборка", представьте что у вас миллион клиентов и у всех разные конфигурации железа, сети, у всех разные расстояние до ваших датацентров и т д. По таймлайну просто невозможно спрогнозировать где и что выстрелит

[Alexander Gutnikov]

Алексей Уколов: Спасибо, да - хорошая конференция. Недавно смотрел

Answer 1

[RubaXa]

В целом всё сводится к:
- Скорость загрузки страницы
- Скорость рендера/обновления конкретных частей страницы
- Скорость перехода между страницами (с кешом, без кеша)
- и т.п.

Но, тут надо понимать, все графики делятся по браузерам, разрешениям, каким-то специфичным параметрам которые влияют на интерфейс (количество писем, треды/не треды и т.п.)

Но это только цветочки, есть огромный пласт числовых метрик (их реально тысячи), которые отвечают за подсчет кликов, показ элементов (например лаеров, балунов и т.п.), количество запросов к api и варианты ответов...

Comments

[Alexander Gutnikov]

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

[RubaXa]

У нас своя система логирования, анализируем в ручном и автоматическом режиме (смс приходит при неожиданном изменении). В ручном при выкатке смотрим на нужные показатели и как они изменяются, кроме этого висят большие мониторы, по которым постоянно ротируются особо важные графики :]

[Alexander Gutnikov]

RubaXa: Вот это и интересно. Где храните данные по показателям, агрегируете их как-то? строите перцентили и прочее? как долго храните данные? что-то особое для хранения данных используете?

[RubaXa]

Говорю же, решение полностью написано нами под наши нужды и уже ооочень давно, минимальный интервал агрегации минута, в итоге получается два графика
- Количество вызовов метрики
- Среднее по Xn за минуту (Хn — это числа, которые передавали в метрику, если я правильно помню)

Хранится ~год

Answer 2

[Александр Аксентьев]

navigation timing api

Николай Сивко рассказывал на хайлоаде в 15 году https://www.slideshare.net/mobile/NikolaySivko/web...

Кто-то там по эксплуатации из хедхантера. Ныне okmeter.io сервис разрабатывают.

Comments

[Алексей Уколов]

Navigation же про скорость загрузки, а не работы интерфейса. Или я ошибаюсь?

[Александр Аксентьев]

Алексей Уколов: ну это единственное из того что доступно насколько я знаю.

Скорость работы именно кода на клиенте понятие очень растяжимое, с учетом того что могут быть и андроиды за 2000 рублей и игровые писи с 32гб рам.
Особенно полезного мне кажется из такого разброса не вытащить будет.
На андроиде мощное SPA будет наглухо виснуть, на писи работать нормально.
В среднем - средне xD
Хотя мощные SPA и на i7 бывает с трудом работают, поэтому я их не очень люблю.

[Александр Аксентьев]

Алексей Уколов: так что основные метрики только в сеть/днс/скоростьзагрузки упираются.
Можно на клиенте измерять конечно таймерами, но очень фиг знает что там будет.

[Alexander Gutnikov]

Алексей Уколов: Тут "скорость работы" в довольно широком смысле имеется в виду. И вопрос скорее про способ измерения и сбора данных чего угодно на клиенте, в том числе и navigation timing данных. Как их собрать, агрегировать и показать и желательно в реальном времени.

[Alexander Gutnikov]

Александр Аксентьев: спасибо за ссылку на HL презентацию - не видел ее. Разброс данных действительно может быт большой и это тоже часть проблемы - недостаточно считать среднее значение, хорошо бы иметь возможность строить перцентили и т д

[Александр Аксентьев]

Alexander Gutnikov: okmeter.io как раз в персентилях показывает всевозможные значения :)

[Alexander Gutnikov]

Александр Аксентьев: Не могу понять, у окметер написано что это мониторинг постргеса. Или на его основе клиентские метрики тоже можно процессить как-то?

[Александр Аксентьев]

Alexander Gutnikov:
Это слайдер на главной - дальше пролистайте :D
там из коробки очень много метрик: nginx, postgre/mysql, cpu, сбор данных navigation timing api и т.п. Как в munin практически или даже больше.
Но представление данных в персентилях, что чуть полезнее чем в мунине.
А так же возможность оповещений для критических параметров.
Ну и свои можно любые метрики делать на основе.

[Александр Аксентьев]

Alexander Gutnikov: dsro.ru/gyazo/images/7bb6e1e4bbe04ea4f8f5c97345a6.png

[Alexander Gutnikov]

Александр Аксентьев: А все вижу, спасибо. Текст на главной путает. Спасибо - почитаю

[Алексей Уколов]

Тут "скорость работы" в довольно широком смысле имеется в виду. И вопрос скорее про способ измерения и сбора данных чего угодно на клиенте, в том числе и navigation timing данных. Как их собрать, агрегировать и показать и желательно в реальном времени.

Стоит об этом явно в вопросе написать. Тогда и ответы будут релевантнее и люди будут понимать о чём речь.
Я, например, подписался, потому что про Navigation Timing API знаю, а как измерять на клиенте скорость работы интерфейса не очень представляю. Но если речь пойдёт про агрегацию и графики, то это мимо меня.