Технология Клиент-Сервер 2003'2
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Что такое TPC?

Павел Румянцев

Что представляют собой системы, построенные по архитектуре «клиент/сервер»? В подавляющем большинстве случаев этими системами являются системы обработки запросов к базам данных. Зачастую перед организациями, желающими автоматизировать свою деятельность, возникает огромное количество вопросов. Одним из ключевых вопросов является решение одной, и весьма непростой проблемы – оптимального выбора платформы для будущей системы.

Понятно, что ответ на такой вопрос нельзя принимать, ориентируясь на разрозненные материалы, публикуемые в прессе, заверения производителей, мнения коллег или собственное субъективное отношение к некоторой платформе или продукту. Ценой опрометчиво принятого решения могут быть огромные финансовые затраты и потерянное время. Обоснование такого решения нуждается в какой-то точке отсчета, то есть в результатах тестирования, подтвержденных независимыми источниками.

Аналогичные проблемы стоят и перед фирмами-разработчиками программного обеспечения. Насколько разработанная нашей фирмой программа лучше программы конкурентов? Или, наоборот, в чём мы проигрываем конкурентам? Что необходимо сделать для того, чтобы наша программа была лучшей?

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

Очевидно, что перед необходимостью принятия таких решений (или же обоснования своих притязаний) стояли производители и заказчики подобных систем в начале 80-х годов, когда в промышленности началась гонка, продолжающаяся до сих пор. Начало этой гонки связывают с началом автоматизации бизнес-процессов.

Естественно, что несколько смягчить остроту проблемы могли только тесты производительности систем, которые на том момент находились в зачаточном состоянии. Начиная с середины 80-х годов, продавцы компьютерных систем и баз данных начали производить оценку систем, базирующуюся на системе тестов TP1 (TP – вероятно, аббревиатура «Test of Performance»).

Фирма IBM, в «недрах» которой была разработана система тестов TP1, сделала эту систему общедоступной. Тесты, включённые в состав TP1, имели своей целью определить производительность систем, занимающихся обработкой транзакций, производимых банкоматами. Возможности этой системы были несколько ограничены. Проверялся только пакетный режим проведения транзакций, воздействие на банкомат со стороны пользователя или других компьютеров сети было исключено. У этой системы тестов были два недостатка. Во-первых, исключение из тестов внешних воздействий могло привести к получению неверных результатов. Во-вторых, условия проведения тестов не были определены, что также не могло не повлиять на точность получаемых результатов. Наконец, не существовало контроля над проведением и интерпретацией результатов тестирования. Результатом явилось то, что доверие к этой системе было достаточно низким. Ситуацию усугубил ещё и тот факт, что зачастую системы, производительность которых была неверно оценена благодаря неверным тестам (тестам, проведённым в неверных условиях), начинали пользоваться успехом на рынке. Естественно, этот факт не мог не расстроить честных производителей и торговцев системами автоматизации.

Первого апреля 1985 года в «Datamation» была опубликована анонимная статья, озаглавленная «Измерение производительности обработки транзакций». Фактически автором статьи являлись Джим Грей (Jim Gray) и ещё двадцать четыре автора, работающих в различных отраслях науки и производства. Несмотря на дату публикации, содержание статьи отнюдь не было шуткой. В этой статье предлагалась методика тестирования производительности системы обработки транзакций. Грей и его соавторы предложили систему тестов, отличчающуюся от тестов системы TP1. Эта система учитывала то, что банкомат (в более широком смысле – терминальное устройство) не является автономным устройством, и, следовательно, на него влияют как другие компьютеры, включённые в сеть, так и пользователи. Кроме того, при оценке результатов тестов было предложено использовать несколько параметров, позволявших оценить не только технические, но и экономические параметры системы.

Во-первых, Грей предложил не ограничиваться оценкой только производительности системы, но и оценивать общую стоимость эксплуатации системы. Эту общую стоимость он предложил рассчитывать не только как совокупную стоимость аппаратного и программного обеспечения, но и учитывать стоимость поддержания системы в работоспособном состоянии в течение пяти лет. До этого момента при оценке систем стоимость её обслуживания не учитывалась.

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

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

В-четвёртых, впервые было предложено ввести ограничение по времени обработки транзакций. В частности, в системе тестов «Дебет-кредит» 95% всех транзакций должны были быть завершены в течение одной секунды. Это предъявляло не столько количественные, сколько качественные требования к работе системы. Тестируемая система должна была работать так, чтобы пользователь (субъективно, конечно) не замечал задержек в ее работе. До этого момента таких ограничений не вводил никто.

