Comments 7
Сторона клиента не должна учитываться т к параметр tps относится лишь к магистральной части любой сети ( телекоммуникации, интернет, p2p,,, ). Когда запрос (сигнал) попадает в магистральную сеть (ядро ) здесь этот параметр важен.
я считаю это не совсем честно по отношению к клиенту сети. Почему «последняя миля» не учитывается? Если взять например блокчейн, где клиенты выполняют массивные вычисления, или при получении некоторых данных должны их расшифровать, накатить на свои базы, или пообщаться с другими клиентами — то это может быть значимый кусок производительности всей сети. Вы можете получить ситуацию «алло шеф, у меня транзакции по полминуты висят», а в ответ: «ничего не знаем, у нас по графику 1000 tps в магистральной сети».
Есть еще проекты где клиенты соединяются между собой, а еще есть L2 решения — когда одна цепочка коммитит изменения и диспуты в вышестоящую L1 цепочку — в этих случаях с производителностью все совсем сложно. Так что клиентскую часть в децентрализованных сетях имеет смысл учитывать. В традиционных системах клиент обычно ничего серьезного не делает, шлет мелкие запросы да качает данные, поэтому их и не измеряют.
Есть еще проекты где клиенты соединяются между собой, а еще есть L2 решения — когда одна цепочка коммитит изменения и диспуты в вышестоящую L1 цепочку — в этих случаях с производителностью все совсем сложно. Так что клиентскую часть в децентрализованных сетях имеет смысл учитывать. В традиционных системах клиент обычно ничего серьезного не делает, шлет мелкие запросы да качает данные, поэтому их и не измеряют.
Последняя миля, представьте дайлап или нерасторопный пользователь, это не имеет отношение к мощности магистральной сети. В любой системе есть узкое место на которое не может повлиять ни один пользователь, это всегда магистраль. Не важно сколько труб втекает в магистральный трубопровод, если магистраль прокачивает 1000 tps, а локальные могут 10000 tps подтянуть к магистрали, они просто будут ждать.
В теоретическом плане — да, в теории интернет может предоставить неограниченное количество tps. Но что если я строю блокчейн, в котором клиент выполняет множество сложных вычислений, и при этом измеряю кучу метрик быстродействия? Для клиента важно, что его компьютер не успевает вычислять содержимое транзакций и отправлять их вовремя. Как мне не перепутать ситуацию, когда я уперся в блокчейн часть, с той, когда клиент тупо не успевает формировать запросы? Кроме того у многих проектов есть промежуточные сервера, например в LIghtning или Plasma. С точки зрения обычных сетей — наверное метрики клиентов не важны. Но в сетях, где клиенты выполняют большую часть процессинга надо измерять и на клиентах, также, уже виднеются на горизонте сети, где общая производительность будет почти складываться из производительностей клиентов, и там роль этих метрик еще возрастет.
Включаете систему на полную нагрузку, находите самое узкое место и высчитываете мощность системы.
а полная нагрузка зависит сильно от характера действий пользвателей. В случае сетей все просто — задача доставить данные дальше. В блокчейнах надо сначала запроцессить, а потом, если данные ок — передать дальше. И вот это «запроцессить» может быть как простейшей транзакцией по переводу криптовалюты, так и довольно тяжеловесным вызовом смарт-контракта, который занимает по полсекунды на исполнение, а может чатсью атаки на консенсус, которая вызовет активную «переписку» между валидаторами блокчейна. Поэтому внутри аналога «магистральной» в p2p сети все куда менее предсказуемо и сильнее зависит от характера клиентской нагрузки. Ну и «включаете систему на полную нагрузку» здесь трудно определить — какой профиль нагрузки считается «на полную»?
С таким же успехом можно сказать, что это проблема создания stateless client
Sign up to leave a comment.
Сколько TPS в вашем блокчейне?