Демократизация мейнфреймов

[zVlad]

....Не имею ни малейшего понятия что там было и как, я, как и Вы, прочёл о том, что экономия составила 2 миллиона в месяц, и не прочёл ни одного опровержения этого утверждения со стороны айбиэм ... а уж что там и как было - какая разница?
....

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

[zVlad]

А вон как. "Часовню - это тоже я". Понятно.
Только какое это имеет отношение к собственно МФ? Почему экономия от головотяпства называется экономией перехода с МФ на что-то другое?

Потому-что головотяпство было устранено в результате перехода. Вы вообще поглядите на досуге как ROI считается ... там такие забавные вещи учитываются .. "никогда бы не подумал"

....

А откуда Вы вообще знаете что головотяпство было? В саксес стори об этом ничего не сказано.

[zVlad]

P.S. Да и еще от экономии. Я писал уже что не понимаю как можно сэкономить $2 млн на замене 100-200 MIPS МФ если пятилетний лиз немногим менее мощного МФ стоит $0.5 млн. Как-то не проходит арифметика здравого смысла.

Ну это я Вам с лёгкостью объясню - если "програмно-аппаратный" комплекс постоянно требует "подкрутки", и её делают люди с неплохими зарплатами, и в плюс к этому десятки людей (тоже с неплохими зарплатами) работают неэффективно из-за того, что отчёт могут посмотреть только раз в день, а потом его надо перезапустить и следующий раз посмотреть уже завтра ... пара миллионов экономии иногда выходит даже без оценки влияния ускорения вычислений на то, чем компания управляет.

Только какое это имеет отношение к собственно МФ? Почему экономия от головотяпства называется экономией перехода с МФ на что-то другое?

А вы думаете ибм не применяет таких приемов в своих success stories описаниях?

Вы о чьих приемах говорите? Abappy что ли?

[crypto5]

P.S. Да и еще от экономии. Я писал уже что не понимаю как можно сэкономить $2 млн на замене 100-200 MIPS МФ если пятилетний лиз немногим менее мощного МФ стоит $0.5 млн. Как-то не проходит арифметика здравого смысла.

Ну это я Вам с лёгкостью объясню - если "програмно-аппаратный" комплекс постоянно требует "подкрутки", и её делают люди с неплохими зарплатами, и в плюс к этому десятки людей (тоже с неплохими зарплатами) работают неэффективно из-за того, что отчёт могут посмотреть только раз в день, а потом его надо перезапустить и следующий раз посмотреть уже завтра ... пара миллионов экономии иногда выходит даже без оценки влияния ускорения вычислений на то, чем компания управляет.

Только какое это имеет отношение к собственно МФ? Почему экономия от головотяпства называется экономией перехода с МФ на что-то другое?

А вы думаете ибм не применяет таких приемов в своих success stories описаниях?

Вы о чьих приемах говорите? Abappy что ли?

Я говорю не о "чьих" а о "таких".

[zVlad]

Ну это я Вам с лёгкостью объясню - если "програмно-аппаратный" комплекс постоянно требует "подкрутки", и её делают люди с неплохими зарплатами, и в плюс к этому десятки людей (тоже с неплохими зарплатами) работают неэффективно из-за того, что отчёт могут посмотреть только раз в день, а потом его надо перезапустить и следующий раз посмотреть уже завтра ... пара миллионов экономии иногда выходит даже без оценки влияния ускорения вычислений на то, чем компания управляет.

Только какое это имеет отношение к собственно МФ? Почему экономия от головотяпства называется экономией перехода с МФ на что-то другое?

А вы думаете ибм не применяет таких приемов в своих success stories описаниях?

Вы о чьих приемах говорите? Abappy что ли?

Я говорю не о "чьих" а о "таких".

Там их два. Один прием находит экономию в $2 млн. долларов в год на замене МФ, пятилетний лиз которого стоит $0.5 млн. Второй прием - объяснение этого дисбаланса головотяпством, которое было вылечено переходом с МФ на другую платформу без объяснения почему это головотяпство не могло было быть вылечено без перехода.

