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

[zVlad]

....

На странице 18 данного документа можно найти таблицу с результатом DB2 10 на z196 (4 CP LPAR). При количестве симулированных юзеров 9828 штук получилась утилизация %CPU on z/OS = 69.03%. Можно предположить, что CPU 100% будет достигнуто при числе симулированных юзеров в 14243 cоответственно.

....

Это может быть (и даже наверняка) не верно ожидать прямую пропорциональную зависимость между количеством юзеров и загрузкой CPU.

[crypto5]

TPC-C с его безумным storage layer'ом, схемами партицирования и "космическими" кластерами уже действительно давно нерелевантен для хоть сколько-нибудь значимого сайзинга.

Во все тестах TPC-* есть конкурс в том числе и некластеризированых решений, но МФ там тоже увы нету.

Что Вы хотели сказать? Что МФ не способны образовывать кластеры?

Нет, я этого не хотел сказать!

[zVlad]

TPC-C с его безумным storage layer'ом, схемами партицирования и "космическими" кластерами уже действительно давно нерелевантен для хоть сколько-нибудь значимого сайзинга.

Во все тестах TPC-* есть конкурс в том числе и некластеризированых решений, но МФ там тоже увы нету.

Что Вы хотели сказать? Что МФ не способны образовывать кластеры?

Нет, я этого не хотел сказать!

Так что же Вы хотели сказать?

[crypto5]

TPC-C с его безумным storage layer'ом, схемами партицирования и "космическими" кластерами уже действительно давно нерелевантен для хоть сколько-нибудь значимого сайзинга.

Во все тестах TPC-* есть конкурс в том числе и некластеризированых решений, но МФ там тоже увы нету.

Что Вы хотели сказать? Что МФ не способны образовывать кластеры?

Нет, я этого не хотел сказать!

Так что же Вы хотели сказать?

Очевидно что: во все тестах TPC-* есть конкурс в том числе и некластеризированых решений, но МФ там тоже увы нету.

[zVlad]

ИБМ поступил мудро много лет назад, когда прекратил участвовать в нерелевантных для МФ тестах типа ТРС

TPC-C с его безумным storage layer'ом, схемами партицирования и "космическими" кластерами уже действительно давно нерелевантен для хоть сколько-нибудь значимого сайзинга. А вот SAP SD, например, очень даже релевантен.

Как известно, IBM не публикует в открытых источниках результаты теста SAP SD на мейнфреймах System z. Т.е. сравнить напрямую с теми же POWER-ами или x86 не получится. На днях обнаружил любопытный документ под названием DB2 10 for z/OS with SAP® on IBM System z® Performance Report, в котором проводится сравнительное тестирование DB2/zOS 9-ой и 10-ой версии на машинах z10 и z196 соответственно.

Для тестирования используют тесты SAP Sales and Distribution и SAP Banking Day Posting в 3-tier ландшафте.
В качестве SAP application servers использовались :

"The application servers for dialog instances were either x336 machines running Linux or POWER p55A machines running AIX. We used up to thirty one x336 machines, each with two 3.6 GHz cores and 12 GB of memory. We used up to thirty-three p55A machines, each with four 2.1 GHz cores and 32 GB of memory"

На странице 18 данного документа можно найти таблицу с результатом DB2 10 на z196 (4 CP LPAR). При количестве симулированных юзеров 9828 штук получилась утилизация %CPU on z/OS = 69.03%. Можно предположить, что CPU 100% будет достигнуто при числе симулированных юзеров в 14243 cоответственно.

Цена самой дешевой машины z196 c 4-мя CP, например 2817-404 (если я угадал с моделью) составляет $1,570,000

Те же 14000 юзеров в SAP SD показывает новенький x3850X5 в 2-tier одним ящиком за 70000$

Я конечно понимаю, что System z под SAP покупают не из соображений производительности, но тем не менее "сырой" price/perfomance, мягко говоря, ужасает.

....

Когда наконец оппоненты МФ научаться сравнивать яблоки с яблоками?