Однако появление этой статьи внесло ещё большую сумятицу. Вспомним, что Грей опубликовал не тест. Он опубликовал только размышления о том, каким должен быть этот тест, и каким требованиям он должен отвечать. После выхода этой статьи среди производителей и продавцов систем обработки транзакций наступила некоторая сумятица. Кто-то для оценки производительности системы пользовался тестами TP1, кто-то использовал методологию «Дебет-кредит», кто-то использовал частично тесты из TP1, а частично тесты, построенные в соответствии с «Дебет-кредитом»… При этом результаты этих тестов каждый интерпретировал по-своему, точнее, как ему выгодно.

В этой ситуации естественным выходом было создание хороших тестов производительности, выдающих достоверные результаты. На результатах хороших тестов может быть построена честная конкуренция. Однако любому мало-мальски связанному с вычислительной техникой человеку очевидно, что результаты тестов могут быть трактованы неоднозначно. Поэтому помимо создания тестов необходимо было обеспечить правильность толкования результатов тестов и предотвратить любые возможности неверной интерпретации результатов. Как общая ситуация с попытками какого-либо ранжирования систем по их производительности, так и необходимость создания «связки» «тесты/система интерпретации результатов тестов» привели к возникновению TPC – совета по производительности обработки транзакций (Transaction Processing Performance Council).

Американский маркетолог Омри Серлин (Omri Serlin) понимал и ощущал всю ненормальность этой ситуации. Поэтому он начал кампанию за приведение всего этого «безобразия» в строго определённый порядок. В необходимости наведения порядка Омри Серлину удалось убедить восемь компаний, и 10 августа 1988 года был подписан документ о создании TPC (Transaction Processing Performance Council).

TPC был создан для того, чтобы наблюдать не только за правильностью проведения тестов, но и за тем, как интерпретируются результаты этих тестов. Таким образом, основными задачами TPC явились:

разработка процедур интерпретации результатов проведённых тестов;

ведение наблюдения за правильностью проведения тестов;

учёт результатов проведённых тестов.

Год спустя, в ноябре 1989 года TPC опубликовал свою первую спецификацию теста производительности, которая получила название TPC-А. Эта спецификация в основном базировалась на модели, предложенной Джимом Греем со товарищи. TPC-А отличался от этой модели, однако, внесённые изменения не носили принципиального характера. В частности, были внесены следующие изменения:

требование выполнения 95% транзакций в течение одной секунды было заменено на требование выполнения 90% транзакций в течение двух секунд;

число эмулируемых терминалов было ограничено десятью;

стоимость терминала включалась в общую стоимость системы;

системы могли работать как в локальных (LAN), так и в глобальных (WAN) сетях (в статье Джима Грея шла речь только о работе в WAN);

требования в целом к системе были ужесточены таким образом, чтобы за общую производительность системы нельзя было принять её производительность в «пиковых» условиях;

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

В TPC-А было включено ещё одно не просто важное, а принципиально важное условие. Принципиально новым требованием явилось требование опубликования полного отчёта о проведении тестов и полученных результатах. При выполнении этого требования каждый, кто хотел проверить толкование результатов тестов, мог совершенно легально сделать это. Естественно, это требование повлекло за собой совершенно новое понимание тестирования. Тестирование как таковое стало представляться процессом, результаты которого ценны только в полноте своей. Результаты отдельных тестов потеряли своё значение, как не дающие полной картины.

Первый результат прохождения теста TPC-A был опубликованы в июле 1990 года. Четырьмя годами позднее, когда TPC-А находился на пике популярности, в списке прошедших тесты значилось 115 систем тридцати трёх компаний. Всего же было опубликовано около трёхсот результатов прохождений тестов.

Первый результат прохождения TPC-А был равен 33 tpsA (транзакций в секунду при прохождении теста TPC-А) при стоимости транзакции 25500 долларов. Лучший результат, полученный при прохождении этой серии тестов, составил 3692 tpsA при стоимости транзакции 4873 доллара. Повышение скорости в 111 раз и снижение стоимости в пять раз произошло за счёт:

неоптимальности первых версий тестов;

улучшения качества и скорости работы «железа» и «софта»;

исправления ошибок и удаления «узких мест» из программ, уже прошедших тесты;

