Tps что это такое
Tps что это такое
Смотреть что такое «TPS» в других словарях:
Tps — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. <<
TPS — may refer to:*Vincenzo Florio Airport, also known as Trapani Birgi Airport, IATA airport code *Tall poppy syndrome, used in Australia and New Zealand to describe what is seen as a levelling social attitude *Telephone Preference Service, a UK opt… … Wikipedia
TPS — steht für den Biokunststoff Thermoplastische Stärke Trassenpreissystem von Eisenbahninfrastrukturunternehmen das Toyota Produktionssystem den finnischen Eishockeyverein Turun Palloseura (Eishockey) den finnischen Fußballverein Turun Palloseura… … Deutsch Wikipedia
TPS — Temporary Protected Status Nolo’s Plain English Law Dictionary. Gerald N. Hill, Kathleen Thompson Hill. 2009 … Law dictionary
TPS — puede referirse a: Sistema de procesamiento de transacciones o Transaction Processing System, un sistema informático de gestión de datos. Sistema de producción Toyota, o Toyota production system. Videojuego de disparos en tercera persona o Third… … Wikipedia Español
TPS — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. Sigles d’une seule lettre Sigles de deux lettres > Sigles de trois lettres Sigles de quatre lettres … Wikipédia en Français
TPS — 1996) один из первых полноценно трёхмерных шутеров от первого лица В Википедии есть проект «Игры» 3D шутер жанр компьютерных игр. Название произошло совмещением понятий «3D» (три измерен … Википедия
tps — I tps [Abk. für Triangles per Second, dt. »Dreiecke pro Sekunde«], Grafikverarbeitung: Maßeinheit für die Leistungsfähigkeit von Grafikprozessoren (3D Engines) beim Shading. Das Bearbeiten von einem Dreieck bzw. Polygon in einer Sekunde… … Universal-Lexikon
TPS — Transactions per second. Chicago Mercantile Exchange Glossary * * * TPS UK US noun PRODUCTION ► ABBREVIATION for TOYOTA PRODUCTION SYSTEM(Cf. ↑Toyota Production System) … Financial and business terms
TPS — • Technical Publishing Software • TeleProcessing Services • Thermal Protection System • Task Parameter Synthesizer ( > IEEE Standard Dictionary ) • Television Par Satellite französischer Satellitenfernsehenanbieter, auch Internet Provider in… … Acronyms
Tps. — T. Pos., Tps. сокр. от Tenorposaune … Словарь иностранных музыкальных терминов
Как измерять производительность блокчейн сетей. Основные метрики
Существует много метрик, относящихся к логике и качеству работы блокчейна. Они помогают определить узкие места в коде и найти логические и оптимизационные проблемы в алгоритмах консенсуса и финальности в блокчейнах. Любая разработка распределенных систем, в том числе блокчейнов, требует анализа работы сразу множества узлов. Они позволяют команде проекта следить за состоянием всей блокчейн-сети, видеть проблемы с отдельными нодами, детектировать появление 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 и множество других метрик, помогающих оптимизировать дисковые операции.
Заключение
Итак, мы рассмотрели несколько наборов метрик, которые могут давать очень ценную информацию о работе блокчейн сети и возможностях для ее оптимизации. Подытоживая, можно собрать их в три группы:
Каждая из групп важна по своему, так как в каждой из подсистем возможно существование ошибок, ограничивающих работу других компонентов, а замедление даже небольшого количества валидаторов может оказывать серьезное влияние на всю сеть. Также, наиболее хитрые ошибки в алгоритмах консенсуса и финальности возникают только при большом потоке транзакций или изменении параметров консенсуса. Для их анализа требуются воспроизводимые условия тестирования и сложные сценарии нагрузки.
Разработка блокчейнов — это всегда оркестрация несколькими машинами, скрипты для раскладки конфигов и согласованного запуска нод и бенчмарков, сервера для сбора метрик и логов со всех машин. Поэтому, при разработке своего блокчейна, предусмотрите найм квалифицированного девопса — он окажет неоценимую поддержку команде разработки. Удачи!
Производственная система на примере TPS
Производство — процесс изготовления товаров или предоставления услуг для потребителей. Это процесс, который использует нематериальные ресурсы, такие как идеи, творчество, исследования, знание, мудрость и т. д. Обычно, это ручной, механический или химический процесс, который преобразует полученные на входе материальные ресурсы, такие как сырье, полуфабрикаты или комплектующие в готовую продукцию или товар, имеющие ценность для потребителя.
В производственном процессе используются помещения, производственное оборудование и инструменты, людской труд, различные ресурсы — вода, электроэнергия, расходные материалы. В производственный процесс включены процессы обработки заказов, закупки сырья и материалов, складирования, транспортной логистики и т. п. Все эти процессы можно объединить в производственную или перерабатывающую подсистему.
Производственный процесс не может существовать без управляющего и вспомогательных (поддерживающих) процессов, которые имеют ценность только для самого предприятия. Вспомогательные процессы, например, обслуживание оборудования или IT-структуры предприятия, управление персоналом.
Таким образом, производственная система может быть определена как:
«Совокупность методов, процедур и планов, включающая в себя все функции, необходимые для переработки информации и сырья на входе в готовые товары/услуги на выходе».
Если планы не выполняются, намеченные цели не достигаются, значит, производственная система не работает.
Производственная система Toyota
Производственная система Toyota (TPS), погруженная в философию «полной ликвидации всех потерь», охватывает все аспекты производства для достижения максимальной эффективности. К потерям относят все, что не добавляет ценности для потребителя: потери из-за ожидания, ненужной транспортировки, лишних запасов, лишних этапов обработки, перепроизводства и брака. Все эти потери переплетаются друг с другом, создавая еще больше потерь, что, в конечном счете, отрицательно влияет на управление самой корпорацией.
Производственная система Toyota восходит своими корнями к автоматическому ткацкому станку Сакичи Тойода (1867-1930), который является автором одной из основополагающих концепций системы «Дзидока» (Jidoka) – производство высококачественной продукции.
TPS развивалась и дополнялась на протяжении многих лет путем проб и ошибок. Второй из основных принципов — концепция «Точно в срок» (Just-In-Time или JIT), разработанная Киичиро Тойода (1894-1952), основателем (и вторым президентом) Toyota Motor Corporation.
Дзидока и андон
Революционный автоматический ткацкий станок, изобретенный Сакичи Тойода не только позволил автоматизировать работы, которые раньше выполнялись вручную, но также станок останавливался сам в случае обнаружения поломки, чтобы предотвратить выпуск дефектной продукции. Если оборудование останавливается самостоятельно, возникает необходимость обратить внимание оператора на эту ситуацию. Поэтому важной частью производственного процесса стал «Андон» (Andon) — система сигнализации (световое табло), позволяющая считывать информацию с одного взгляда. Это позволило наблюдать за работой большого количества станков всего одному оператору. В результате, Сакичи удалось добиться чрезвычайного повышения производительности и эффективности работы.
Развитием системы дзидока стала «человеческая автоматизация». Частью сигнальной системы андон является специальный шнур, дернув за который, каждый рабочий может остановить конвейер. Роль автоматического стопора станка на конвейере выполняет каждый рабочий. Не успел завернуть гайку — дерни за шнур. Главное, что никто не станет ругать и наказывать этого рабочего. Наоборот, похвалят, что не передал дальше по конвейеру брак. Причину же попытаются установить, и это называется «Хансей» – постоянный анализ.
Точно в срок
Киичиро Тойода, который унаследовал эту философию, реализовал свое убеждение, что «идеальные условия для создания вещи создаются, когда машины, оборудование и люди работают вместе, чтобы добавить ценность, не создавая никаких отходов». Он придумал методики и технологии для устранения отходов между операциями и процессами. В результате, родился метод JIT.
«Точно в срок» означает создание «только того, что нужно, когда это необходимо, и в необходимом количестве». Например, чтобы эффективно производить большое количество автомобилей, который может состоять из 30000 частей, необходимо создать детальный план производства, который включает в себя и закупки запчастей. При этом каждая из 30 тысяч деталей должна поступить на определенное рабочее место на сборочном конвейере «в момент, когда это необходимо, и в необходимом количестве». В результате, устраняются потери и необоснованные заявки, что приводит к повышению производительности.
Канбан
В производственной системе Toyota имеется уникальный метод управления производством «Канбан» (Kanban), который играет важную роль. Систему канбан также называют «Метод супермаркета», потому что идея использования контрольных карт была заимствована у американских супермаркетов. На контрольных картах продуктов указывается информация, например, название продукта, код товара и место хранения. В Toyota, когда процесс обращается к предшествующему процессу для получения запчастей, он использует канбан, чтобы сообщить, какие части были использованы.
Канбан позволяет процессу (заказчик) обратиться к предыдущему процессу (супермаркет) для получения необходимых частей, когда они необходимы и в необходимом количестве. Чтобы на предшествующих этапах не делать лишних частей и не доставлять их на следующий этап. На рисунке представлена иллюстрация принципа работы системы Канбан с двумя типами канбанов: карточки производственного заказа (зеленые) и карточки отбора комплектующих (коричневые).
Однако, оригинальные методы и процессы — это лишь одна сторона производственной системы Тойота. Вот, что говорит экс-вице-президент Toyota Group Ясухито Ямаучи о производственной системе TPS: «Суть TPS заключается в стандартизации процессов и системе постоянных улучшений (кайдзен или кайзен). И оба эти понятия неразрывно связаны с вопросами мотивации людей. Кстати, в Toyota принято говорить именно о людях, а не о персонале. Это отражает наше уважение к тем, кто работает в компании. Кроме того, основные факторы эффективности производственной системы – это: инициатива, находящаяся в руках рядовых сотрудников, делегирование полномочий, делегирование задач, предоставление рабочим свободы для принятия решений в разумных пределах, а также кайдзен. Среди этих пяти факторов нет ни одного, который можно было бы рассматривать в отрыве от мотивации и вовлеченности персонала. От того, насколько охотно люди хотят работать, насколько близко к сердцу они принимают происходящее в компании, напрямую зависят все пять основных факторов построения производственной системы». Полный текст интервью находится здесь.
Дао Тойота
Широко известна книга американского профессора Джеффри Лайкера «Дао Toyota: 14 принципов менеджмента ведущей компании мира». Автор 20 лет посвятил изучению опыта Тойота и сформулировал свои выводы в этой книге.
Практикуя философии «Ежедневные улучшения» и «Хорошее мышление, хорошие продукты», TPS превратилась во всемирно признанную производственную систему. Тойотовцы не сделали из своей системы тайны. Они готовы поделиться своим опытом со всеми. TPS явилась прообразом популярного во всем мире и в России Бережливого производства (Lean). И сегодня все подразделения Тойоты продолжают улучшать TPS день и ночь, чтобы обеспечить ее дальнейшее развитие — кайзден.
В последнее время «дух Toyota делать вещи» называется «Дао Toyota». Дао — это путь, но не в значении «дорога», а в более широком философском смысле — дело жизни. Он был принят не только внутри японской компании и в автомобильной промышленности, но и в производственной деятельности по всему миру, и продолжает развиваться во всем мире.