Вы сами говорите вроде правильные вещи в одном месте и тут же начинаете передергивать в другом.

То что Вы нашли вроде бы как тест на МФ для SAP не был задуман как тест на рекордную производительность. Его целью было сравнение DB2 9 c DB2 10 на разных конфигурациях МФ. А это значит что и в DB2 и в z/OS были включены все уровни мониторинга, который тоже потребляет ресурсы. Кроме того в отчете сказано:

Since the main focus is on the database server, all test
scenarios were done using a physical 3-tier environment where each of the three layers resided on
separate machines.

и далее:

With these tests, we were able to show that a single DB2 10 subsystem can support more DB2 threads
than DB2 9. However, going from 409 threads to 457 threads really isn’t that significant. We were not
limited to 457 threads by DB2 10. We were limited by the hardware resources (mostly application server
capacity) available in our test environment and the number of clients in our SAP SD database.

Аппликэйшн сервер не на МФ стоял в этих тестах, в то время как лучший результат был бы если АС вместе с БД стояли бы на одном МФ, в одном или смежных LPAR.

Если говорить только о производительности, то Вы фактически сравнили результат полученный на четырех CPU с результатом полученным на 40 CPU, т.е. в десять раз большим или с учетом фактора тактовой частоты по крайне мере четырехкратном превышении. По памяти мы имеем 26 GB на МФ против 512 GB на "новеньком ящике", т.е. практически 20-кратное превышение.

Ну и как всегда цена у нас оказывается очень разной. А не задуматься ли Вам на предмет реальной жизни? Где Вы видели фирму которая бы обходилась одним ящиком пусть даже "новеньким". У нас, например, уже несколько лет назад когличество серверов перевалило за 2000 и это количество с тех пор не уменьшилось. Интерфейсная часть нашего приложения на МФ сидит на 12 ящиках как минимум - 8-мь продакшн и 4 разные другие плюс балансеры. И это все отдельные единицы обслуживания требующие людей с их зарплатами равными в месяц одной седьмой стоимости Вашего "новенького" ящика. Т.е. за семь месяцев один человечек приставленный к серверам хавает столько денег сколько стоит сервер с 40 корами и 512 GB памяти. И человечков этих не один, а гораздо больше и у них есть много манагеров с бОльшими зарплатами, а еще сетевые дела, файрволы, и т.д. есть. И все это требует площадей, элестроэнергии и охлаждения.
В случае же МФ как правило достаточно два бокса на разных локэйшн и вот мы уже имеем солюшн для DR. Причем на обоих локэшн мы можем крутить продакшн системы и девелопменты с разными так QA and training. БД с аппликэйшн серверами, балансеры, файрволлы, DNS и другие сетевые приложения все может быть размещено на этих МФ. Такая примерно конфигурация имеется в нашей фирме. И при этом два человека легко справляются со всеми инфраструктурными вопросами еще и помогая программистам зачастую. Если нашу МФ инфраструктуру развернуть в серверную то получится зоопарк небольшого областного центра со всеми вытекающими последствиями в виде затрат на содержание этого зоопарка.

[zVlad]

....P.S. По поводу "демократизации мейнфреймов" : я понимаю кому и зачем нужны System z, но когда мне начинают петь песни о том, что System z - это лучшая платформа для SAP или Linux-виртуализации, мне хочется безудержно смеяться.

Лучшая ли МФ платформа для SAP я заявлять не решусь. Скажу лишь что динамический SQL, о котором много говорилось в отчете по тесту приведеном Вами, это далеко не оптимальный вариант использования DB2 for z/OS.
Что же до Вашего смеха над МФ виртуализацией, то здесь Вы сильно ошибаетесь, очень сильно, и я бы Вам советовал ознакомиться с этой темой прежде чем "безудержно смеяться". Иначе это, сами знаете, смех без причины....

[Zombie416]

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

