что такое тпс сервера
Русские Блоги
Пропускная способность системы, TPS (QPS), параллелизм пользователей, концепции и формулы тестирования производительности
1. TPS:
Транзакций в секунду (количество транзакций, обрабатываемых в секунду), то есть количество транзакций, обрабатываемых сервером в секунду. TPS включает одно входящее и одно исходящее сообщение, а также один доступ к базе данных пользователя. (Business TPS = CAPS × среднее TPS на звонок)
Как правило, производительность системы оценки измеряется количеством технических транзакций, выполняемых за секунду. Общая производительность системы зависит от значения TPS модуля с самой низкой производительностью.
2. QPS:
Соответствует количеству запросов в секунду, которое представляет собой максимальную пропускную способность.
PS: Ниже приведены основные понятия и формулы расчета теста производительности, запишите:
Один. Элементы измерения системы проглатывания:
Пропускная способность (способность выдерживать давление) системы тесно связана с потреблением ЦП запроса, внешними интерфейсами, вводом-выводом и так далее. Чем выше потребление ЦП на один запрос, тем медленнее влияние внешних системных интерфейсов и ввода-вывода, тем ниже пропускная способность системы и наоборот.
Несколько важных параметров пропускной способности системы: QPS (TPS), одновременное количество, время отклика.
QPS (TPS): количество запросов / транзакций в секунду
Количество одновременных проблем: количество запросов / транзакций, одновременно обрабатываемых системой.
Время отклика: обычно принимают среднее время отклика.
(Многие люди часто путают число параллелизма и понимание TPS)
Поняв значение трех вышеуказанных элементов, вы можете рассчитать взаимосвязь между ними:
QPS (TPS) = Количество одновременных запросов / Среднее время ответа или Количество одновременных запросов = QPS * Среднее время ответа
Типичная система входа для работы. Вы выходите на работу в 8 утра, а пользователь входит в систему входа на 30 минут с 7:30 до 8:00. В компании работает 1000 сотрудников, и среднее время входа каждого сотрудника в систему составляет 5 минут. Для расчета можно использовать следующий метод.
QPS = 1000 / (30 * 60) транзакций / сек.
Среднее время ответа = 5 * 60 секунд.
Параллелизм = QPS * Среднее время ответа = 1000 / (30 * 60) * (5 * 60) = 166,7
Пропускная способность системы обычно определяется двумя факторами: QPS (TPS) и количеством одновременных операций. Эти два значения каждой системы имеют относительное предельное значение. Под давлением доступа к сценарию приложения, пока один элемент достигает наивысшего значения системы, система Пропускная способность не увеличится. Если давление будет продолжать увеличиваться, вместо этого упадет пропускная способность системы. Причина в том, что система перегружена, а другое потребление, такое как переключение контекста, память и т. Д., Приводит к снижению производительности системы.
Факторы, определяющие время отклика системы
Время отклика системного вызова такое же, как и в плане проекта, но также существует критический путь, то есть время воздействия системы;
Критический путь состоит из операций ЦП, ввода-вывода, ответа внешней системы и т. Д.
два. Оценка производительности системы:
При проектировании системы нам необходимо учитывать влияние операций ЦП, операций ввода-вывода и факторов отклика внешней системы, а также предварительные оценки производительности системы.
В нормальных условиях, когда мы сталкиваемся с требованиями, помимо QPS и параллелизма, есть еще одно измерение: дневная PV.
Наблюдая за журналом доступа системы, обнаруживается, что в случае большого количества пользователей трафик доступа в один и тот же период времени в каждый период времени почти одинаков. Например, каждое утро в будние дни. Пока мы можем получить дневную диаграмму потока и QPS, мы можем рассчитать дневной поток.
Обычные технические приемы:
1. Найдите самые высокие TPS и дневные PV системы. Эти два элемента имеют относительно стабильную взаимосвязь (за исключением праздников и сезонных факторов).
2. С помощью стресс-теста или эмпирической оценки получается наивысшее значение TPS, а затем используется соотношение 1 для расчета максимальной суточной пропускной способности системы. Китайцы B2B и Taobao сталкиваются с разными группами клиентов. Сетевое поведение этих двух групп клиентов не применяется, и соотношение между TPS и PV отличается.
Соотношение между TPS и PV Taobao обычно составляет самый высокий TPS: PV составляет примерно 1: 11 * 3600 (эквивалентно 11 часам доступа при самом высоком TPS. Это сценарий для деталей продукта. Различные сценарии приложений будут иметь некоторые различия)
Б) B2B китайская станция
Взаимосвязь между TPS и PV B2B сильно различается в зависимости от системы и различных сценариев приложений. По приблизительным оценкам, она составляет около 1: 8 часов (данные анализа трафика для подробных данных о предложениях в 2009 году). Существует большая разница между пропорциями Wangpu и offerdetail, что может быть вызвано временной высокой долей краулеров.
В среде Taobao, если предположить, что TPS, которое мы проводим в стресс-тесте, равно 100, то ежедневная пропускная способность этой системы = 100 * 11 * 3600 = 3,96 миллиона.
Это в случае простых (один URL), некоторых страниц, на странице есть несколько запросов, фактическая пропускная способность системы еще меньше.
Независимо от того, есть ли время на обдумывание (T_think), значение TPS, полученное в результате теста, количество одновременных виртуальных пользователей (U_concurrent) и время отклика транзакции (T_response), считываемое Loadrunner, имеют следующие отношения (при стабильной работе):
TPS=U_concurrent / (T_response+T_think)。
Взаимосвязь между количеством одновременных запросов, QPS и средним временем отклика.
Основные понятия и формулы расчета тестирования производительности программного обеспечения
1. В центре внимания производительность программного обеспечения
На какую производительность стоит обратить внимание при тестировании ПО?
Мы думаем о том, какие роли задействованы в разработке, развертывании, использовании и обслуживании программного обеспечения, а затем рассматриваем, на каких аспектах производительности эти роли сосредоточены. Как инженер по тестированию производительности программного обеспечения, на чем мы должны сосредоточиться?
Для пользователей, когда они нажимают кнопку, ссылку или выдают инструкцию, до тех пор, пока система не отобразит результаты в форме, которую воспринимает пользователь, время, затраченное на этот процесс, является интуитивным впечатлением пользователя о производительности программного обеспечения. Это то, что мы называем временем отклика. Когда соответствующее время невелико, взаимодействие с пользователем хорошее. Конечно, время отклика взаимодействия с пользователем включает личные субъективные факторы и объективное время отклика. При разработке программного обеспечения нам нужно подумать, как улучшить Объедините эти две части, чтобы добиться наилучшего взаимодействия с пользователем. Например, когда пользователь запрашивает большой объем данных, мы можем отобразить первые извлеченные данные для пользователя и продолжить извлечение данных, пока пользователь их просматривает. В это время пользователь не знает, что мы делаем в фоновом режиме.
Пользователь обеспокоен соответствующим временем действия пользователя.
Во-вторых, мы рассматриваем аспекты производительности, которые требуют внимания с точки зрения администратора.
1. Соответствующее время
2. Разумно ли использование ресурсов сервера?
3. Разумно ли использование ресурсов сервера приложений и базы данных?
4. Можно ли расширить систему?
5. Какое максимальное количество пользователей может поддерживать система и каков максимальный объем бизнес-обработки в системе?
6. Где может быть узкое место в производительности системы
7. Изменение этих устройств может повысить производительность.
8. Может ли система поддерживать бизнес-доступ 7 × 24 часа?
Опять же, рассмотрим это с точки зрения разработчиков (дизайнеров).
1. Разумна ли архитектура?
2. Разумна ли конструкция базы данных?
3. Есть ли у кода проблемы с производительностью?
4. Есть ли в системе неоправданное использование памяти?
5. Есть ли в системе какой-либо необоснованный метод синхронизации потоков?
6. Существует ли в системе необоснованная конкуренция за ресурсы.
Итак, на что нам следует обратить внимание с точки зрения инженеров по тестированию производительности?
Одним словом, надо обратить внимание на все вышеперечисленные моменты производительности.
Два, несколько основных условий производительности программного обеспечения
1. Время ответа: время, необходимое для ответа на запрос.
Время передачи по сети: N1 + N2 + N3 + N4
Время обработки сервера приложений: A1 + A3
Время обработки сервера базы данных: A2
Время отклика = N1 + N2 + N3 + N4 + A1 + A3 + A2
2. Формула расчета количества одновременных пользователей.
Количество пользователей системы: количество пользователей, оцененных системой, например системой OA, общее количество пользователей, которые могут использовать систему, составляет 5000, тогда это количество является количеством пользователей системы.
Количество одновременных онлайн-пользователей: наибольшее количество одновременных онлайн-пользователей в определенном временном диапазоне.
Количество одновременных онлайн-пользователей = количество запросов в секунду RPS (пропускная способность) + количество одновременных подключений + среднее время обдумывания пользователем
Расчет среднего количества одновременных пользователей: C = nL / T
Расчет пикового количества одновременных пользователей: C ^ примерно равно C + 3 * радикал C
3. Формула расчета пропускной способности
Относится к количеству запросов пользователей, обрабатываемых системой за единицу времени.
С точки зрения бизнеса пропускную способность можно измерить в единицах измерения, таких как количество запросов в секунду, количество страниц в секунду, количество людей в день или количество обработанных транзакций в час.
С точки зрения сети пропускная способность может быть измерена в байтах в секунду.
Для интерактивных приложений индекс пропускной способности отражает нагрузку на сервер, которая может указывать на нагрузочную способность системы.
Когда нет узких мест в производительности, существует определенная связь между пропускной способностью и количеством виртуальных пользователей, которую можно рассчитать по следующей формуле: F = VU * R /
4. Счетчик производительности
Это некоторые индикаторы данных, которые описывают производительность сервера или операционной системы, например, объем используемой памяти и время процесса, которые играют роль «мониторинга и анализа» при тестировании производительности, особенно при анализе всей масштабируемости и определении новых узких мест в энергии. Очень важная роль.
Использование ресурсов: относится к использованию различных ресурсов в системе, например, коэффициент использования ЦП составляет 68%, коэффициент использования памяти составляет 55%, обычно используется «фактическое использование ресурсов / общий доступный ресурс» для формирования коэффициента использования ресурсов.
5. Формула расчета времени обдумывания.
Время обдумывания, с точки зрения бизнеса, это время относится к интервалу времени между каждым запросом, когда пользователь выполняет операцию. Чтобы смоделировать этот интервал времени при проведении тестирования новой энергии, вводится концепция времени обдумывания, чтобы сделать его более реалистичным. Для имитации действий пользователя.
В формуле пропускной способности F = VU * R / T показывает, что пропускная способность F является функцией количества VU, количества запросов, выданных каждым пользователем R, и времени T, а R можно рассчитать по времени T и времени размышлений пользователя TS. Расчет: R = T / TS
Вот общий порядок расчета времени на обдумывание:
A. Сначала подсчитайте количество одновременных пользователей в системе.
Б. Рассчитайте среднюю пропускную способность системы
F=VU * R / T R×C = VU * R / T
C. Подсчитайте среднее количество запросов, отправленных каждым пользователем.
D. Рассчитайте время обдумывания по формуле
Пропускная способность / мощность обработки
Производительность обработки также называется пропускной способностью, что означает количество клиентских запросов, обрабатываемых за единицу времени. Обычно пропускная способность измеряется количеством запросов в секунду или количеством страниц в секунду. С точки зрения бизнеса, пропускную способность также можно измерить количеством посетителей в день или просмотром страниц в день.
Одновременные онлайн-пользователи
Для веб-сайта, когда пользователь входит на главную страницу веб-сайта, он начинает выполнять различные операции на веб-сайте, включая просмотр веб-страниц, получение контента, отправку форм и т. д. Этот процесс Пользователи называются онлайн-пользователями. Если много таких пользователей посещают веб-сайт в один и тот же момент времени или в течение одного периода времени, эти пользователи все вместе называются одновременными онлайн-пользователями веб-сайта. В то же время другой уровень понимания онлайн-пользователей заключается в том, что система приложений в целом рассматривается как черный ящик, от уровня клиента пользователя до системы, сколько людей в целом ее используют. При выполнении тестирования производительности, если вы используете одновременных онлайн-пользователей, вы можете назвать это одновременной онлайн-нагрузкой.
Скрипт теста производительности
Скрипт разработан с помощью инструмента моделирования нагрузки. Скрипт представляет собой комбинацию некоторых кодов, он использует код для реализации действий пользователя в системе приложения. Например, вы посещаете домашнюю страницу веб-сайта, вводите имя пользователя и пароль и нажимаете кнопку входа в систему, чтобы войти в систему. Это двухэтапная операция, выполняемая пользователем в системе приложения. Сценарий содержит код для реализации этих двух шагов. Если вы хотите смоделировать загрузку 10 000 пользователей, 50% из этих 10 000 пользователей посещают домашнюю страницу, 20% регистрируются, 20% запрашивают и 10% просматривают определенную страницу, вам необходимо создать 5 скриптов соответственно Это сценарий доступа к домашней странице, сценарий регистрации, сценарий запроса и сценарий просмотра страниц.
сделка
Транзакция делится на два определения: бизнес-уровень и технический уровень. Транзакция бизнес-уровня относится к завершению полной бизнес-операции, такой как операция вывода и запроса. Техническая транзакция относится к системной операции от приложения к приложению или от приложения к базе данных. Общая бизнес-транзакция состоит из нескольких технических транзакций. В зависимости от сложности бизнес-транзакции и архитектуры системных приложений соотношение составляет примерно 1: 2–1: 10.
(1) В налоговой системе вы можете использовать «система обрабатывает бизнес-операции 100 000 пользователей каждый месяц», где TPS измеряется количеством компаний в месяц; (2) В налоговой системе вы также можете использовать «система обработает 40 000 бизнес-операций пользователей в течение 8 часов на седьмой день». TPS здесь измеряется количеством компаний в день; (3) В налоговой системе вы также можете использовать «Система должна обработать 3 операции транзакции по уплате налогов для 12 000 пользователей с 10:00 до 11:00 на седьмой день, то есть 36 000 операций транзакций по уплате налогов», где TPS измеряется количеством транзакций в час; (4 ) В налоговой системе вы также можете использовать «Система будет обрабатывать 3 типа транзакций по уплате налогов для 12 000 пользователей с 10:00 до 11:00 на седьмой день, то есть 36 000 операций транзакций по уплате налогов, каждая транзакция по уплате налогов». Чтобы отправить в среднем 10 HTTP-запросов от клиента к серверу, то есть 360 000 операций HTTP-запросов «, TPS здесь измеряется количеством запросов в час.
Точность тестирования производительности
После выполнения правильного анализа теста производительности получены правильные требования к тесту производительности, и инструменты тестирования производительности используются для разработки соответствующих сценариев тестирования производительности, разработки соответствующих сценариев тестирования производительности и выполнения теста производительности. Сценарий использует данные теста производительности, устанавливает соответствующее время обдумывания в сценарии тестирования производительности, устанавливает рабочие параметры в сценарии тестирования производительности и т. Д., Чтобы использовать инструменты автоматического тестирования производительности для имитации ситуации, в которой большое количество пользователей одновременно обращается к тестируемой системе в реальности. То есть, если инструмент тестирования производительности не используется должным образом, это приведет к неспособности точно достичь цели «моделирования реальных условий». Например, некоторые инженеры по тестированию производительности не знают, как использовать функцию «контрольной точки» при использовании инструментов тестирования производительности, поэтому они не могут найти серьезную проблему, заключающуюся в том, что большое количество виртуальных пользователей даже не входит в систему во время выполнения теста производительности. Они все еще думают, что тест производительности выполняется. Эффект хороший, проблем с производительностью тестируемой системы нет.
Веб-сервер и сервер приложений
С точки зрения непрофессионала, веб-сервер обслуживает страницы, чтобы браузер мог их просматривать, но сервер приложений предоставляет методы, которые может вызывать клиентское приложение. Чтобы быть точным, вы можете сказать: веб-серверы специализируются на обработке HTTP-запросов, но серверы приложений обслуживают бизнес-логику для приложений через множество протоколов. Веб-сервер (веб-сервер) Веб-сервер может обрабатывать протокол HTTP. Когда веб-сервер получает HTTP-запрос (запрос), он возвращает HTTP-ответ (ответ), например, отправляя обратно HTML-страницу. Чтобы обработать запрос (запрос), веб-сервер может ответить на статическую страницу или изображение, выполнить перенаправление страницы или делегировать создание динамического ответа некоторым другим программам, таким как CGI. Сценарий, сценарий JSP (JavaServer Pages), сервлеты, сценарий ASP (Active Server Pages), серверный JavaScript или некоторые другие серверные технологии. Независимо от их (примечание переводчика: скрипт) цели эти серверные программы обычно генерируют HTML-ответ (ответ) для просмотра браузером. Вы знаете, модель делегирования веб-сервера очень проста. Когда запрос (запрос) отправляется на веб-сервер, он просто передает запрос (запрос) программе, которая может обработать запрос (примечание переводчика: сценарий на стороне сервера). Веб-сервер предоставляет только среду, в которой программа на стороне сервера может быть выполнена, а ответ (сгенерированный программой) может быть возвращен, не выходя за рамки его функций. Серверные программы обычно имеют такие функции, как обработка транзакций, подключение к базе данных и обмен сообщениями. Хотя веб-сервер не поддерживает обработку транзакций или создание пулов соединений с базой данных, он может использовать различные стратегии для достижения отказоустойчивости и масштабируемости, такие как балансировка нагрузки и буферизация. (кеширование). Функции кластеризации (функции кластеризации) часто ошибочно принимают за просто функции, специфичные для сервера приложений. к
Сценарий 1. Веб-сервер без сервера приложений В этом сценарии веб-сервер независимо выполняет функцию интернет-магазина. Веб-сервер получает ваш запрос и затем отправляет его серверной программе, которая может его обработать. Эта программа ищет информацию о ценах из баз данных или текстовых файлов (плоский файл, примечание переводчика: плоский файл относится к небинарным файлам без специального формата, таким как свойства, файлы XML и т. Д.). После обнаружения программа на стороне сервера формулирует информацию о результатах в форме HTML, и, наконец, веб-сервер отправляет ее в ваш веб-браузер. Короче говоря, веб-сервер просто отвечает на HTML-страницы для обработки HTTP-запросов. к
Сценарий 2: веб-сервер с сервером приложений. Сценарий 2 аналогичен сценарию 1, является ли это веб-сервером или генерацией ответов (делегатов) на сценарий (Примечание переводчика: сервер (Серверная программа). Однако вы можете разместить бизнес-логику для определения цен на сервере приложений. Из-за этого изменения этот сценарий просто вызывает службу поиска на сервере приложений, вместо того, чтобы уже знать, как искать данные, а затем выражать их в качестве ответа. В это время, когда программа-скрипт генерирует HTML-ответ (ответ), можно использовать возвращенный результат службы. В этом сценарии сервер приложений обслуживает бизнес-логику для запроса информации о ценах на продукты. Эта функция (сервера) не определяет подробные сведения об отображении и о том, как клиент использует эту информацию. Вместо этого клиент и сервер приложений просто передают данные туда и обратно. Когда клиент вызывает службу поиска сервера приложений, служба просто ищет и возвращает результаты клиенту. Отделив его от HTML-кода, генерирующего ответ, логику ценообразования (поиска) можно многократно использовать в приложении. Другие клиенты, например кассовые аппараты, также могут позвонить в ту же службу, что и клерк, чтобы проверить клиента. В отличие от этого, служба поиска цен в сценарии 1 не может использоваться повторно, поскольку информация встроена в HTML-страницу.в целомВ модели сценария 2 веб-сервер обрабатывает HTTP-запросы (запросы), отвечая на HTML-страницы, в то время как сервер приложений предоставляет логику приложения, обрабатывая цены и доступность (запросы). к
Предупреждение (предостережения). Теперь веб-службы XML запутали границу между сервером приложений и веб-сервером. Отправляя полезную нагрузку XML (полезную нагрузку) на сервер, веб-сервер теперь может обрабатывать данные и ответ (ответ) в той же степени, что и предыдущий сервер приложений. Кроме того, большинство серверов приложений теперь включают в себя веб-серверы, а это означает, что веб-серверы можно рассматривать как подмножество серверов приложений. Хотя сервер приложений включает в себя функцию веб-сервера, разработчики редко развертывают сервер приложений в этом качестве (Примечание переводчика: эта функция относится как к функциям сервера приложений, так и Функция веб-сервера). Напротив, при необходимости они обычно настраивают веб-сервер независимо друг за другом с сервером приложений. Такое разделение функций помогает повысить производительность (простые веб-запросы (запросы) не повлияют на сервер приложений), раздельную конфигурацию (выделенный веб-сервер, кластеризацию и т. Д.) И предоставить лучший продукт. ВыбратьПокинуть комнату。
Узкое место в производительности
Узкое место производительности на самом деле является дефектом производительности программного обеспечения, наиболее популярным пониманием является «узкое место производительности».
(1) Узкое место производительности оборудования в основном связано с проблемами ЦП и ОЗУ. Например, во время анализа требований к программному обеспечению и эскизного проектирования было определено, что на сервере базы данных требуется 6 ЦП и 12 ГБ памяти, но в ходе теста было обнаружено, что непрерывное использование ЦП превышает 95%. В это время можно считать, что оборудование появилось. Узкое место в производительности.
(3) Узкие места в производительности приложений обычно относятся к приложениям, недавно разработанным разработчиками. Например, приложение, разработанное на Java или C и развернутое на сервере приложений для обработки запросов пользовательских транзакций. Например, разработчик разработал программу обработки платежей. В ходе тестирования было обнаружено, что программа обработки платежей может обрабатывать только параллельные платежные запросы, отправленные пользователем последовательно, и не может обрабатываться параллельно, что приводит к времени отклика обработки платежной транзакции. Очень долго, на данный момент можно считать, что в приложении есть узкое место в производительности.
Как измерять производительность блокчейн сетей. Основные метрики
Существует много метрик, относящихся к логике и качеству работы блокчейна. Они помогают определить узкие места в коде и найти логические и оптимизационные проблемы в алгоритмах консенсуса и финальности в блокчейнах. Любая разработка распределенных систем, в том числе блокчейнов, требует анализа работы сразу множества узлов. Они позволяют команде проекта следить за состоянием всей блокчейн-сети, видеть проблемы с отдельными нодами, детектировать появление DoS атак на сеть и многое другое. Давайте рассмотрим основные из них. Let’s dive in.
“Transactions-per-second”
В случае распределенных систем, TPS — это очень капризное и неоднозначное число, которое не всегда отражает реальное качество предоставляемого пользователям сервиса. Измерения TPS пришли к нам из распределенных баз данных. TPS в базах данных — это некоторые стандартизованные для теста транзакции или их наборы (сколько то INSERT, сколько-то UPDATE, столько DELETE-ов на фоне постоянных SELECT) для жестко заданной конфигурации кластера или вообще на одной машине. Эти метрики обычно дают только приближенные оценки производительности распределенных БД или блокчейнов, так как время процессинга транзакции может сильно варьироваться в зависимости от множества факторов.
Базы данных, ориентированные на консистентность (см. “CAP-теорема”) не фиксируют транзакцию, пока не получат достаточное число подтверждений от других нод и это медленно. А базы данных, ориентированные на Availability, считают успешной транзакцию, которую просто удалось записать на диск. Они сразу отдают клиенту обновленные данные и это очень быстро (хотя в будущем, эта транзакция может быть откачена назад). Также, если транзакции, используемые в бенчмарке, обновляют лишь одну ячейку с данными, TPS явно будет выше, чем в случаях, когда транзакции могут затрагивать много ячеек и блокировать друг друга. Алгоритмы работы с этими блокировками в каждой БД реализованы по своему — как раз поэтому мы и не видим “соревнований по TPS” между Oracle, MSSQL, PostgreSQL с одной стороны и MongoDB, Redis, Tarantool с другой — уж очень разные внутренние механизмы и разные задачи.
По моему мнению, “измерить TPS” блокчейна означает провести полный комплекс измерений его производительности:
Чтобы говорить о заветных “transactions per second”, нужно описать все условия (число валидаторов, их гео-распределение, уровень packetloss и т.п.) и описать логику бенчмаркинга. В блокчейнах просто накатить транзакцию на внутреннюю БД не означает ее принятие консенсусом. Например, в случае c Proof-of-Work, статистически, транзакции не завершаются вообще никогда, и, если транзакция включена в блок на одной машине, это не означает, что она будет принята всей сетью (например, в случае победы другого форка).
Если в блокчейне есть дополнительный алгоритм обеспечения финальности транзакций (EOS, Ethereum 2.0, парачейны Polkadot, использующие консенсус с финальностью GRANDPA), то временем процессинга транзакции можно считать промежуток между тем, как нода “увидела” транзакцию и следующим финализированным блоком, куда эта транзакция была включена. Такие, более близкие к реальности “TPS” нечасто встретишь в обещаниях проектов. Они, естественно, ниже описанных в Whitepaper-ах, но зато максимально информативны.
Так что еще раз предупреждаю, в термин “TPS” может быть вложено очень много разных смыслов. Будьте скептичны и требуйте подробностей.
Метрики, специфичные для блокчейн сетей
Local TPS
Число обработанных нодой транзакций и max/avg/min время их обработки на локальной ноде очень удобно измерять, так как функции, выполняющие эту операцию, обычно явно выделены в коде. Можно просто измерить, сколько времени транзакция работала, обновляя state database. Эти транзакции, возможно, пока не приняты консенсусом, но уже прошли валидацию, и нода уже может отдавать клиенту обновленные данные (рассчитывая, что не появится форк цепочки).
Эта метрика не очень честная: если в качестве основной будет выбран другой форк цепочки, то статистику по откаченным транзакциям нужно тоже откатывать. Но для тестирования этим почти всегда можно пренебречь.
Часто, именно это число пишут в кратких отчетах: “у нашего блокчейна вчера получилось 8 000 tps”, так как ее просто измерить — достаточно одной запущенной ноды и скрипта, который ее нагружает. В этом случае отсутствует сетевая задержка, которая замедляет достижение сетью консенсуса, а метрика показывает быстродействие state database без влияния сети. Это число не является реальной пропускной способностью блокчейн-сети, но показывает предел, к которому она будет стремиться, если консенсус и сеть будут достаточно быстрыми.
Результат работы любой блокчейн-транзакции — несколько атомарных обновлений storage. Например, платежная транзакция в Bitcoin — это удаление нескольких старых UTXO (delete) и добавление нескольких новых UTXO (insert), а в Ethereum — это исполнение короткого кода смарт-контракта и, опять же, обновление нескольких пар “ключ-значение”. Количество этих “атомарных” операций записи могут быть отличной метрикой, позволяющей определять узкие места в storage-подсистеме и внутренней логике транзакций.
Также, блокчейн-ноды могут быть реализованы на нескольких языках программирования — так надежнее. Это нужно учитывать, оценивая производительность сети, например, нода Ethereum существует в имплементациях на Rust и Go. Другие блокчейны также стремятся иметь дополнительные имплементации для надежности.
Local produced blocks amount
Эта несложная метрика показывает, какой валидатор сколько блоков произвел. Она является продуктом консенсуса и ее можно считать основной для оценки “полезности” для сети отдельных валидаторов.
Зарабатывая на каждом блоке, валидаторы заинтересованы в стабильной работе и безопасности своих машин. Это число помогает определить, кто из валидаторов-кандидатов наиболее квалифицирован, защищен и подготовлен для работы в публичной сети с активами реальных пользователей. Значение метрики можно публично проверить, просто скачав блокчейн и посчитав кто сколько блоков произвел.
Finality и Last Irreversible Block
В сетях с явно реализованой финальностью (EOS, Ethereum, Tendermint, Polkadot, etc ) помимо основного, быстрого консенсуса (в котором достаточно одной подписи валидатора на блок) часть блоков требует согласования группой валидаторов. Эти блоки считаются финальными, а алгоритм сбора подписей — финальностью. Задача финальности — сделать так, чтобы все транзакции, включенные в блокчейн до финализированного блока уже никогда не были бы откачены и не заменены другим форком цепочки. Это защита от атаки double spend в proof-of-stake сетях, и способ быстро, за несколько секунд, вернуть пользователю надежное подтверждение криптовалютной транзакции.
С точки зрения пользователя блокчейна, транзакция завершается не в тот момент, когда он принята нодой, а когда появился блок, который финализирует цепочку, в которой находится транзакция. Чтобы финализировать блок, валидаторы должны получить этот блок по p2p сети, и обменяться подписями друг с другом. Именно здесь и проверяется реальная скорость блокчейна, ведь пользователю важен именно момент финализации блока с его транзакцией, а не просто принятие и запись ее на диск одной из нод.
Алгоритмы финальности также различаются, пересекаются и объединяются с основным консенсусом (to read: Casper в Ethereum, Last Irreversible Blocks в EOS, GRANDPA в Parity Polkadot и их модификации, например MixBytes RANDPA).
Для сетей, где финализируется не каждый блок, полезной метрикой является отставание последнего финализированного блока от текущего последнего блока. Это число показывает, насколько отстают валидаторы, согласуя правильную цепочку. Если отставание большое, значит алгоритм финализации требует дополнительного анализа и оптимизации.
Другие блокчейн-метрики
Остальные метрики обычно сильно зависят от типа консенсуса, поэтому представлять их в числе основных не очень правильно. В числе таких параметров, например: количество форков цепочки, их длина в блоках, заполняемость блоков транзакциями и т.п. По ним можно определить ситуации разделения сети или быстро локализовать проблемы конкретного валидатора.
P2P слой
Крайне важно помнить о промежуточной основе блокчейн-сетей — peer-to-peer подсистеме. Именно она вносит неопределенные задержки в доставке блоков и транзакций между валидаторами. Когда количество валидаторов небольшое, они локализованы, списки peer-ов жестко прописаны, все работает хорошо и быстро. Но стоит добавить валидаторов, разнести ноды географически и сэмулировать packetloss, как в “tps” появляются существенные провалы.
Например, при тестировании консенсуса EOS с дополнительным алгоритмом finality, увеличение числа валидаторов даже до 80-100 машин, разнесенных по четырем континентам несильно повлияло на скорость достижения finality. В то же время, увеличение packetloss сильно повлияло на отставание финальности, что говорит о необходимости дополнительной настройки p2p слоя для большей устойчивости к потере сетевых пакетов, а не к большому latency. К сожалению, различных настроек и факторов велико, поэтому, только бенчмарки позволяют понять эффективное количество валидаторов, которые обеспечивают достаточно комфортную скорость работы блокчейна.
Устройство p2p подсистемы можно понять из документации, например, по libp2p или документацию по протоколу Kademlia или BitTorrent.
Важными метриками для p2p являются:
Например, большое число misses при обращении к данным означает, что запрашиваемыми данными обладают лишь небольшое число нод, и они не успевают раздать их всем желающим, а объем принятого/отданного p2p трафика позволит установить ноду, имеющую проблемы с сетевой конфигурацией или каналом.
Системные метрики блокчейн-нод
Стандартные системные метрики блокчейн-нод описаны в большом числе источников, поэтому опишу их кратко. Их роль — помогать искать узкие места и ошибки во всех частях кода, показывая какие подсистемы ноды наиболее загружены и какими задачами.
Говорят о том, сколько вычислений выполняет процессор. Если CPU load высокий, значит нода что-то вычисляет, активно использует логику или FPU (в блокчейнах почти не используется). В блокчейнах это может быть, например, из за того, что нода проверяет электронные подпиcи, процессит транзакции с тяжелой криптографией или делает сложные вычисления.
CPU можно “разрезать” ещё на несколько полезных метрик, чтобы понять, какие части кода наиболее затратны. Например, system — код ядра, user — пользовательские процессы, io — ожидание i/o от медленных внешних устройств(диск/сеть) и т.д. Вот хорошая статья по теме.
Memory
Современные блокчейны используют key-value базы-данных (LevelDB, RocksDB), которые постоянно держат в памяти “горячие” данные. Как и в любых нагруженных сервисах, здесь всегда возможны утечки памяти в результате ошибок или целенаправленных атак на код ноды. Если потребление нодой памяти растет, либо резко увеличилось, то, скорее всего, это вызвано увеличением числа ключей в state database, большими очередями транзакций, либо увеличением числа сообщений между разными подсистемами ноды. Недозагрузка памяти может говорить о возможном увеличении лимитов на данные в блоках или максимальную сложность транзакции.
Для full-нод, котоhttps://habrastorage.org/webt/qa/sn/m5/qasnm5bougkjuagneevjkpg9x0w.pngрые отвечают клиентам сети, важными также являются метрики файлового кеша. Клиенты обращаются к различным частям state database и логу транзакций. Это порождает подъем с диска старых блоков, которые могут вытеснять новые блоки, что, в свою очередь замедляет отдачу ответов клиенту.
Network
Основные внутренние метрики network — это объем трафика в байтах, число отправленных и принятых сетевых пакетов по каждому и протоколов, packet loss ratio. В блокчейнах тим метрикам часто не уделяют большого внимания, т.к. блокчейны пока еще не обрабатывают траназакции со скоростью в 1 Gbit/sec.
Существуют блокчейн-проекты, позволяющие пользователям делиться своим wifi или предоставлять услуги хранения и передачи файлов или сообщений. При тестировании таких сетей, количество и качество трафика через сетевой интерфейс становится крайне важными метриками, так переполненный сетевой канал влияет на все остальные сервисы на машине без исключения.
Storage
Дисковая подсистема — это самый медленный компонент в любых сервисах и часто бывает причиной серьезных проблем с производительностью. Избыточное логгирование, неожиданно пришедший backup, неудобный паттерн чтения/записи, большой суммарный объем блокчейна — все это может привести к существенному замедлению работы ноды или к серьезно завышенным требованиям к железу.
Лог транзакций технически можно рассматривать как WAL (WAL ) для state database, поэтому важны те метрики storage, которые позволяют искать узкие места в механизмах современных key-value баз данных. Это количество read/write IOPS, max/min/avg latency и множество других метрик, помогающих оптимизировать дисковые операции.
Заключение
Итак, мы рассмотрели несколько наборов метрик, которые могут давать очень ценную информацию о работе блокчейн сети и возможностях для ее оптимизации. Подытоживая, можно собрать их в три группы:
Каждая из групп важна по своему, так как в каждой из подсистем возможно существование ошибок, ограничивающих работу других компонентов, а замедление даже небольшого количества валидаторов может оказывать серьезное влияние на всю сеть. Также, наиболее хитрые ошибки в алгоритмах консенсуса и финальности возникают только при большом потоке транзакций или изменении параметров консенсуса. Для их анализа требуются воспроизводимые условия тестирования и сложные сценарии нагрузки.
Разработка блокчейнов — это всегда оркестрация несколькими машинами, скрипты для раскладки конфигов и согласованного запуска нод и бенчмарков, сервера для сбора метрик и логов со всех машин. Поэтому, при разработке своего блокчейна, предусмотрите найм квалифицированного девопса — он окажет неоценимую поддержку команде разработки. Удачи!