В первом случае в принципе можно представить что были взяты цены МФ когда он покупался - по видимому лет 10-15 назад. Учтены затраты на разработку приложения, которое теперь работает на другой платформе как есть. И т.п.. В итоге могла получиться сумашедшее число. И как результат $2 млн. в год экономии.

[Abappy]

А вон как. "Часовню - это тоже я". Понятно.
Только какое это имеет отношение к собственно МФ? Почему экономия от головотяпства называется экономией перехода с МФ на что-то другое?

Потому-что головотяпство было устранено в результате перехода. Вы вообще поглядите на досуге как ROI считается ... там такие забавные вещи учитываются .. "никогда бы не подумал"

....

А откуда Вы вообще знаете что головотяпство было? В саксес стори об этом ничего не сказано.

А я и не знаю было оно или нет. Я знаю что они насчитали 2 млн долларов. Теоретически - при подсчёте ROI можно банально посчитать разницу от сокращения потери денег на время от работы отчёта и суммы могут получиться куда большие чем пара миллионов в месяц. Но в любом случае - давайте дружно не отвлекаться на мелочи (тем-более что они не только Вам, но и мне неинтересны). Возьмём лучше оракловый переход с айбиэма и Bull-а ( у Bull-а кстати не так давно было около десятка машин в топ 500 (включая один в десятке) суперкомпьютеров по миру, так-что даже если Вы их не знаете, это ещё не значит, что они совсем уж плохие ).

Итого - были чудесные Bull и IBM и тут вдруг 50 с лишним миллионов экономии и при этом чуть ли не двукратный прирост производительности ... как же так?

[flip_flop]

[Bull] и сейчас 6-й в списке. Но мы не о суперкомьпютерах а о эдаких многостаночниках консолидаторах.

Кстати о консолидации.