То получится небольшая стойка с серверами и виртуальными машинами на VMWare/Hyper-V/whatever. Которую будут обслуживать немного людей, и работать это будет уж всяко не медленнее чем 5 неновых процессоров в МФ.

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

[StrangerR]

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

То получится небольшая стойка с серверами и виртуальными машинами на VMWare/Hyper-V/whatever. Которую будут обслуживать немного людей, и работать это будет уж всяко не медленнее чем 5 неновых процессоров в МФ.

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

Чего там обслуживать то? Дисковая стойка, пара десятков серверов, один VC, с него все менеджится. Если сервер сломался - VMware перекинет системы на другой а из делла придет новая коробка, туда вставляем FLASH карточку из сломавшегосся и вперед... Там все это обслуживать - одного человека за глаза хватит и еще у него время на другие задачи останется...

[zVlad]

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

То получится небольшая стойка с серверами и виртуальными машинами на VMWare/Hyper-V/whatever. Которую будут обслуживать немного людей, и работать это будет уж всяко не медленнее чем 5 неновых процессоров в МФ.

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

А если новых процессоров?

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

[zVlad]

...

Привет StrangeR. Тут iDesperado ссылочку с аналитикой Exadata и DB2 приводил. Вы кажется покрывать что-то Exadat-ой собирались. Можете почитаете о том как на самом деле обстоят дела с этим.

[Zombie416]

А если новых процессоров?

Дык у MФ нет вроде новых процессоров, только прошлогодний z196 с 45нм, 4мя ядрами и неизвестной производительностью (неособо впечатляющей, поэтому хвастаться приходится гигагерцами. хорошо хоть не сантиметрами).

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

Не надо мигрировать на МФ. Виртуализировать сами коробки, оставив все как есть. Потреблять будете меньше чем МФ, стоить дешевле.

Но контора у вас видимо богатая, сколько это стоит никого не интересует, бюджет растет, политика в порядке. Поэтому продолжаться это может бесконечно.

[zVlad]

.....
Но контора у вас видимо богатая, сколько это стоит никого не интересует, бюджет растет, политика в порядке. Поэтому продолжаться это может бесконечно.

Наша контора имеет определенные конкурентные преимущества, но они, во-первых, не вечны, а во-вторых у конторы есть собственник которому хочется иметь прибыль, и ограничений этому хотению нет. Так что если бы все было так здорово как Вам кажется, то наверное это так или иначе пробило бы себе дорогу. Уж по крайней мере МФ бы уже заменили бы. Да и стада серверов как-нибудь проредили бы. У нас, кстати, есть и блэйды и VMWare, но подозреваю я в продакшн VMWare не используется, или очень незначительно используется.

[Zombie416]

то наверное это так или иначе пробило бы себе дорогу. Уж по крайней мере МФ бы уже заменили бы. Да и стада серверов как-нибудь проредили бы

Чтобы чего-то пробило дорогу, хотение не просто должно быть, а должно быть сильным и неизбежным. Пока бюджет есть и все как-то работает, от добра добра не ищут.

Ну и потом, как можно заменить МФ, если есть работающие custom приложения, и производительность всех устраивает? Мигрировать на другую hardware платформу и оставить DB2 - все равно кормить IBM. А переписывать на другую базу - это на много лет и миллионов development-а и проблем, только чтобы все как-то задышало опять.

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

[zVlad]

...

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

Не надо мигрировать на МФ. Виртуализировать сами коробки, оставив все как есть. Потреблять будете меньше чем МФ, стоить дешевле.
....

Там где МФ нет вообще может и не надо. А вот в нашей конторе МФ есть и избавляться от него не собираются. При этом МФ загружен более менее прилично только с 9:00 до 15:00 пять дней в неделю. Все остальное время, да и в это время, МФ мог бы выполнять нагрузку тех же Линукс приложений. Например, можно было бы репатриировать репликации БД МФ, которые в данный момент на MS SQL сидят. Проблема DR решилась бы красивее чем это сейчас имеет место быть. Есть и другие приложения сидящие не на-МФ, но тесно связаны с МФ.

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