производители «играли» с тестами, узнавая один от другого о предъявляемых требованиях и «подгоняя» систему только для прохождения теста.

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

Таблица 1. Системы, показавшие десять лучших результатов
в тесте TPC-С, категория «Производительность» (1 июля 2003 года).

Второй системой тестов, результаты которой впервые были опубликованы в середине 1991 года, являлась TPC-В. Это в некотором смысле был возврат к «Дебет-кредиту». При работе TPC-B не учитывались воздействия сети и пользователей. Первый результат прохождения этого теста составил 102,94 tpsB при стоимости транзакции 4167 долларов. Лучшим из показанных был результат 2025 транзакций при стоимости транзакции 254 доллара.

Результаты, да и само существование этого теста оцениваются неоднозначно, и эта неоднозначность подвигла TPC на дальнейшее развитие серии тестов и на создание ещё одной серии – TPC-S. В январе 1998 года был создан тест, позволявший оценивать производительность TPC-W для web-серверов, занимающихся обработкой транзакций.

Но вернёмся ко времени создания TPC-B. Как сказано выше, непосредственно TPC сыграл большую роль в развитии систем обработки транзакций. Но при своём создании TPC допустил один промах. У него не было никакой юридической службы. Пользователю, не согласному с результатами тестов или интерпретацией этих результатов, некуда было обратиться и обжаловать эти результаты. Для того чтобы изменить это положение, в 1990-1991 годах был создан и начал функционировать Technical Advisory Board (TAB), который и взял на себя заботу о разрешении всех конфликтов, связанных с тестами и их результатами. Таким образом, TPC помимо «законодательной» (интерпретация результатов проведения тестов) и «исполнительной» (разработка тестов и осуществление тестирования) ветвей получил также и «судебную» ветвь.

Таблица 2. Системы, показавшие 10 лучших результатов в тесте TPC-С,
в категории «Стоимость/производительность» (1 июля 2003 года).

Разработка и дальнейшее усовершенствование тестов на этом, естественно, не остановилось, и к настоящему времени используется уже третья версия тестов TPC, TPC-С.

К началу 90-х годов прохождение тестов TPC де-факто стало почти обязательным для систем обработки транзакций. Многие компании, пройдя тестирование TPC, свою маркетинговую политику построили на результатах прохождения этих тестов. Но, как говорится, в семье не без урода. Некоторые из этих компаний стали с целью повышения объёма продаж предъявлять свои результаты несколько однобоко. При этом выпячивались результаты одних тестов и старательно замалчивались результаты других. Естественно, это не могло не нанести урона престижу TPC и авторитету производимого тестирования. Для того, чтобы впредь предотвратить подобные случаи, TPC принял решение разрешить объявление результатов тестов только при выполнении следующих условий:

точность представления результатов;

полнота представления результатов;

целостность представления результатов (должны быть представлены не только результаты тестов, но и условия их проведения).

Эти три условия позволили TPC потребовать от недобросовестных производителей и торговцев прекращения спекуляций на результатах пройденных тестов. Результатом, естественно, явилось восстановленная репутация TPC.

В настоящее время в состав TPC входят отнюдь не только восемь фирм, явившихся «отцами-основателями» TPC. Список членов TPC сам по себе может охарактеризовать эту организацию. В состав TPC по состоянию на декабрь 2002 года входили:

Acer

Assential Software

BEA Systems

Bull

DataReturn

Dell Computers

EDS

EMC Corp

Fujitsu

Gradient Systems

Hewlett-Packard

Hitachi

IBM Corp

IDEAS International

Intel Corp

Itom International

Microsoft

NCR

NEC

Network Appliance, Inc

Oracle

Performance Tuning Corp

Fujitsu Siemens

Silicon Graphics

Sun Microsystems

SunSoft

Sybase

Unisys Corp

White Cross Systems

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

Как уже говорилось выше, целью тестов TPC является предоставление объективных данных о производительности системы. Для того, чтобы достичь этой цели, спецификации TPC требуют, чтобы тестировалась производительность систем, продуктов, технологий, отвечающих следующим требованиям:

продукт должен быть доступен пользователям;

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

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

Запрещается производить тестирование таких систем, целью тестирования которых является только улучшение результатов тестирования, но не реальное улучшение работы системы в реальных условиях.

При интерпретации результатов должны использоваться следующие характеристики:

является ли система доступной для пользователя, документированной и поддерживаемой?

