Java, UX, HTML, CSS, WEB-design

Измерение производительности с помощью синхронизации сервера

[ad_1]

  • Дрю Маклеллан

  • 0 Комментарии

Измерение производительности с помощью синхронизации сервера

  • 7 минут чтения

  • Производительность, API, Методы

Краткое резюме ↬

Заголовок Server Timing обеспечивает дискретный и удобный способ передачи данных о производительности внутреннего сервера инструментам разработчика в браузере. Добавление информации о времени в ваше приложение позволяет вам отслеживать производительность серверной и клиентской части в одном месте.

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

Многие из нас знакомы с работой над проблемой производительности на каком-то уровне. Это может быть что-то такое же простое, как попытка выяснить, почему JavaScript на вашей странице не запускается достаточно быстро или почему изображения слишком долго появляются при плохом Wi-Fi в отеле. Ответы на такого рода вопросы часто можно найти в очень знакомом месте: в инструментах разработчика вашего браузера.

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

«Время до первого байта»

Оптимизация браузера мало что может сделать для улучшения страницы, которая просто медленно создается на сервере. Эта стоимость возникает между тем, как браузер делает запрос на файл и получает ответ. Изучение вашей каскадной диаграммы сети в инструментах разработчика покажет эту задержку в категории «Ожидание (TTFB)». Это время ожидания браузера между выполнением запроса и получением ответа.

Еще после прыжка! Продолжить чтение ниже ↓

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

Панель «Сеть» в Chrome DevTools, показывающая проверку запроса одной страницы.
Проверка запроса документа показывает время, которое браузер тратит на ожидание ответа от сервера.

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

Заголовок синхронизации сервера

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

Это делается очень просто, прозрачно для пользователя и оказывает минимальное влияние на вес вашей страницы. Информация отправляется в виде простого набора заголовков ответа HTTP.

Server-Timing: db;dur=123, tmpl;dur=56

В этом примере сообщается о двух разных временных точках, названных db и tmpl. Это не часть спецификации — это имена, которые мы выбрали, в данном случае для представления некоторых временных параметров базы данных и шаблона соответственно.

То dur свойство указывает количество миллисекунд, которое потребовалось для завершения операции. Если мы посмотрим на запрос в разделе «Сеть» инструментов разработчика, то увидим, что тайминги добавились на график.

Панель «Время запроса страницы» в Chrome DevTools, показывающая новый раздел «Время сервера».
Появится новый раздел Server Timing, показывающий тайминги, установленные с помощью HTTP-заголовка Server-Timing.

То Server-Timing заголовок может принимать несколько метрик, разделенных запятыми:

Server-Timing: metric, metric, metric

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

  1. Короткое название для метрики (например, db в нашем примере)
  2. А продолжительность в миллисекундах (выражается как dur=123)
  3. А описание (выражается как desc="My Description")

Каждое свойство отделяется точкой с запятой в качестве разделителя. Мы могли бы добавить описания к нашему примеру следующим образом:

Server-Timing: db;dur=123;desc="Database", tmpl;dur=56;desc="Template processing"
Панель «Время запроса страницы» в Chrome DevTools, показывающая описания, используемые для показателей времени сервера.
Имена заменяются описаниями, если они предоставлены.

Единственное свойство, которое требуется, это name. Оба dur и desc являются необязательными и могут использоваться при необходимости. Например, если вам нужно отладить проблему синхронизации, которая возникает на одном сервере или в центре обработки данных, а не на другом, может быть полезно добавить эту информацию в ответ без связанной синхронизации.

Server-Timing: datacenter;desc="East coast data center", db;dur=123;desc="Database", tmpl;dur=56;desc="Template processing”

Затем это будет отображаться вместе с таймингами.

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

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

Реализация серверного времени

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

  1. Время некоторых операций
  2. Соберите вместе результаты тайминга
  3. Вывести HTTP-заголовок

В псевдокоде генерация ответа может выглядеть так:

startTimer('db')
getInfoFromDatabase()  
stopTimer('db')