Но дело все в том что в нашей конторе нет МФ мафии, вместо этого есть мафия Unix и Wintel. Наш манагер - самой молодой (в смысле стажа работы в нашей фирме) манагер, а все остальные не имеют опыта работы с МФ. Поэтому не смотря на явные экономические выгоды, с практическими нулевыми затратами, эта идея не воспринимается ни под каким соусом. Называется это - job security для тех кто на не-МФ. И экономика здесь не играет никакой роли. Так что дешевые железяки которыми мне здесь все уши прожужжали в реальной жизни мало что меняют. В реальной жизни всегда найдется обоснование почему этих дешевых железок надо очень много и соответственно надо много людей для их обслуживания. И в результате ИТ на дешевых железках оказывается очень не дешевым, а предложения реально сэкономить никого не возбуздает, наоборот вызывает яркую агрессию, воспринимается как покушение на завоеванные позиции. И такие предложения даже не обсуждаются, сразу отметаются без объяснений. Я знаю о чем говорю, я прошел этот процесс уже много раз в нашей конторе. Нет я немного не прав. Как раз сейчас идет проект по переносу функционала из SAP на Unix/Oracle к нам на МФ. В августе будет внедрение.

[Dmitry67]

Но дело все в том что в нашей конторе нет МФ мафии, вместо этого есть мафия Unix и Wintel

Кругом враги...

[zVlad]

....
Ну и потом, как можно заменить МФ, если есть работающие custom приложения, и производительность всех устраивает? Мигрировать на другую hardware платформу и оставить DB2 - все равно кормить IBM. А переписывать на другую базу - это на много лет и миллионов development-а и проблем, только чтобы все как-то задышало опять.

....

Вы вроде постоянно со мной спорите, но почему то не внимательно (видимо выборочно) читаете меня. Мне кажется я уже раз десять сообщал что наше приложение поставляется разработчиком не только на МФ, нои на Юникс с Оракл. Более того, говорят что разработка этого приложения изначально ведется именно под Юникс/Оракл и лишь локализуется (но довольно полно, не так как в случае SAP) на МФ. Что держит нашего клиента на МФ? В первую очередь надежность и серьюрити. Один из двух клиентов (и об этом я уже все уши должно быть прожужжал) ушел три года назад на Юникс-Оракл. Попал на большие деньги, потерял производительность, стабильность и до сих пор не имеет DR. Все это почти из первых рук информация.

[StrangerR]

Но дело все в том что в нашей конторе нет МФ мафии, вместо этого есть мафия Unix и Wintel

Кругом враги...

Ну так пропихивайте идею виртуализации на MФ под линуксами (винда там небось и не работает?) Очень логичное сочетания - МФ как МФ под основные задачи, и использование свободных ресурсов под прочие. Может, дело не в мафии а в том что не _получается каменный цветок_?

Сколько все таки стоит _добавить 64 гига памяти_ в ваш МФ?

[StrangerR]

...

Привет StrangeR. Тут iDesperado ссылочку с аналитикой Exadata и DB2 приводил. Вы кажется покрывать что-то Exadat-ой собирались. Можете почитаете о том как на самом деле обстоят дела с этим.

Я не собирался, я знаю что в Warehouse Exadata1 покрывает DB2 с потрохами, но подозреваю что с Exadata2 для OLTP у оракла что то не склеилось, не видать победных реляций... потому и спрашивал. Погляжу по ссылкам повыше, самому интересно, что же там случилось. Хотя одну причину я знаю - оракл как всегда бездумно сказал _у нас на ексадата 2 будет только 11.2 версия_ в момент когда 11.2 для продакшена планировали лишь откровенные камикадзе.

[Zombie416]

Что держит нашего клиента на МФ? В первую очередь надежность и серьюрити. Один из двух клиентов (и об этом я уже все уши должно быть прожужжал) ушел три года назад на Юникс-Оракл. Попал на большие деньги, потерял производительность, стабильность и до сих пор не имеет DR. Все это почти из первых рук информация.

