Как тестировать RPC-провайдеров для вашего рабочего процесса

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

Именно поэтому мы описали методологию и создали Alchemy rpcbench для ее реализации: единый бинарный файл, который тестирует любой набор RPC-провайдеров с вашего собственного компьютера на тех методах, которые действительно вызывает ваше приложение. Сама методология работает с любыми инструментами, которые у вас уже есть.

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

Что следует измерять при тестировании RPC-провайдера?

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

Параметр

Что он измеряет

Как это измерить

Задержка под нагрузкой

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

Проведите серию производственных тестов RPS. Зафиксируйте показатели p95 и p99 для каждого из них, а также частоту сбоев и ошибок 429 рядом с ними

Отставание блоков

Насколько быстро провайдер доставляет новые блоки

Согласованность данных

Можно ли получить данные блока в момент его объявления

На каждой новой вершине запрашивайте блок, его логи, чеки и транзакции. Убедитесь, что они совпадают

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

Что из этого следует измерять в первую очередь?

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

Если вы создаете

Измеряйте в первую очередь

Что находится под угрозой

DEX или ончейн-модуль котировок (например, Valantis)

Отставание блоков, затем p99 для eth_calls, выполняемых вашей логикой ценообразования

Вы формируете цену по блоку, который уже сместился, или ваша котировка поступает после закрытия спреда

Протокол кредитования с ликвидациями (например, Aave)

Отставание блоков и согласованность данных, затем p99 для чтения вашего коэффициента здоровья и цен

Ликвидация срабатывает на блок позже или считывает позицию до того, как данные этого блока станут доступны

Оракул или служба на основе событий (например, RedStone)

Отставание блоков и согласованность данных, затем p99 для eth_getLogs и eth_call

Вы пропускаете триггер, потому что логи вернулись неполными

Индексатор или бэкенд кошелька (например, Struct)

p95 при вашей пиковой нагрузке, с частотой сбоев и ошибок 429 рядом с ней

Загрузка исторических данных зависает, или балансы устаревают, пока пользователи торгуют

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

Как запустить заслуживающий доверия RPC-тест?

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

Настройка запуска

Правило

Почему это важно

Тестируйте методы, которые реально вызывают ваше приложение, и используйте один и тот же пейлоад для всех провайдеров

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

Используйте частоту RPS, похожую на продакшн

Провайдеры, выглядящие одинаково при 50 RPS, могут сильно различаться при 300. Следите и за пропускной способностью, так как широкий диапазон eth_getLogs забивает ваш канал и имитирует деградацию

Определите, что считается успехом

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

Запуск

Правило

Почему это важно

Прогревайте каждого провайдера одинаково

Перед каждым методом для каждого провайдера отправляйте запросы в течение десяти секунд на полной скорости и отбрасывайте их. На основе времени, а не количества запросов: 10 запросов при 500 RPS — это 20 мс прогрева

Держите расписание, следите за собственным компьютером

Помечайте запуск флагом, если p99 отклонения отправки превышает 5 мс за 1000 выборок. В этот момент вы измеряете производительность своего компьютера

Тестируйте провайдеров по одному

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

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

Чтение результатов

Правило

Почему это важно

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

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

Запустите тест дважды, с того же места, где работает ваша система

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

Что такое Alchemy rpcbench?

Alchemy rpcbench — это единый бинарный файл, который запускает всю описанную выше методологию с вашего компьютера с использованием ваших собственных ключей. Он отправляет запросы только на эндпоинты из вашей конфигурации, а созданный им HTML-отчет отправляется напрямую вам.

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

Значения по умолчанию — это отправная точка. Раздел workload: позволяет подставить ваши собственные параметры и методы:

yaml

Скопировано

workload: - method: eth_call params: - to: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" # контракт на вашем пути котировок data: "0x18160ddd" # и ваши calldata - "$anchor" # закрепленный блок, о котором спрашивают каждого провайдера

Шаги изменения частоты, длительность, тайм-аут и окно отставания блоков настраиваются аналогичным образом, а предварительный проход оценивает стоимость запуска в запросах, времени и пропускной способности до того, как какая-либо нагрузка покинет ваш компьютер. Эта стоимость измеряется в вычислительных единицах Alchemy, поэтому воспринимайте ее как проверку объема.