есть ли у приложения какие-нибудь ограничения сверх тех, которые предъявляются TPC?

является ли система составной частью более крупной системы?

предпринимает ли система специальные меры, которые не приводят к квеличению производительности, но улучшают результаты тестирования?

не является ли система подобной какой-то другой системе, уже имеющейся на рынке?

требует ли система дополнительных навыков для работы с ней, то есть необходимо ли обслуживающему персоналу, уже имеющему опыт работы с подобными системами, проходить дополнительное обучение на рабочем месте или в учебном центре?

есть ли у системы ценовые скидки, и в каких случаях они применяются?

имеются ли уже случаи поставки этой системы? Сколько систем уже находится в эксплуатации?

если система до сих пор нигде не эксплуатируется, то есть ли какие-нибудь основания предполагать, что она будет использоваться в будущем?

Тестирование продукта производится в следующих категориях:

логическая структура базы данных;

характеристики транзакции;

характеристики устройства взаимодействия системой (терминала);

реакция системы на увеличение размера базы данных;

реакция системы на увеличение числа пользователей базы данных;

производительность и время реакции системы;

цена системы и правильность её установления;

полное раскрытие отчёта о результатах тестирования системы;

возможность аудита системы.

Как система тестирования систем обработки транзакций, TPC эмулирует некоторую среду, в которой некоторое количество терминалов производит запросы к базе данных. В общем случае эти транзакции включают в себя ввод и передачу заказа, запись платежей, проверку состояния заказа и управление запасами на складах.

Можно привести такой пример. Допустим, что в бизнес-модели TPC-С оптовый торговец (Компания) взаимодействует с некоторым числом принадлежащих ей складов в различных торговых районах. Соответствующий тест TPC-С сконструирован таким образом, чтобы можно было смоделировать рост компании и возникновение новых складов. Каждый склад в модели TPC-С поддерживает десять торговых районов, при этом в каждом торговом районе находятся три тысячи покупателей. Оператор торгового района в любой момент может осуществить транзакцию любого из пяти приведённых выше типов. Как и типы транзакций, частота возникновения транзакций модулируется на основе какого-то реального сценария.

Наиболее часто встречающимся типом транзакции является ввод нового заказа, который в среднем включает в себя десять наименований товаров. Каждый склад старается поддерживать у себя набор из ста тысяч наименований заказов, входящих в каталог компании. Тем не менее, на складе может не оказаться заказанного товара, в этом случае TPC-С предположит, что примерно десять процентов всего заказа находится не на региональном складе, а на складе другого региона.

Другим часто встречающимся типом транзакции является запись платежа, полученного от покупателя. Несколько менее часто у оператора возникает необходимость проверить состояние ранее размещённого заказа, отправить десять укомплектованных заказов или запросить систему о возможной нехватке товаров на складе. Уровень производительности, определяемый TPC-С, определяет число заказов, которые могут полностью быть обработаны за одну минуту. Единицей измерения этого уровня является tpmC, то есть число транзакций за минуту во время прохождения теста TPC-С.

Для того, чтобы тест мог работать с системами разного масштаба, реализация TPC-С позволяет изменять число терминалов и число и размер базы данных применительно к вычислительной мощности тестируемой системы.

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

Методика тестирования систем

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

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

Транзакция ввода нового заказа

Смысл транзакции при вводе нового заказа состоит в формировании полного заказа и отслеживании результатов его обработки. Транзакции этого типа встречаются наиболее часто, на них налагаются жёсткие временные ограничения.

Обычно при тестировании этого вида транзакций предполагается, что у компании есть один центральный склад. Номер торгового района выбирается случайным образом из интервала [1..10]. Случайным же образом из интервала [1..3000] выбирается номер покупателя. Число элементов в заказе выбирается случайным образом из интервала [5..15]. Номер элемента выбирается случайным образом н интервале [1..100000]. 1% всех новых заказов считаются ошибочными. Ошибочный заказ выбирается случайным образом (из интервала [1..100]) из каждой сотни поступивших заказов. Транзакции, обрабатывающие ошибочные заказы, откатываются.

Считается, что в 90% случаев требуемый товар находится на складе соответствующего торгового района. 10% заказов (десять заказов, случайно выбираемых из каждой сотни заказов) требуют обращения на склад другого торгового района.

Транзакция записи платежа, полученного от покупателя

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