Или то что менять неохота, все и так устраивает.

А единичная история с каким-то клиентом у которого какое-то приложение, которое как будто бы пишется для двух платформ одинаково, говорят, работает плохо, это лирика. Без вникания в детали что конкретно перенесли, куда, почему нестабильно, где ДР, и кто виноват виднр только одно: клиент, несмотря на все декларируемые ужасы и убытки, на МФ пока не вернулся.

[zVlad]

Что держит нашего клиента на МФ? В первую очередь надежность и серьюрити. Один из двух клиентов (и об этом я уже все уши должно быть прожужжал) ушел три года назад на Юникс-Оракл. Попал на большие деньги, потерял производительность, стабильность и до сих пор не имеет DR. Все это почти из первых рук информация.

Или то что менять неохота, все и так устраивает.

А единичная история с каким-то клиентом у которого какое-то приложение, которое как будто бы пишется для двух платформ одинаково, говорят, работает плохо, это лирика. Без вникания в детали что конкретно перенесли, куда, почему нестабильно, где ДР, и кто виноват виднр только одно: клиент, несмотря на все декларируемые ужасы и убытки, на МФ пока не вернулся.

Я с Вами согласен что нужна конкретика. И она есть. Каждую неделю по нескольку часов приложение лежит. Перформансе неудовлетворяет. Денег вбухано гораздо больше чем тратилось когда клиент был на МФ, где в добавок все было стабильно и был DR. На МФ они есно не вернуться. Более того, в разговоре с манагером о состоянии этого клиента родилось небесосновательное предположение что на уровне верховного командивания этих наших клиентов циркулируют самые бодрые настроения, что мол вот перешли и все у нас пучком. Вполне возможно, здесь не принято плакаться в жилетку даже если жопа болит.

Перенесли все было на МФ, БД скачали как есть, структуры там в обоих случаях одинаковы. Язык программирования Кобол и там и там.

[Abappy]

Я с Вами согласен что нужна конкретика. И она есть. Каждую неделю по нескольку часов приложение лежит. Перформансе неудовлетворяет.

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

[zVlad]

Но дело все в том что в нашей конторе нет МФ мафии, вместо этого есть мафия Unix и Wintel

Кругом враги...

Ну так пропихивайте идею виртуализации на MФ под линуксами (винда там небось и не работает?) Очень логичное сочетания - МФ как МФ под основные задачи, и использование свободных ресурсов под прочие. Может, дело не в мафии а в том что не _получается каменный цветок_?

Сколько все таки стоит _добавить 64 гига памяти_ в ваш МФ?

Да нет все получается что замышляется. Не понял Ваш вопрос по памяти. Зачем добавить?

Работы по виндам (.NET) на МФ имеются:

http://www.mainframe-upgrade.com/articl ... mework.php

Вот почитайте что по видимому ваши коллeги (Интел программисты) пишут про ввод-вывод МФ:

And if you are still debating whether to get into IFLs and go with Linux on the mainframe then consider the mainframe I/O arguments:

1. No mainframe CPU is used for I/O, it has its own channel processors. CPU concentrates on pure work - not I/O.

2. I/O on the mainframe is completely unique, with up to 65536 devices on one mainframe (and of course that becomes exponentially more mind boggling on a sysplex!).

3. Even though they compare well with mainframe CPUs nowadays, remember! PC based server main CPUs get bogged down doing I/O as well as the logic processing.

These three points make a convincing case for at least considering moving high I/O processes (like data warehouses and other database intensive applications) to the mainframe.

[krids]

Аппликэйшн сервер не на МФ стоял в этих тестах, в то время как лучший результат был бы если АС вместе с БД стояли бы на одном МФ, в одном или смежных LPAR.

Даже страшно представить list price получившейся бы в этом случае модели z196.

