Большинство проблем с производительностью не заявляют о себе сбоем.
Они приходят как нерешительность.
Вот что сегодня привлекло моё внимание во время тестирования Newton Mainnet Beta.
Один запрос был повторён один раз перед завершением. Ошибок нет. Сообщений о предупреждениях нет. Просто пауза, которая длилась достаточно долго, чтобы заставить меня задуматься, не попал ли я на загруженный узел.
Моё первое объяснение было очевидным: недостаточная пропускная способность.
Сети загружены. Узлы испытывают неравномерную нагрузку. Повторы случаются каждый день. Я почти списал это на случайность, даже не подумав снова.
Но чем дольше я наблюдал за потоком, тем менее убедительным становилось это объяснение.
Загрузка завершилась ровно так, как ожидалось.
Хранилище подтвердило данные.
Регистрация появилась вовремя.
А затем, почти незаметно, всё замедлилось, прежде чем задача стала доступна для выполнения.
Ничего не было сломано.
Ничего не выглядело нездоровым.
Ритм просто изменился.
Это важно, потому что бета-версия Newton's Mainnet не рассчитана исключительно на немедленное завершение. Проверка политики находится между принятием и выполнением, а значит заметная задержка не обязательно является признаком сбоя. Иногда сеть делает больше работы, чем пользователь реально может увидеть.
Это осознание напомнило мне нечто совершенно не связанное с происходившим ранее в тот же день.
Я заключил сделку, потому что подтверждение заказа появилось почти мгновенно. Секунды спустя я обнаружил, что доступная ликвидность была далеко не такой глубокой, как я предполагал.
Заказ был подтверждён.
Качество выполнения — другая история.
Две совершенно разные системы.
Один и тот же урок.
Подтверждение создаёт уверенность.
Выполнение раскрывает реальность.
Если смотреть на Ньютон через эту призму, последовательность ощущается не как одна транзакция, а скорее как цепочка независимых контрольных точек:
Загрузка → Хранилище → Регистрация → Распространение → Проверка политики → Подписанное подтверждение → Выполнение → Повторное использование
Если рассматривать каждую стадию отдельно, всё выглядело благополучно.
Ожидание жило в переходах.
Вот это я и считаю интересным.
Мы тратим много времени на измерение пропускной способности, оборудования и пропускной способности канала, потому что это легко представить. Гораздо меньше внимания уделяют синхронизации, окнам верификации, состоянию модели и таймингу очереди — невидимым механизмам, которые определяют, насколько гладко на самом деле ведут себя распределённые системы.
Когда разные операторы обрабатывают нагрузки по чуть различающимся графикам, каждый компонент может работать корректно, при этом общее впечатление всё равно остаётся несогласованным.
Никаких тревог.
Не было неудачных транзакций.
Всего несколько дополнительных секунд, которые незаметно меняют ощущение от системы.
Это те типы узких мест, которые редко видны на дашбордах, но становятся очевидными любому, кто достаточно долго взаимодействует с сетью.
Я всё ещё не уверен, что эти краткие паузы важны при обычном использовании.
Возможно, что нет.
Настоящее испытание будет позже.
Что происходит после успешной кампании, крупного запуска продукта или внезапной волны принятия, когда тысячи агентов, пользователей и автоматизированных хранилищ начинают одновременно подавать работу?
Эти незаметные паузы остаются скрытыми под поверхностью?
Или же они превращаются в то узкое место, которое в итоге замечают все?
Вот на какой вопрос я обращаю пристальное внимание.