В данном случае при генерации данных о покупателе в 60% случаев случайным образом выбирается фамилия покупателя, а в 40% – его идентификатор. Предполагается, что в 85% случаев платёж осуществляется в том регионе, жителем которого покупатель является. В 15% случаев предполагается, что платёж осуществляется из другого торгового района.

Транзакция проверки состояния заказа

Данные о покупателе формируются так же, как и в предыдущем случае. Номер торгового района выбирается случайным образом.

Транзакция доставки заказов

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

Транзакция запроса о наличии товаров на складе

Эта транзакция используется достаточно редко. При её использовании количество единиц товара генерируется случайным образом из интервала [10..20]

Представление результатов тестирования системы

Возможностью прохождения объективного тестирования в настоящее время пользуются множество разработчиков различных платформ. При этом не является редкостью факт, когда одна и та же фирма тестирует разные конфигурации производимых ею платформ. Нередки случаи, когда производители платформ, не удовлетворённые полученными при тестировании результатами, начинают искать различные «узкие» места, производить доработки, после чего повторно представляют платформу для тестирования. Примером тому является фирма IBM. Если взглянуть в таблицу 1, то можно заметить, что IBM выставляла для тестирования одну и ту же платформу дважды, 9-го мая и 30-го июня 2003 года. В конфигурации платформы никаких изменений не произошло. О чём это может свидетельствовать? Только о том, что за время, прошедшее между двумя тестированиями, платформа подверглась доработкам, которые привели к повышению производительности и, естественно, к понижению стоимости транзакции и соотношения «стоимость/производительность".

Но здесь, разумеется, необходимо заметить, что само по себе понижение стоимости транзакции не может служить характеристикой системы. Понятно, что стоимость транзакции будет падать не только благодаря повышению производительности, но и благодаря использованию более дешёвой аппаратуры. Например, настольный компьютер стоимостью в несколько сотен долларов может и, скорее всего, будет иметь лучшее соотношение «Стоимость/производительность», чем система масштаба предприятия, в состав которой входит несколько дорогих серверов. Следовательно, этот показатель можно использовать только при сравнении систем одного класса, одного масштаба.

В таблице 2 приведены результаты тестирования систем, показавших лучшие результаты в категории «Стоимость/производительность». Даже беглого взгляда на эту таблицу достаточно для того, чтобы понять, что платформы, включённые в эту таблицу, никак нельзя сравнивать с платформами, включёнными в таблицу 1. Как говорится, другой уровень.

Наверное, это было одной из причин того, что одним из требований, предъявляемых TPC, явилось требование опубликования полного отчёта о тестировании.

Чтобы познакомить читателей с примером опубликования результатов тестирования, я подробно просмотрел отчёт (Full Disclosure Report) для СУБД Microsoft SQL Server 2000 Enterprise Edition, работающей на ProLiant DL760-900-256P производства фирмы Compaq под управлением операционной системы Windows 2000 Advanced Server. Что мне бросилось в глаза во время знакомства с этим документом?

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

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

В соответствии с рекомендациями TPC, в отчёте приводятся также данные о ценах оборудования, на котором производилось тестирование.

Заметим, что правильность приведённых параметров, а также соответствие теста спецификациям и методологии TPC были удостоверены собственноручной подписью аудитора. С одной стороны, этот факт свидетельствует об открытости процесса тестирования системы, а с другой говорит о том, насколько высокое значение придаётся достоверности результатов тестирования.

Выводы

Разумеется, высокие требования, накладываемые условиями проведения тестов TPC, делают невозможным их воспроизведение предполагаемым покупателем той или иной системы. Поэтому достаточно справедливо будет относиться к результатам тестов, как к «выставке достижений народного хозяйства», где представлены наиболее выдающиеся образцы той или иной платформы.

Однако эти тесты достаточно адекватно отражают соотношение сил на рынке аппаратных и программных средств, предназначенных для делового применения, что достигается как благодаря ответственному подходу TPC к рассмотрению результатов тестирования, так и пристальным вниманием к этим тестам практически всех производителей «железа» и программного обеспечения. Поэтому изучение и сопоставление результатов тестирования различных систем может позволить принять решение о выборе системы обработки транзакций, основанное на относительно объективной информации.

Приложение 1. Системы, занимавшие в тестах TPC-C
первые места по производительности

Приложение 2. Системы, занимавшие в тестах TPC-C
первые места по производительности.

Copyright © 1994-2016 ООО "К-Пресс"