Система мониторинга производительности фронтенда своими руками

внешний интерфейс монитор
Система мониторинга производительности фронтенда своими руками

Система мониторинга производительности фронтенда своими руками

задний план

Зачем отслеживать производительность страницы?

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

Кроме того, скорость загрузки страницы также напрямую влияет на SEO страницы.Если скорость загрузки страницы слишком низкая, пользователь напрямую отключит ее, что напрямую увеличит показатель отказов страницы. поисковая система обнаружит, что показатель отказов страницы высок, поисковая система подумает, что сайт не представляет большой ценности для пользователя, что понизит рейтинг. В июле 2018 года новые правила Google предусматривают, что время доступа к странице относительно велико, а формула Google снизит рейтинг страницы в поиске.

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

Существует множество зрелых и отличных инструментов для оценки и мониторинга производительности страницы, таких какgtmetrixВеб-сайт, на котором он может одновременно проверять результаты нескольких инструментов анализа, предоставит множество предложений.

Однако этот метод отклоняется от реальной ситуации и не может дать обратную связь об общей скорости определенного региона, количестве медленных пользователей и не может отражать колебания производительности.Помимо белого экрана и тому подобного, у нас также есть некоторые функциональные измерения скорости, такие как время клика по странице, время показа рекламы и т. д., их нельзя моделировать и отслеживать.

Чтобы постоянно отслеживать доступ пользователей и доступность различных функций страницы в различных сетевых средах, мы решили внедрить js на страницу для мониторинга реальных данных пользователей в Интернете. Конкретный метод заключается в использовании фрагмента кода для передачи данных пользователя на наш сервер и использовании системы для агрегирования, обработки и, наконец, построения графика данных, чтобы мы могли просматривать производительность каждой страницы.

Проектирование системы измерения скорости

Тестовая система разделена на три части следующим образом.

  • Передняя отчетность
    • Как записывать моменты времени измерения скорости.
    • Как сообщить.
    • выборка данных.
  • Обработка данных, хранение.
  • Отображение данных

###Внешняя отчетность

Фрагмент внешнего js-кода внедряется во внешний интерфейс, и данные о производительности страницы передаются через эти коды. Какие индикаторы могут лучше отражать опыт пользователя?

Самое большое чувство пользователя — почему так долго открывается страница, почему так медленно загружается изображение, а на страницу после загрузки долго нельзя кликнуть. Пользовательский опыт — важный показатель производительности страницы для программистов. В соответствии с вышеуказанными проблемами пользователей, индикаторы абстрагируются, время белого экрана, время первого экрана и интерактивное время. Так как же нам считать это время?

Определить отправную точку для статистики

Время начальной точки должно быть, когда мы вводим URL-адрес и нажимаем Enter в качестве начальной точки, то есть время, когда пользователь действительно начинает ждать. Если это браузер высокого класса, мы можем напрямую использовать интерфейс Navigation Timeing для получения начальной точки статистики.

Интерфейс Navigation Timeing – это API JavaScript для точного измерения производительности в Интернете. Этот интерфейс предоставляет серию подробных временных состояний.

Откройте консоль в Chrome, введите производительность в командной строке, щелкните ее и просмотрите ее свойство времени, вы увидите следующий код.

1.png

Каждое свойство performance.timing представляет событие страницы (например, страница, отправляющая запрос) или загрузку страницы (например, начало загрузки DOM), измеренное в миллисекундах с полуночи 1 января 1970 года. Результат 0 указывает на то, что событие не произошло (например, redirectEnd или redirectStart и т. д.).

Вот один изNavigation Timing draftПолучена диаграмма последовательности события performance.timing.

2.png

НавигацияStart указывает время, когда браузер запрашивает его, что обычно является временем, когда вы возвращаетесь к семинару в поле ввода URL-адреса, или временем, когда страница обновляется нажатием F5.

Для получения подробных объяснений в другие моменты времени, пожалуйста, нажмите https://www.w3.org/TR/navigation-timing/ или погуглите, есть много статей, объясняющих это, поэтому я не буду повторяться здесь.

Этот интерфейс уже поддерживается большинством браузеров, за исключением браузеров ниже IE9 на стороне ПК.

время белого экрана

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

Есть три типа времени, когда заканчивается настоящий белый экран.

Первый тип обычной страницы, которая не зависит от рендеринга js, время белого экрана должно быть, когда загружаются ресурсы внешней ссылки в заголовке, потому что браузер будет отображать страницу только при загрузке ресурсов заголовка. Таким образом, момент времени белого экрана лучше всего печатать в конце заголовка (здесь он может быть неточным, но постарайтесь быть как можно ближе), как показано в коде.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <!--头部资源-->
    <link href="style.css">
    <title>Document</title>
    <scirot>
        // 白屏幕结束时间
        var time = +new Date() - performance.timing.navigationStart;
    </scirot>