Каждый запуск записывает JSON-файл, агрегированные данные в формате CSV и автономную HTML-панель управления. Инструмент не выдаст цифры, за которые не может ручаться. Недостаточные выборки, троттлинг провайдера или отставание компьютера — все это помечается в самом верху.

Тест, прошедший проверку, дает вам четыре результата в следующем порядке:

Что вы получаете

О чем это говорит

Вердикт о достоверности

Стоит ли вообще ссылаться на этот запуск. Прочитайте это в первую очередь

Сравнения

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

Задержка по методам

p50, p90, p95 и p99 на каждом шаге интенсивности, а также показатели успешности, неудач и ошибок 429 рядом с ними

Отставание блоков и согласованность

Кто первый объявил о каждом блоке, насколько отстали остальные, пропущенные блоки и были ли данные каждого хеша доступны для обслуживания

О чем эта методология умалчивает

• Один регион ничего не говорит о другом. Если ваша система работает в другом месте, запускайте тест оттуда.
• Отставание блоков измеряется относительно самого быстрого провайдера, которого вы тестировали, а не истинной вершины блокчейна.
• Методы выполняются по очереди, поэтому запуск никогда не является точным повторением вашего реального микса трафика.
• Один запуск — это всего лишь одна точка данных. Мы настоятельно рекомендуем проводить несколько запусков для получения надежного сигнала о производительности, поскольку на результаты может влиять множество факторов, включая проблемы во всей сети.
• Инструмент Alchemy rpcbench предназначен только для сетей EVM и поддерживает одну сеть за один запуск.

Как получить доступ к Alchemy rpcbench?

Alchemy rpcbench находится на стадии закрытого альфа-тестирования. Заполните эту форму, чтобы запросить доступ!

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

Часто задаваемые вопросы

Как следует сравнивать RPC-провайдеров?

Запустите одну и ту же нагрузку для каждого провайдера из региона, где работает ваша система, используя методы, которые она действительно вызывает. Отправляйте запросы по фиксированному расписанию, тестируйте провайдеров по очереди и зафиксируйте один блок, чтобы все отвечали на один и тот же вопрос. Изучайте результаты метод за методом, сопоставляя показатели сбоев и ограничений частоты с каждым значением задержки, а затем повторите тест в другое время. Если вы не хотите создавать такой инструмент самостоятельно, обратитесь к нам для получения доступа к Alchemy rpcbench.

В чем разница между задержкой RPC, отставанием блоков и согласованностью данных?

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

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

Да, и вам не нужно верить нам на слово. Ни один участок кода в Alchemy rpcbench не разветвляется в зависимости от того, с каким провайдером он взаимодействует, поэтому специфическим для провайдера тайм-аутам или попыткам повтора негде спрятаться. Укажите любому агенту по программированию на ваш клон репозитория вместе с аудиторским запросом из README, и он проверит все за вас. Инструмент запускается на вашем компьютере с использованием ваших ключей, а результаты никогда не покидают вашу папку вывода.

Стоит ли выбирать RPC-провайдера на основе единого общего показателя производительности?

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

Откуда следует запускать бенчмарк RPC?

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

Сколько времени занимает выполнение бенчмарка RPC?

Время выполнения зависит от того, как вы настроите тест, но конфигурация по умолчанию занимает около двух часов. Вы можете настроить и запустить тест менее чем за 10 минут. Конфигурация, поставляемая с Alchemy rpcbench, отправляет 280 000 запросов на провайдера в сети Ethereum по семи методам и трем шагам интенсивности примерно за 48 минут, а окно отставания блоков добавляет еще один час. Провайдеры работают по очереди, поэтому фаза задержки увеличивается в зависимости от их количества. Запланируйте на это полдня, поскольку для достоверности нужны выборки.

Нужен ли мне WebSocket-эндпоинт для тестирования RPC-провайдеров?

Для задержки — нет. Для отставания блоков и согласованности данных — да, поскольку оба эти показателя зависят от eth_subscribe и подписки на newHeads. Вам также потребуется как минимум два провайдера для измерения отставания блоков, так как этот параметр определяет, кто первый объявил о каждом блоке.

Каких RPC-провайдеров я могу тестировать?

Любого провайдера с эндпоинтом EVM JSON-RPC в тестируемой сети. Вы предоставляете URL-адреса и ключи, при этом ни сам метод, ни инструмент не зависят от того, кто является провайдером.

Публикует ли Alchemy собственные бенчмарки RPC?

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