Если говорить только о производительности, то Вы фактически сравнили результат полученный на четырех CPU с результатом полученным на 40 CPU, т.е. в десять раз большим или с учетом фактора тактовой частоты по крайне мере четырехкратном превышении. По памяти мы имеем 26 GB на МФ против 512 GB на "новеньком ящике", т.е. практически 20-кратное превышение.

Блеск! Т.е кучу application server-ов в бэкграунде Вы банально не заметили ?
Я Вас разочарую, на 4 СP MФ этот результат достигнут быть не может в принципе, потому что SAP Dialog Instance под z/OS не работают. Не нравится "новенький ящик" в 2-tier ? Ради бога, те же 14000 юзеров на 13-ти power-блейдах трехлетней давности в 3-tier, где под БД было выделено всего 2 ядра POWER6.

Ну и как всегда цена у нас оказывается очень разной.

Ну так огласите, плз, свой вариант цены на данную модель и как она (такая цена) может быть получена.

А не задуматься ли Вам на предмет реальной жизни? <поскипано>

В реальной жизни преимущества МФ в части консолидации тяжелого custom-ворклоада и организации супернадежных сисплексов никто не оспаривает. Право, не стоило тратить свое время на прописные истины.

Пойнт был лишь в том, чтобы показать в сравнении цифры, которые практически нигде не увидеть в паблике и уж тем более никогда не услышать от сейлзов/маркетологов/продакт манагеров IBM System z. Цифры озвучены, выводы каждый сделает сам. Лично для меня в контексте SAP SD они совершенно очевидны.

[krids]

Скажу лишь что динамический SQL, о котором много говорилось в отчете по тесту приведеном Вами, это далеко не оптимальный вариант использования DB2 for z/OS.

Вот-вот. Именно поэтому под БД SAP'а покупать СУБД, которая вместе с платформой стоит бешеных денег затем, чтобы неиспользовать и 10% её возможностей - это, имхо, бред.

Что же до Вашего смеха над МФ виртуализацией, то здесь Вы сильно ошибаетесь, очень сильно, и я бы Вам советовал ознакомиться с этой темой прежде чем "безудержно смеяться". Иначе это, сами знаете, смех без причины....

Вы невнимательны. МФ-виртуализация != Виртуализация Linux на МФ. Массовая виртуализация Linux-машин на МФ могла быть оправдана лет 5-7 назад. Сегодня, с учетом реалий развития x86-виртуализации это выглядит просто смешно (возить картошку на бентли конечно можно, только вот и безумно дорого и картошки много не привезешь).

[zVlad]

....Пойнт был лишь в том, чтобы показать в сравнении цифры, которые практически нигде не увидеть в паблике и уж тем более никогда не услышать от сейлзов/маркетологов/продакт манагеров IBM System z. Цифры озвучены, выводы каждый сделает сам. Лично для меня в контексте SAP SD они совершенно очевидны.

Увы, Вы не заменитили и никак не прокомментировали мой главный поинт. Он был в том что тестирование SAР SD на МФ имело цель сравнить DB2 9 c DB2 10 и z10 c z196. Цели поставить рекорд, или показать на что способен МФ не ставилось. В тоже время тесты которые Вы противопоставляете МФ были поставленны именно для демонтрации способностей по производительности.
Теперь Вы поняли разницу, или еще что-то нужно объяснять?

Вот Вас и других с Вами все время волнует цена, Вы все время делаете круглые глаза увидив цену МФ. А как Вы оцениваете RAS и другие качественные показатели? Никак. Их по Вашему вообще не существует. А в реальной жизни это не так и те кто сознательно работает на МФ это очень хорошо понимают и их не интересуют бэнчмарки в тестах где упражняются не-МФ системы. Они знают какой МФ им нужен и их в лучшем случае могут интересовать тесты разных конфигураций МФ и софта чтобы понять где и как можно оптимизировать параметры. Я, к примеру, понял из теста с SAP SD что нам надо идти не на DB2 9 как планируется сейчас, а сразу на DB2 10. Конечно это шокирует наших программистов и манагеров, но может удастся их убедить.