</head>
<body>
</body>
</html>

Во-вторых, использовать некоторые интерфейсные фреймворки, такие как vue и reacjs, которые должны выполнять js перед рендерингом контента на страницу или асинхронно извлекать данные и отображать страницу, когда данные извлекаются обратно. В этом случае мы обычно помещаем цену страницы в состояние загрузки. Тогда время окончания белого экрана после загрузки этой загрузки.

выше сгиба

Под временем первого экрана понимается время, когда все ресурсы на первом экране страницы отображаются полностью. Это время непоследовательно для каждой страницы. Например, первый экран страницы — это 4 изображения, тогда мы должны вычислить первое экранное время после загрузки четырех изображений, или, если страница асинхронно извлекает данные, первое экранное время должно быть временем, когда данные вставлены. в браузер. . Короче говоря, время, когда первый экранный ресурс наконец загружается, считается первым экранным временем.

Метод отчетности

После измерения времени данные необходимо отправить на сервер. К данным измерения скорости предъявляются низкие требования по скорости потерь, и измерение скорости должно производиться по возможности без ущерба для логики основного процесса и производительности страницы. Запрос на получение тега img, используемый для сообщения данных, в основном по следующим причинам.

  • Нет междоменной проблемы ajax, и можно делать запросы из разных источников.
  • Очень старая вкладка, нет проблем с совместимостью браузера
 var i = new Image();
 i.onload = i.onerror = i.onabort = function () {
 	i = i.onload = i.onerror = i.onabort = null;
 }
 i.src = url;
            

Некоторые продвинутые браузеры также поддерживают метод navigator.sendBeacon. Этот метод можно использовать для отправки небольших объемов данных, этот метод является асинхронным, и запрос все равно может быть отправлен даже при закрытом браузере, что особенно удобно для отчетности по статистике.

navigator.sendBeacon(url, data ? $.param(data) : null)

Окончательное решение: когда браузер поддерживает метод sendBeacon, этот метод используется первым, а метод img используется для сообщения, если он не поддерживает.

выборка

Данные отчета об измерении скорости огромны.Поскольку данные слишком велики, время обработки хранилища также увеличится, а производительность сервера будет ограничена.Во избежание пустой траты ресурсов обработка выборки данных выполняется в процессе создания отчета. Степень детализации выборки контролируется самим клиентом, если выборка 1/10, то к сообщаемым данным следует добавить rate=10, а rate — это частота выборки.

Сбор и хранение данных

Мы настроили сервер nginx на машине.Сервер nginx может записывать доступ и записывать запись доступа пользователя в журнал.Этот журнал может записывать все заголовки запроса информации запроса, такие как параметры запроса и запрос ip. Журнал может быть сформирован в соответствии с установленным форматом.

Когда тест скорости страницы отправляет запрос, nginx записывает запрос и записывает запрос в лог.

Мы не использовали logrotater nginx (опрос времени журнала). Поскольку минимальная гранулярность logrotater составляет 1 день, но мы надеемся, что лог хранится в файле 5 минут (причина в том, что файлы могут быть пакетными, чтобы избежать обработки слишком больших файлов за один раз, а точка измерения скорости однодневный тренд точки измерения скорости, которую мы запрашиваем. Гранулярность также составляет 5 минут).

Конфигурация nginx выглядит следующим образом:

if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})T(\d{2}):(\d{1})[0-4]")
{
    set $logname $1-$2-$3-$4-$50;
}
if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})T(\d{2}):(\d{1})[5-9]")
{
    set $logname $1-$2-$3-$4-$55;
}

生成该日志:
access_log logs/stat.y.qq.com.sp.access.$logname.log spdata;

Непосредственно при создании лог-файла он разделяется. Однако у этого есть недостаток, заключающийся в том, что вы не можете использовать функцию logrotate для регулярного удаления файлов журналов.Вам необходимо написать дополнительный скрипт для регулярного удаления журналов, чтобы избежать чрезмерного осаждения файлов и траты дисковых ресурсов.

Формат данных, хранящихся в журнале, следующий:

log_format  spdata  '$time_local ~|^ $http_x_forwarded_for ~|^ $request ~|^ $http_referer ~|^ $status ~|^ $http_user_agent ~|^ $cookie_ptisp ~|^ $cookie_uin';

где ~|^ — разделитель

Статистические поля

  • время, нажмите 5 минут
  • IP, IP-адрес пользователя
  • данные, данные, сообщаемые страницей
    • Идентификатор продукта AppID Идентификатор продукта (например, музыка QQ, национальная песня K)
    • идентификатор проекта pid (например, клиент для ПК, YQQ, музыкальный мобильный клиент QQ, другой H5)
    • pageid id страницы (конкретная страница в рамках проекта)
    • баллы Пункт скорости 1=xx&2=xx&3=xx...
    • r Частота дискретизации 0~1
  • реферер страницы
  • ua разобрать подплатформу подсистему подсистему подсистему тип сети
  • провайдер провайдер
  • uin идентификатор пользователя