startTimer('geo')
geolocatePostalAddressWithAPI('10 Downing Street, London, UK')
endTimer('geo')

outputHeader('Server-Timing', getTimerOutput())

Основы реализации чего-либо в этом направлении должны быть простыми на любом языке. Очень простая реализация PHP может использовать microtime() функция для операций синхронизации и может выглядеть примерно так:

class Timers
{
    private $timers = [];

    public function startTimer($name, $description = null)
    {
        $this->timers[$name] = [
            'start' => microtime(true),
            'desc' => $description,
        ];
    }

    public function endTimer($name)
    {
        $this->timers[$name]['end'] = microtime(true);
    }

    public function getTimers()
    {
        $metrics = [];

        if (count($this->timers)) {
            foreach($this->timers as $name => $timer) {
                $timeTaken = ($timer['end'] - $timer['start']) * 1000;
                $output = sprintf('%s;dur=%f', $name, $timeTaken);

                if ($timer['desc'] != null) {
                    $output .= sprintf(';desc="%s"', addslashes($timer['desc']));
                } 
                $metrics[] = $output;
            }
        }

        return implode($metrics, ', ');
    }
}

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

$Timers = new Timers();

$Timers->startTimer('db');
usleep('200000');
$Timers->endTimer('db');

$Timers->startTimer('tpl', 'Templating');
usleep('300000');
$Timers->endTimer('tpl');

$Timers->startTimer('geo', 'Geocoding');
usleep('400000');
$Timers->endTimer('geo');

header('Server-Timing: '.$Timers->getTimers());

Запуск этого кода сгенерировал заголовок, который выглядел так:

Server-Timing: db;dur=201.098919, tpl;dur=301.271915;desc="Templating", geo;dur=404.520988;desc="Geocoding"
Панель «Время запроса страницы» в Chrome DevTools, на которой правильно отображаются тестовые значения.
Тайминги сервера, установленные в примере, отображаются на панели «Тайминги» с задержками, настроенными в нашем тестовом сценарии.

Существующие реализации

Учитывая, насколько удобен Server Timing, мне удалось найти относительно немного реализаций. Пакет server-timing NPM предлагает удобный способ использования Server Timing из проектов Node.

Если вы используете PHP-фреймворк на основе промежуточного программного обеспечения, tuupola/server-timing-middleware также предоставляет удобный вариант. Я использую это в производстве на Notist в течение нескольких месяцев, и я всегда оставляю несколько основных таймингов включенными, если вы хотите увидеть пример в дикой природе.

Что касается поддержки браузера, лучшее, что я видел, это Chrome DevTools, и это то, что я использовал для скриншотов в этой статье.

Соображения

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

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

Использование заголовка Server Timing — отличный способ убедиться, что вся информация о времени как от внешнего, так и от внутреннего интерфейса вашего приложения доступна в одном месте. Если ваше приложение не слишком сложное, его можно легко реализовать, и вы сможете запустить его в работу в течение очень короткого промежутка времени.

Если вы хотите узнать больше о синхронизации сервера, вы можете попробовать следующее:

  • Спецификация синхронизации сервера W3C
  • На странице MDN, посвященной синхронизации сервера, есть примеры и актуальная информация о поддержке браузера.
  • Интересный репортаж от команды BBC iPlayer об использовании ими Server Timing.
Сокрушительная редакция
(ра)



[ad_2]
Source: https://smashingmagazine.com

Заключение

Вы ознакомились с статьей — Измерение производительности с помощью синхронизации сервера

Пожалуйста оцените статью, и напишите комментарий.

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован.

Краткое описание по статье Измерение производительности с помощью синхронизации сервера

Название: Измерение производительности с помощью синхронизации сервера . Краткое описание: [ad_1] ⭐ Дрю Мак . Дата публикации: 26.01.2022 . Автор: Алишер Валеев .

Для чего создан сайт Novosti-Nedeli.ru

Данный сайт посвящен новостям мира и мира технологий . Также тут вы найдете руководства по различным девайсам.

Сколько лет сайту?

Возраст составляет 3 года

Кнопка «Наверх»