Набрел на спеки по консолидации - организация все-та же [www.spec.org] и увидел спеки именно по консолидации серверов [SPECvirt_sc2010 http://www.spec.org/virt_sc2010/results ... _perf.html ]. Правда не посредством перехода на МФ а посредством виртуализации. Но все-таки. Разноплановая нагрузка - и приложения, и база данных на [DB2] и файловая система и сетевая нагрузка.

С чувством глубоко удовлетворения увидел, что уважаемая фирма ИБМ (да торжествует имя ее) уверенно лидирует с большим отрывом. На том самом сервере с двумя платами, о котором автор сего топика упоминал на первых страницах (IBM x3850 X5). Итак, один сервер на двух платах с осемью процессорами [Xeon E7] (по четыре сокета на плату) с двумя терабайтами памяти уверенно тянет 432 виртуальные машинки в среде мною любимого [RHEL 6.0], одного единственного на одном единственном сервере со встроенной поддержкой [KVM - Kernel based Virtual Machine]. Виртуализация тянет спокойненько 160 логических процессора (по два на корову, всего 80 коров) и два терабайта памяти. Это получается 432/8=54 ВМ на процессор. Подозреваю, что могли бы и все 64, но практически невыгодно.

Итак, то, что некоторое время (давеча, кстати) цитировалось поклонниками новейших МФ [zEnterpise] как большой отрыв от х86 серверов (по 60 ВМ на [CPU z196], до 3-х ТБ памяти) уже не является прерогативой МФ. Кстати, тот же [RHEL 6] поддерживает все [RAS] характеристики. Получается что [RHEL KVM] выигрывает у [VMware], но это уже оффтопик. Итак, парочка серверов от достопочтенной кампании - и ...

Заметьте - не говорим о деньгах, хотя вроде бы деньги и были и есть движущей силой консолидации, так что было бы странно говорить о качестве консолидатора в отрыве от показателя качества (деньгах на [TCO]).

Такая вот консолидация с виртуализацией на ширпотребе (в хорошем смысле).

[Abappy]

160 логических процессора (по два на корову, всего 80 коров) .

а потом бедные программисты приложений гадают - с какого одна и та же задача вызываемая на одной и той же машине выполняется иногда 20 секунд а иногда 50 (при "в целом" нулевой загрузке) ... а ответ прост - как повезёт распределиться виртуальным процессорам по реальным коровкам, так и будет ( в целом ничего страшного, но отлаживать на этом производительность тяжко ) ... впрочем у МФ "те же яйца вид сбоку"

[StrangerR]

Я не думаю что RHEL может хоть как то выигрывать у VMware по удобству работы с ним - последняя поддерживает и real Time и все виды миграций (HW -> VM -> VM -> HW) и Live Move и кроме прочего - VMFS является изначально кластерной а в RHEL вы кластерную файловую систему долго будете руками делать а потом с фенсингом бодаться, я думаю она выигрывает лишь по пефоменсу в случае если под ней работают линуксы. Но это не так важно, и та и другая позволяют влегкую делать то, что раньше делали МФ.

А главное, и та и другая позволяют создать апплаенсы - сделать приложение, установить его, сохранить в виде имейджа систем и дальше ставить по мере необходимости куда требуется. При этом программистам уже не нужно трахаться с мультиплатформенностью и с тем _почему у Васи приложение работает по году а у Пети падает раз в неделю_. ТО есть последнее достоинство МФ - единство среды - стремительно исчезает. И остается лишь завышенная раз в 5 цена (в МФ).

[Bull] и сейчас 6-й в списке. Но мы не о суперкомьпютерах а о эдаких многостаночниках консолидаторах.

Кстати о консолидации.

Набрел на спеки по консолидации - организация все-та же [www.spec.org] и увидел спеки именно по консолидации серверов [SPECvirt_sc2010 http://www.spec.org/virt_sc2010/results ... _perf.html ]. Правда не посредством перехода на МФ а посредством виртуализации. Но все-таки. Разноплановая нагрузка - и приложения, и база данных на [DB2] и файловая система и сетевая нагрузка.

С чувством глубоко удовлетворения увидел, что уважаемая фирма ИБМ (да торжествует имя ее) уверенно лидирует с большим отрывом. На том самом сервере с двумя платами, о котором автор сего топика упоминал на первых страницах (IBM x3850 X5). Итак, один сервер на двух платах с осемью процессорами [Xeon E7] (по четыре сокета на плату) с двумя терабайтами памяти уверенно тянет 432 виртуальные машинки в среде мною любимого [RHEL 6.0], одного единственного на одном единственном сервере со встроенной поддержкой [KVM - Kernel based Virtual Machine]. Виртуализация тянет спокойненько 160 логических процессора (по два на корову, всего 80 коров) и два терабайта памяти. Это получается 432/8=54 ВМ на процессор. Подозреваю, что могли бы и все 64, но практически невыгодно.

Итак, то, что некоторое время (давеча, кстати) цитировалось поклонниками новейших МФ [zEnterpise] как большой отрыв от х86 серверов (по 60 ВМ на [CPU z196], до 3-х ТБ памяти) уже не является прерогативой МФ. Кстати, тот же [RHEL 6] поддерживает все [RAS] характеристики. Получается что [RHEL KVM] выигрывает у [VMware], но это уже оффтопик. Итак, парочка серверов от достопочтенной кампании - и ...

Заметьте - не говорим о деньгах, хотя вроде бы деньги и были и есть движущей силой консолидации, так что было бы странно говорить о качестве консолидатора в отрыве от показателя качества (деньгах на [TCO]).

Такая вот консолидация с виртуализацией на ширпотребе (в хорошем смысле).

[StrangerR]

160 логических процессора (по два на корову, всего 80 коров) .

а потом бедные программисты приложений гадают - с какого одна и та же задача вызываемая на одной и той же машине выполняется иногда 20 секунд а иногда 50 (при "в целом" нулевой загрузке) ... а ответ прост - как повезёт распределиться виртуальным процессорам по реальным коровкам, так и будет ( в целом ничего страшного, но отлаживать на этом производительность тяжко ) ... впрочем у МФ "те же яйца вид сбоку"

ну блин, а кто же мешает зарезервировать или явно привязать коровы к быкам, то бишь физические процессоры к виртуальным системам... Это все просто от незнания, эти проблемы.

[zVlad]

....
Итого - были чудесные Bull и IBM и тут вдруг 50 с лишним миллионов экономии и при этом чуть ли не двукратный прирост производительности ... как же так?

50 млн - это детский лепет. Вот Центробанк России 400 млн экономии насчитал при переходе с Sun техники и Оракл на МФ и кстати Оракл.

[zVlad]

160 логических процессора (по два на корову, всего 80 коров) .

а потом бедные программисты приложений гадают - с какого одна и та же задача вызываемая на одной и той же машине выполняется иногда 20 секунд а иногда 50 (при "в целом" нулевой загрузке) ... а ответ прост - как повезёт распределиться виртуальным процессорам по реальным коровкам, так и будет ( в целом ничего страшного, но отлаживать на этом производительность тяжко ) ... впрочем у МФ "те же яйца вид сбоку"

Предположение про МФ не верно в корне. на zOS с WLM (а без него не бывает) можно гарантировать качество сервеса по требуемому параметру - респонс тайм и т.п.

[Abappy]

160 логических процессора (по два на корову, всего 80 коров) .

а потом бедные программисты приложений гадают - с какого одна и та же задача вызываемая на одной и той же машине выполняется иногда 20 секунд а иногда 50 (при "в целом" нулевой загрузке) ... а ответ прост - как повезёт распределиться виртуальным процессорам по реальным коровкам, так и будет ( в целом ничего страшного, но отлаживать на этом производительность тяжко ) ... впрочем у МФ "те же яйца вид сбоку"

ну блин, а кто же мешает зарезервировать или явно привязать коровы к быкам, то бишь физические процессоры к виртуальным системам... Это все просто от незнания, эти проблемы.

так иногда и привязано всё, но в любом случае производительность плавает существенно ... это отдельная грустная тема ( кстати контроль на МФ о котором говорит zVlad тоже не помогает ). При этом никакие процессы не умирают, просто работать сложнее

[Abappy]

....
Итого - были чудесные Bull и IBM и тут вдруг 50 с лишним миллионов экономии и при этом чуть ли не двукратный прирост производительности ... как же так?

50 млн - это детский лепет. Вот Центробанк России 400 млн экономии насчитал при переходе с Sun техники и Оракл на МФ и кстати Оракл.

Это здорово, хотя одно не отменяет другого. Где можно про ЦБ-шную экономию почитать ?

[zVlad]

....так иногда и привязано всё, но в любом случае производительность плавает существенно ... это отдельная грустная тема ( кстати контроль на МФ о котором говорит зВлад тоже не помогает ). При этом никакие процессы не умирают, просто работать сложнее :сорры:

Стоп. Пожалуйста поподробней - так что там на МФ не помогает?

[zVlad]

160 логических процессора (по два на корову, всего 80 коров) .

а потом бедные программисты приложений гадают - с какого одна и та же задача вызываемая на одной и той же машине выполняется иногда 20 секунд а иногда 50 (при "в целом" нулевой загрузке) ... а ответ прост - как повезёт распределиться виртуальным процессорам по реальным коровкам, так и будет ( в целом ничего страшного, но отлаживать на этом производительность тяжко ) ... впрочем у МФ "те же яйца вид сбоку"

ну блин, а кто же мешает зарезервировать или явно привязать коровы к быкам, то бишь физические процессоры к виртуальным системам... Это все просто от незнания, эти проблемы.

Тогда весь смысл виртуализании и консолидации, заключающийся в совместном использовании всех ресурсов сервера, изчезает и остаются только накладные расходы на виртуализацию и безопасность выполнения многих системных имиджей на одном сервере (or blade), вытекающая из банальной недоработки в этом плане тех систем, которые Вы гоняете на ВМ. Если последнее не так и системы Ваши надежны под любой нагрузкой, то Вы должны были бы в состоянии всю нагрузку запихать в одну систему (или несколько систем, не сотни) и не заморачиваться с виртуализацией.

[Palych]

а потом бедные программисты приложений гадают - с какого одна и та же задача вызываемая на одной и той же машине выполняется иногда 20 секунд а иногда 50 (при "в целом" нулевой загрузке) ... а ответ прост - как повезёт распределиться виртуальным процессорам по реальным коровкам, так и будет ( в целом ничего страшного, но отлаживать на этом производительность тяжко ) ... впрочем у МФ "те же яйца вид сбоку"

ну блин, а кто же мешает зарезервировать или явно привязать коровы к быкам, то бишь физические процессоры к виртуальным системам... Это все просто от незнания, эти проблемы.

Тогда весь смысл виртуализании и консолидации, заключающийся в совместном использовании всех ресурсов сервера, изчезает и остаются только накладные расходы на виртуализацию и безопасность выполнения многих системных имиджей на одном сервере (or blade), вытекающая из банальной недоработки в этом плане тех систем, которые Вы гоняете на ВМ. Если последнее не так и системы Ваши надежны под любой нагрузкой, то Вы должны были бы в состоянии всю нагрузку запихать в одну систему (или несколько систем, не сотни) и не заморачиваться с виртуализацией.

Если система выделена для девелопмента, то параметры её производительности одни, а когда тот же инстанс используется для отладки производительности - другие. "И никакие лекции этому не помогут".
Конечно к МФ это не относится. Там всё будет работать в любом случае.

[zVlad]

а потом бедные программисты приложений гадают - с какого одна и та же задача вызываемая на одной и той же машине выполняется иногда 20 секунд а иногда 50 (при "в целом" нулевой загрузке) ... а ответ прост - как повезёт распределиться виртуальным процессорам по реальным коровкам, так и будет ( в целом ничего страшного, но отлаживать на этом производительность тяжко ) ... впрочем у МФ "те же яйца вид сбоку"

ну блин, а кто же мешает зарезервировать или явно привязать коровы к быкам, то бишь физические процессоры к виртуальным системам... Это все просто от незнания, эти проблемы.

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

Если система выделена для девелопмента, то параметры её производительности одни, а когда тот же инстанс используется для отладки производительности - другие. "И никакие лекции этому не помогут".
Конечно к МФ это не относится. Там всё будет работать в любом случае.

Я не совсем об этом, если Вы заметили.
По терминалогии. У приложений нет производительности, приложения - это потребители, пассивные элементы процесса. Производительнозтью обладают компютеры, и их производительностью надо уметь граммотно распоряжаться. Когда Интел сервера были слабые и на них ставили по одному сервису на каждый этой проблемы не было. Но с ростом производительности серверов эта проблема становится все более насущной и вы (те кто в лодке Интел серверов главным образом) демонстрируете эту насущость здесь все больше и больше. Еще года три назад таких тендеций в наших дискуссиях не наблюдалось, а сейчас они явно есть.

[crypto5]

160 логических процессора (по два на корову, всего 80 коров) .

а потом бедные программисты приложений гадают - с какого одна и та же задача вызываемая на одной и той же машине выполняется иногда 20 секунд а иногда 50 (при "в целом" нулевой загрузке) ... а ответ прост - как повезёт распределиться виртуальным процессорам по реальным коровкам, так и будет ( в целом ничего страшного, но отлаживать на этом производительность тяжко ) ... впрочем у МФ "те же яйца вид сбоку"

Предположение про МФ не верно в корне. на zOS с WLM (а без него не бывает) можно гарантировать качество сервеса по требуемому параметру - респонс тайм и т.п.

Как уже говорилось при условии если wlm знает как померять response time у приложения.

[zVlad]

160 логических процессора (по два на корову, всего 80 коров) .

а потом бедные программисты приложений гадают - с какого одна и та же задача вызываемая на одной и той же машине выполняется иногда 20 секунд а иногда 50 (при "в целом" нулевой загрузке) ... а ответ прост - как повезёт распределиться виртуальным процессорам по реальным коровкам, так и будет ( в целом ничего страшного, но отлаживать на этом производительность тяжко ) ... впрочем у МФ "те же яйца вид сбоку"

Предположение про МФ не верно в корне. на зОС с ШЛМ (а без него не бывает) можно гарантировать качество сервеса по требуемому параметру - респонс тайм и т.п.

Как уже говорилось при условии если WLM знает как померять респонсе тиме у приложения.

На самом деле не у приложения, а у трансакции - у приложения нет респонсе тайм.

Естественно WLM может управлять и управляет только тем что может измерять. Респонсе тайм один из таких параметров. Другим похожим является цреднее значение респонсе тайм. Есть и другие параметры которые измеряет и которыми может управлять WLM.

[Dmitry67]

Как это у приложения нет response time?

[crypto5]

Как это у приложения нет response time?

Это глупый терминологический спор. Более важный вопрос здесь - сколько на свете приложений которые могут быть из коробки интегрированы с WLM что бы он мог смотреть на response time и считать среднее, всякие квантили, и уж тем более как то влиять на эти параметры.

[StrangerR]

160 логических процессора (по два на корову, всего 80 коров) .

а потом бедные программисты приложений гадают - с какого одна и та же задача вызываемая на одной и той же машине выполняется иногда 20 секунд а иногда 50 (при "в целом" нулевой загрузке) ... а ответ прост - как повезёт распределиться виртуальным процессорам по реальным коровкам, так и будет ( в целом ничего страшного, но отлаживать на этом производительность тяжко ) ... впрочем у МФ "те же яйца вид сбоку"

Предположение про МФ не верно в корне. на zOS с WLM (а без него не бывает) можно гарантировать качество сервеса по требуемому параметру - респонс тайм и т.п.

На VMware тоже можно . Резервируете приложению все что нужно для нужного SLA и все.
Реальное время там прекрасно пашет, к примеру всякие там VoIP приложения.

[StrangerR]

Это не так. Память - да, физически резервируется но она на интеле настолько дешевлше чем на вашем МФ что и говорить смешно. А CPU - резервирование вовсе не отменяет возможность использовать неиспользованное CPU другими задачами, просто если все кто зарезервировал вдруг решат по максимуму на CPU сесть, другим не останется (если все что было зарезервировали). Ну и поставить еще одну железку, не МФ, крайне легко и быстро, если что, это вам не МИПСЫ у ИБМ-а за дикие бабки отлицензирровать, это пойти и заказатьт еще один сервер за $4K суммарной стоимости, делов то...

160 логических процессора (по два на корову, всего 80 коров) .

а потом бедные программисты приложений гадают - с какого одна и та же задача вызываемая на одной и той же машине выполняется иногда 20 секунд а иногда 50 (при "в целом" нулевой загрузке) ... а ответ прост - как повезёт распределиться виртуальным процессорам по реальным коровкам, так и будет ( в целом ничего страшного, но отлаживать на этом производительность тяжко ) ... впрочем у МФ "те же яйца вид сбоку"

ну блин, а кто же мешает зарезервировать или явно привязать коровы к быкам, то бишь физические процессоры к виртуальным системам... Это все просто от незнания, эти проблемы.

Тогда весь смысл виртуализании и консолидации, заключающийся в совместном использовании всех ресурсов сервера, изчезает и остаются только накладные расходы на виртуализацию и безопасность выполнения многих системных имиджей на одном сервере (or blade), вытекающая из банальной недоработки в этом плане тех систем, которые Вы гоняете на ВМ. Если последнее не так и системы Ваши надежны под любой нагрузкой, то Вы должны были бы в состоянии всю нагрузку запихать в одну систему (или несколько систем, не сотни) и не заморачиваться с виртуализацией.

[zVlad]

Как это у приложения нет response time?

Это глупый терминологический спор. Более важный вопрос здесь - сколько на свете приложений которые могут быть из коробки интегрированы с WLM что бы он мог смотреть на response time и считать среднее, всякие квантили, и уж тем более как то влиять на эти параметры.

Если на МФ пишется серьезное приложение, например, монитор транзакций, БД, веб сервер, то используются такие системные механизмы которые одновременно с удовлетвотворением требований транзакционного механизма обеспечивает информацию и средства управления для WLM. Т.о. информация о транзакциях идет к WLM через систему, в систему же WLM посылает установки (приоритеты, изменяемые динамически) через которые происходит управление транзакциями.

Простые приложения не имеющие внутренней структуры единиц работы - транзакций, представляют собой одну транзакцию. Время выполнения такой транзакции можно конечно назвать респонс таймом, но правильнее его называть временем выполнения, или elapsed time. Но поскольку время выполнения одиночной программы случай уникальный и на основе ее выполнения невозможно собрать статистику необходимую для управления приоритетом, то для таких приложений имеет критерий (goal), называемый velocity, который используется для, скажим так, уникальных из условно бесконечных транзакций.