Чтобы уменьшить нагрузку на сервер, отчетная машина отделена от сервера хранения. При хранении сервер хранилища регулярно извлекает журналы с машины для создания отчетов для хранения данных.

Хранилище данных

Обработка данных является серьезной проблемой для системы, и вся платформа имеет сотни миллионов PV в день. Чтобы избежать слишком больших данных, мы будем собирать данные для создания новой таблицы по дате.

Даже если новая таблица создается по дате, необходимо запросить десятки миллионов данных, и прямой запрос данных в таблице занимает очень много времени. Чтобы решить проблему трудоемкого запроса данных, мы установили три таблицы:Таблица статистики данных, таблица необработанных данных, индексная таблица необработанных данных.

Таблица статистики

Таблица статистики предназначена для записи среднего времени, потраченного на все точки на странице в течение 5 минут. При анализе данных программа делит день на 5 минут, вычисляет 5-минутную среднюю скорость каждой точки измерения скорости и записывает ее в таблицу статистики данных.При запросе тренда определенной точки измерения скорости за день, мы можем напрямую запросить таблицу статистики без необходимости повторного использования всех точек. Использование статистических таблиц может значительно уменьшить количество запрашиваемых данных, тем самым повышая скорость запросов.Запросы MySQL находятся на уровне миллисекунд.

Исходная таблица и индексная таблица

Таблица статистики данных может решить большинство потребностей запроса данных, но если вы добавите несколько сложных условий запроса (условия запроса: страна, провинция, оператор, тип сети, операционная платформа), очевидно, что таблица статистики не может быть удовлетворена. статистическая таблица создается для каждой комбинации условий, которая будет генерировать много дополнительных таблиц, а скорость использования составных запросов не очень высока, но стоимость очень велика.Это решение неосуществимо.

Мы храним необработанные данные в другой таблице, чтобы проверить индекс таблицы необработанных данных. Таблица данных не должна быть слишком большой, данные превышают определенную величину, скорость запроса будет очень низкой, чтобы обеспечить производительность Mysql, где количество записей в одной таблице рекомендуется не превышать 10 миллионов. Для запроса таблицы данных по различным субиндексам.

Порог тревоги

Когда интерфейс данных возвращается слишком медленно, скорость открытия страницы низкая.В это время нам нужно раннее предупреждение, чтобы уведомить разработчиков о том, что при обработке данных в базу данных среднее время, затрачиваемое узлом за 5 минут, превышает заданный порог, или порог по умолчанию 10 секунд, система каким-то образом сообщит эту информацию разработчику. Страница может быть очень чувствительной для поиска проблем с помощью сигналов тревоги, чтобы вовремя их решить и предотвратить дальнейшее распространение проблемы.

Отображение данных

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

Общий обзор страницы

3.png

Для отображения трудоёмкой ситуации всех точек измерения скорости на всей странице.

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

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

Детали точки скорости

4.png

Точка измерения скорости будет отображать следующую информацию

  • среднее время
  • объем запроса
  • процент медленных пользователей
  • Нормальное распределение скорости

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

Общие размеры

  • нация
  • провинция
  • оператор
  • Тип сети
  • операционная система

5.png

обработка исключительных данных

6.png

На графике с точками наблюдения график будет иметь длинный рывок. Причина рывка в том, что латентность этой точки намного выше данных окружающих точек. Для того, чтобы выяснить причину всплеска, был запрошен исходная таблица.Большинство точек отчета в норме, но будет отчет, который занимает более 30 минут.В настоящее время я не знаю, почему такой длинный сообщается время рендеринга, которое может быть связано с машиной пользователя, а также с состоянием сети в то время. Эти данные сообщает пользовательская сторона, и трудно определить проблему.Эти точки имеют большое влияние на расчетное среднее значение графика.Чтобы гарантировать, что данные в целом являются нормальными, а данные не затронуты аномальным узлом, мы нажмем «Фильтр», чтобы отфильтровать напрямую.

Суммировать

Мы познакомим вас с тем, как создать систему измерения скорости с учетом трех аспектов: интерфейсной отчетности, сбора и хранения данных и отображения данных. Оптимизация производительности — это то, на что нам нужно постоянно обращать внимание. Чтобы обеспечить бесперебойную работу пользователей, скорость измерительная система является незаменимым инструментом.

Ссылаться на

https://fex.baidu.com/blog/2014/05/build-performance-monitor-in-7-days/

https://www.qcloud.com/community/article/655542

http://javascript.ruanyifeng.com/bom/performance.html