Оценка производительности программно
advertisement
Оценка производительности программно-аппаратных решений. Часть 1 Оценка производительности программно-аппаратных решений Проблема выбора Часть 1. «Универсальные интегральные тесты» Январь 2003 Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 О компании ................................................................................................................................3 Лицензионное соглашение .................................................................................................3 Оценка производительности программно-аппаратных решений. Проблема выбора. ........................................................................................................................................4 Введение .....................................................................................................................................4 Описание проблемы...........................................................................................................4 Существующие методы оценки производительности ........................................4 Постановка задачи .............................................................................................................5 Перспективы дальнейших исследований ................................................................5 Существующие универсальные тесты производительности систем ...............5 ♦ Интегральные тесты ......................................................................................................6 Описание тестов ..............................................................................................................6 Аналитическое рассмотрение тестов TPC..................................................................12 ♦ Основные достоинства теста TPC-C? ...................................................................13 ♦ Основные недостатки тестов TPC-C .....................................................................15 ♦ Корреляция тестов TPC-C и тестов приложений. ..........................................17 ♦ Рекомендации по использованию результатов тестов ...............................18 Выбор решения..............................................................................................................18 Тесты TPC в России...............................................................................................................19 ♦ Методика исследования ............................................................................................19 ♦ Результаты .......................................................................................................................21 ♦ Анализ оценок................................................................................................................21 Оценка производительности системы .................................................................22 Sizing (возможность использования для составления спецификации) ...............................................................................................................................................22 Технические достижения производителя..........................................................22 TPC менее значимо чем специализированные тесты .................................22 Осведомленность заказчиков о тестах ...............................................................22 Производительность в тестах не отражает надежность .............................23 Комментарии экспертов .............................................................................................23 Выводы.......................................................................................................................................26 Адреса использованных в исследовании ресурсов..............................................27 Copyright и торговые марки .............................................................................................27 Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 О компании Компания Elashkin Research занимается исследованиями компьютерных технологий и российского рынка enterprise решений. Специфика этого сегмента заключается в тесной интеграции компьютерных технологий, бизнес процессов и экономических показателей. При этом огромное значение придается пониманию технологий и путей внедрения технологий в бизнес процессы. Новые технологии, используемы в enterprise системах, зачастую весьма сложны для понимания, а часто еще не достаточно формализованы. Между тем, стоимость ошибки в прогнозе может быть весьма высока. Основным качеством любой компании, исследующей этот рынок, является глубокое понимание технологий, потребностей заказчика и существующих на рынке тенденций. Такой подход к исследованиям компании Elashkin Research и тесное сотрудничество с лучшими экспертами ведущих производителей и разработчиков современных enterprise технологий и решений делают компанию Elashkin Research лидером этого рынка. Более подробную информацию и другие отчеты вы можете найти на нашем сайте www.elashkin.com. Лицензионное соглашение Специальная лицензия для учебных заведений. Данная копия исследования предназначена для учебных и научных целей и лицензирована для факультета информационных технологий НГУ. Данная лицензия разрешает цитирование данных и текста данного отчета с обязательным указанием авторства. Данная копия может использоваться в научном и учебном процессе. Разрешается помещать ее на интернет и интранет сайтах, имеющих отношение к данному учебному заведению. Запрещается передача данного исследования другим организациям и сотрудникам других организаций и использование ее в коммерческих целях. Лица, не относящиеся к данному учебному заведению и заинтересованные в полной копии этого исследования, могут самостоятельно загрузить персональную бесплатную копию с сайта www.elashkin.com. Если вы не согласны с условиями лицензии, то вам следует удалить копии этого отчета и отказаться от его использования. Продолжение использования этого исследования автоматически означает согласие с условиями лицензирования. При использовании данных этого отчета, ссылка на Elashkin Research обязательна. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 Оценка производительности программно-аппаратных решений. Проблема выбора. Введение Описание проблемы Стандартной операцией при любом внедрении или изменении существующей информационной системы является оценка необходимого быстродействия системы и планирование необходимых ресурсов, как программных, так и аппаратных, для ее реализации. В настоящее время не существует абсолютно точного решения этой задачи, и если, несмотря на ее сложность и стоимость такой алгоритм будет предложен каким либо производителем, то даже небольшие изменения в аппаратной части, версии программного обеспечения, конфигурации системы или количестве или стандартном поведении пользователей, приведут к появлению значительных ошибок. Однако точное решение задачи планирования производительности не является обязательным условием для создания информационных систем решающих ту или иную задачу. Достаточно более или менее приблизительной оценки и разумное приближение выбранной системы оценок. При этом основной вопрос заключается уже в выборе модели для оценки и понимании допустимой ошибки этого метода. На практике оценка потенциальной производительности той или иной системы для решения конкретной задачи основывается на личном опыте лица принимающего решения или системного интегратора, предложившего решение. При этом оценка производительности системы проводится по аналогии с уже реализованными решениями с поправкой на маркетинговые материалы компаний производителей программного и аппаратного обеспечения или статьи в компьютерной прессе. Постоянный технический прогресс делает такой опыт быстро устаревающим. Кроме того, даже однотипные задачи могут иметь значительные различия, связанные с количеством пользователей, типом нагрузки, топологии сети и зависеть еще от целого ряда других факторов. Такой подход характеризуется высокой вероятностью ошибки, что приводит при недооценке возможностей выбранного решения к перерасходу денег, а при недооценке - к необходимости пересмотра проекта, его стоимости, сроков реализации и возврата инвестиций. Кроме того, абсолютное большинство проектов предусматривает рост нагрузки в будущем. Таким образом, ошибка в оценке производительности может сказаться не сразу, а в течение некоторого времени, когда возможностей ее исправить будет меньше, чем на начальной стадии реализации проекта. Положение дополнительно осложняется тем, что выбор того или иного решения происходит в условиях большой неопределенности, особенно характерной для России, когда неизвестно как будет в дальнейшем развиваться бизнес компании, какие новые технологии появятся и какие новые бизнес процессы будут автоматизированы. Существующие методы оценки производительности Если отбросить метод оценки производительности системы основанный на опыте лица принимающего решения или системного интегратора, то большинство существующих методов основывается на том или ином типе тестирования. Можно выделить два основных типа тестирования: компонентное и интегральное. При компонентном тестировании, проводится тестирование отдельных компонентов решения, начиная от производительности процессоров или подсистем хранения информации, до тестирования производительности сервера целиком, но без полезной нагрузки в виде того или иного бизнес приложения. Интегральный подход характеризуется оценкой производительности решения в целом, как его программной, так и аппаратной частей. При этом может использоваться как то бизнес приложение, которое будет использовано в конечном решении, так и некоторые модельные приложения, эмулирующие некоторые стандартные бизнес процессы и нагрузки. Кроме того, интегральные тесты можно разделить на Универсальные, Специализированные (тесты приложений) и Пилотные тесты. Более подробно эта классификация рассматривается в Таблице 1. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Таблица 1. Варианты интегральных тестов. Универсальный TPC Пример Программное обеспечение Аппаратное обеспечение Усредненная модель. Отличается от приложения, которое будет использовано в проекте. Отличается от аппаратуры, которая будет использована в проекте Специализированные SAP benchmark Совпадает с приложением в реальном проекте. Отличается от аппаратуры, которая будет использована в проекте. Тип нагрузки Усредненная модель. Отличается от нагрузки в реальном проекте. Усредненная модель. Отличается от нагрузки в реальном проекте. Настройка производительности Выполняется лучшими специалистами компаний производителей Выполняется лучшими специалистами компаний производителей Возможность тестирования в различных режимах Отсутствует, условия тестирования зафиксированы в стандарте теста Доступна Отсутствует, условия тестирования зафиксированы в стандарте теста Доступна Доступность информации о тесте Часть 1 Пилотные Тестирование приложения у заказчика Совпадает с приложением в реальном проекте. Может отличаться, при моделировании на меньшей машине, или совпадать при масштабном пилотном проекте. Возможна эмуляция соответствующая реальной ситуации в проекте. Выполняется силами системного интегратора или собственными силами Возможно Варьируется от полного отсутствия информации до полного доступа Независимые организации, компьютерные журналы и производители решений предоставляют значительное количество результатов разнообразных тестов. Однако сами по себе эти результаты не могут ответить на вопрос о выборе решения обладающего достаточной производительностью в каждом конкретном случае. Вместе с тем, не следует пренебрегать той информацией, которая содержится в этих тестах. Ее можно использовать для того, чтобы выбрать необходимую систему, обладающую нужной производительностью, или, как минимум, повысить точность оценки полученной другими методами. Постановка задачи Задачей данного исследования является анализ существующих универсальных интегральных тестов и той информации, которая может быть использована для оценки производительности систем в конкретных бизнес задачах. Перспективы дальнейших исследований Для составления полной картины оценки производительности программно-аппаратных решений следующие исследования будет посвящены «Специализированным тестам» и «Пилотным тестам», оставшимся за рамками данной работы. Таким образом, будет рассмотрены основные аспекты выбора оптимальной программно-аппаратной платформы для построения конкретной информационной системы. Кроме того, планируется отдельные исследования, посвященные кластерным системам. Существующие универсальные тесты производительности систем Универсальные тесты производительности систем существуют довольно давно. Пик их количества пришелся на середину – конец 90-х годов прошлого века. К настоящему времени вперед Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 вырвались несколько универсальных интегральных систем оценки производительности. Уменьшение количества различных тестов, скорее всего, связано с двумя причинами. Во-первых, такие тесты весьма дороги и компаниям производителям не выгодно вкладывать деньги в большое число разнообразных тестов. Кроме того, производителям нужна единая система, в которой результаты будут сравнимы между собой в одинаковых условиях. Во-вторых, уменьшение числа различных тестов связано с некоторым разочарованием в применимости их результатов к реальным информационным проектам и росту числа специализированных тестов. ♦Интегральные тесты Интегральные тесты производительности основаны на моделировании компьютерных информационных систем поддерживающих основные бизнес процессы. Широкое использование компьютеров в бизнесе началось достаточно давно, но особенное развитие этих технологий началось в начале 80-х годов. Этот процесс сопровождался изменением парадигмы компьютерных вычислений и дал мощный толчок взаимному прогрессу в области бизнес процессов и компьютерных технологий. В середине 80-х годов прошлого века начался новый этап развития компьютерных технологий и их применения в бизнесе. Этот этап характеризовался значительным ростом транзакций проводимых в режиме on-line, таких как транзакции проводимые кассиром банка или продавцом авиабилетов. Эти вычисления значительно отличались от пакетной обработки данных, характерной для бизнеса 60-х и 70-х годов, поэтому был предложен термин On-Line Transactions Processing или OLTP. Для оценки производительности таких систем первоначально использовался тест TP1, предложенный корпорацией IBM, и его модификации. В дальнейшем развитие информационных систем и бизнес процессов вызвало к жизни новые задачи, такие как Хранилища Данных, Системы Поддержки Принятия Решений (OLAP), Интернет технологии и другие. Соответственно были предложены новые тесты для оценки производительности систем для этих типов бизнес приложений. Описание тестов Transaction Processing Performance Council Самым известной организацией проводящей универсальные интегральные тесты является TPC (Transaction Processing Performance Council – Совет по Обработке Транзакций). TPC является независимой некоммерческой организацией, созданной для исследования обработки транзакций и производительности систем управления базами данных (СУБД) и распространения объективной и воспроизводимой информации о производительности в тестах TPC для компьютерной индустрии. Кроме результатов тестов производительности в рамках тестов TCP рассчитывается относительный критерий производительность/стоимость, включающий стоимость программного и аппаратного обеспечения и стоимость владения в течение эксплуатации. В настоящее время TPC является наиболее авторитетной организацией проводящей тестирование бизнес систем. Первоначально Совет по Обработке Транзакций фокусировался на компьютерном аспекте создания компьютерных тестов оценки производительности OLTP систем, но вскоре был вынужден начать работу по стандартизации процедуры представления результатов и участия в тестах. В настоящее время тесты TPC включают не только техническую спецификацию, но и формализованную процедуру проведения тестов, представления результатов, а также обязательный аудит результатов независимой аудиторской компанией. Можно не соглашаться с техническими аспектами тестов и их соответствием реальным условиям эксплуатации бизнес приложений, но TPC является наиболее авторитетной в мире организацией по тестированию производительности и ее результаты действительно независимы и воспроизводимы. Членство в Совете по Транзакциям практически всех основных игроков на этом рынке, политика аудита и одобрения всеми членами совета представленных результатов, не позволяет использовать авторитет Совета в своих целях кому-либо из производителей аппаратного или программного обеспечения. В настоящее время в TPC входят следующие компании (см. Табл. 2) Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 Таблица 2. Члены Transaction Processing Performance Council Кроме того, в TPC входят Ассоциированные члены, основным отличием которых является то, что они не производят программного или аппаратного обеспечения, участвующего в тестах TPC. Список таких членов приведен в Таблице 2а. Стоимость членства в TPC составляет $15.000 в год. Таблица 2а. Ассоциированные члены Transaction Processing Performance Council Premera Blue Cross Open Source Development Lab Inc. Аудит полученных результатов проводят независимые компании InfoSizing и Performance Metrics. TPC тесты В таблице 3 приведены основные тесты проводившиеся Transaction Processing Performance Council. Были предложены еще тесты TPC-S, TPC-E и TPC-C/S, но они не были приняты на заседании TPC. Таблица 3. Список тестов TPC. Название теста Краткое описание TPC-A Выполнение одиночных транзакций в архитектуре «клиент-сервер» TPC-B Выполнение транзакций «внутри» СУБД, отсутствует клиентские сессии. Может рассматриваться как stress test СУБД TPC-C Индустриальный стандарт de facto в области OLTP систем TPC-D Системы Поддержки Принятия Решений, сложные, долго выполняемые запросы к большим сложным структурам данных TPC-H Ad hoc запросы, Системы Поддержки Принятия Решений. TPC-R Системы Поддержки Принятия Решений. Подготовка отчетов. Отличается от TPC-H тем, что разрешена оптимизация структуры СУБД, на основе информации о возможных типах запросов. TPC-W Тесты производительности систем eCommerce для web. Текущая версия Прекращена поддержка с 6/6/95. Последняя версия 2.0 Прекращена поддержка с 6/6/95. Последняя версия 2.0 Текущая версия 5.0 Прекращена поддержка с 4/6/99. Последняя версия 2.1 Пришел на смену TPC-D тестов. Текущая версия 2.0.0 Текущая версия 2.0.0. Происходит переход с версии 1.4.0. Доступны результаты тестирования по обеим спецификациям. Текущая версия 1.7. Версия 1.8 вводится с 19/4/03 и уже доступна. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 TPC-C TPC-C – один из наиболее удачных тестов TPC ставший индустриальным стандартом de facto. Первая версия этого теста была принята в июле 1992 года. TPC-C является более комплексным тестом, чем существовавшие ранее тесты, такие как TPC-A. Он включает набор параллельно выполняемых транзакций различных типов и сложности. База данных в тесте TPC-C состоит из девяти типов таблиц, содержащих широкий диапазон значений и имеющих большой размер. Результаты теста измеряются в числе транзакций в такой системе в минуту (tpmC). Соотношение цена/производительность измеряется в стоимости одной транзакции в данном тесте. Каждый принятый TPC результат содержит подробную информацию об использованном оборудовании, программном обеспечении и стоимости владения. Если необходимо, то можно пересчитать этот параметр, используя свои данные по скидкам, представляемым именно вашей компании производителями, и получить собственные данные. С точки зрения бизнес процессов, TPC-C симулирует компьютерную среду, в которой большое число пользователей выполняют транзакции с использованием данных, хранящихся в СУБД. Подобная бизнес активность характерна для систем ввода заказов, вне зависимости от области деятельности, будь это система управления предприятием или заказ авиабилетов. Этот тест включает симуляцию ввода заказов, выдачу накладных, внесение информации о платежах, проверку состояния заказов и отслеживании состояния склада. Нагрузка на систему и структура базы данных выбраны такими, что они не являются специфичными для какой либо конкретной отрасли, но отражают усредненный бизнес по управлению, продажам или дистрибуции неких товаров или услуг. Последняя версия теста TPC-C, отличается в основном изменением принципов подсчета относительной стоимости и соответственно результаты тестов предыдущей версии, в области максимальной производительности могут быть использованы с определенными оговорками. Так введено правило создания отчетов о необслуженных запросов пользователей, что может незначительно уменьшить общую производительность системы в этой версии теста. В новой версии изменены правила расчета совокупной стоимости владения. Так уменьшен период, в течение которого рассчитывалась эта стоимость, с 5 до 3 лет, изменены условия расчета стоимости технической поддержки с поддержки 8х5 (восемь часов х пять дней в неделю), на 24х7 (полные сутки без выходных). Из стоимости решения исключена стоимость сетевого оборудования, увеличено время проведения теста с 20 минут до 2-х часов, уменьшены требования к дисковому пространству (теперь требуется хранение данных об операциях в течение 60 дней против 180 дней в предыдущей версии) и т.д. TPC-H Тест TPC-H (версия 1.0.0 принята в феврале 1999 года) оценивает производительность Систем Поддержки Принятия Решений. Он состоит из набора сложных, бизнес ориентированных ad-hoc запросов (Ad-hoc (лат) – «к этому, для данного случая, для этой цели», запросы, возникшие в настоящий момент, которые нельзя было предусмотреть заранее). Как и в остальных тестах симулируется поступление запросов от большого числа пользователей. Данные в таблицах и запросы составлены так, чтобы отражать некоторую усредненную по индустрии бизнес активность. Типичные запросы составлены так, чтобы отражать основные типы запросов в Системах Поддержки Принятия Решения: ценообразование и скидки, управление прибылью, исследование предпочтений покупателей, исследование рынка и т.п. Важным отличием TPC-H от его предшественника TPC-D, является возможность продолжения выполнения OLTP транзакций с тестовой базой данных. Таким образом, выполнение TPC-H запросов не заставляет отключать СУБД от других операций. Производительность измеряется в числе выполненных в течение часа запросов при определенном размере СУБД (QphH@Size). В настоящее время используются базы данных размером 100, 300, 1000 и 3000 GB. TPC-R Тесты TPC-R практически полностью совпадают с тестами TPC-H (практически полностью совпадает спецификация, в которой часто путают тесты TPC-R и TPC-H). Основное отличие заключается в том, что характер запросов считается известным и позволяется оптимизация, связанная с этим. Производительность измеряется в числе выполненных в течение часа запросов при определенном размере СУБД (QphR@Size). В настоящее время используются базы данных размером Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 100 и 1000 GB. Данный тест пока не пользуется популярностью и содержит всего несколько результатов. TPC-W Тесты TPC-W определяют производительность транзакций системы для задачи электронной коммерции (e-Commerce). В этом тесте нагрузка ложится не только на сервер базы данных, но и веб сервер, кэш сервер, хранение изображений и СУБД. В тесте симулируется следующая нагрузка: - Множественные соединения с клиентами (браузерами) - Создание, обновление и доступ к динамическим веб страницам - Использование consistent веб объектов - Одновременное исполнение множества разнородных транзакций - OLTP модель - Сложная структура СУБД - Целостность транзакций - Конкурентный доступ к данным и изменение данных. Тест поддерживает три различных профиля взаимодействия с пользователями: - Покупки (WIPS) (интегральный параметр) - Просмотр (WIPSb) (дополнительная метрика) - Система ввода заказа (WIPSo) (дополнительная метрика) Профиль WIPSb соответствует ситуации, когда большая часть посетителей (95%) просто просматривает содержание сайта, а 5% выполняет ввод заказов. Профиль WIPSb подразумевает преимущественный (50%) ввод заказов. Этот профиль значительно больше нагружает СУБД часть теста. Производительность измеряется в единицах WIPS (Web Interactions per Second) TPC-W являются одними из наиболее комплексных тестов проводимых TPC. В этом тесте симулируется доступ к 14 типичным страницам в типичных Интернет задачах (таких как базовая страница, поиск, новые продукты, лучшие покупки и т.п.), при этом выбор страниц осуществляется не по случайному механизму, а в соответствии с элементами навигации на них. Поведение покупателя тоже воссоздается в соответствии с типичными моделями поведения, полученных в реальных системах и усредненных. SPEC SPEC (Standard Performance Evaluation Corporation – Корпорация по Стандартам Оценки Производительности) – является бесприбыльной организацией созданной для того чтобы устанавливать и поддерживать стандарты, которые могут быть применены в последних поколениях высокопроизводительных компьютеров. SPEC также широко известна в компьютерных кругах, но в основном своими компонентными тестами. Наиболее известные тесты SPEC CPU. Однако поле деятельности SPEC гораздо шире. На самом деле это «зонтик», объединяющий три группы: - Open Systems Group (OSG) (Интегральные и компонентные тесты производительности в среде UNIX / NT / VMS). - High Performance Group (HPG) (Тесты производительности в области высокопроизводительных численных вычислений) - Graphics Performance Characterization Group (GPCG) (Тесты производительности графических подсистем, OpenGL и Xwindows). SPEC тесты Наиболее интересными в рамках этого отчета являются интегральные тесты OSG. Следует отметить следующие интегральные тесты: SPECjAppServer (Java Application Server) SPECjAppServer2001 является одним из индустриальных стандартов тестирования производительности серверов обслуживающих приложения J2EE. Этот тест построен на основе известного теста ECperf 1.1 являющегося стандартом de facto, предложенного сообществом Java. ECperf был лицензирован компанией Sun Microsystems для SPEC в 2001 году и незначительно модифицирован SPEC. Основная причина появления SPEC теста, заключается в том, что ECperf является спецификацией, а не организацией, способной организовывать тестирование, представление результатов и другие сервисные функции. Однако результаты ECperf и SPEC не могут сравниваться между собой в связи с различиями в методике тестирования. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 Более новая версия теста SPECjAppServer2002 практически полностью соответствует SPECjAppServer2001, за исключением того, что Enterprise Java Beans (EJB) определены в соответствие со спецификацией EJB 2.0, в отличие от предыдущей версии, использовавшей спецификацию EJB 1.1. В настоящее время идет разработка следующей версии теста SPECjAppServer2003 тестирующего производительность систем J2EE 1.3 и отличающегося увеличенной нагрузкой за счет добавления уровней веб, JMS и некоторых других изменений. Тесты SPECjAppServer являются действительно индустриальными тестами. Информационная структура, использованная в этих тестах, соответствует реальным распределенным, критически важным, работающим круглосуточно enterprise бизнес приложениям. По своей нагрузке они не уступают тестам TCP, но в отличие от последних, нагружают не столько СУБД, сколько тестируют возможности EJB управлять памятью, при использовании сложных конструкций, оптимизировать удаленные вызову, кэшировать задания, и др. SPEC MAIL2001 Первый индустриальный интегральный универсальный тест, измеряющий производительность систем обработки e-mail по протоколам SMTP and POP3. В связи с распространением почтового протокола IMAP в настоящее время идет разработка спецификации соответствующего теста SPECimap2003. SPEC WEB99/WEB99_SSL SPECweb99 является тестом производительности World Wide Web серверов. В этом тесте симулируется типичная нагрузка веб серверов, включая: • • • • • • • Измерения ведется в одновременных соединениях, а не в операциях HTTP Симулируются соединения по линиям ограниченной пропускной способности Используется динамический и статический метод GET Используется метод POST Используются постоянные соединения - keepalives (HTTP 1.0) и persistent connections (HTTP 1.1) Динамическая ротация баннеров Структура файловой системы соответствует реальным примерам SPECweb99-SSL – вариант теста SPECweb99 работающий по защищенному соединению. Другие тесты Наиболее быстро растущая область – это тесты производительности современных технологических решений, работающие в Интернет-интранет сетях, реализующие различные модели распределенных вычислений, таких как J2EE или .NET. Кроме упомянутых SPECweb99 и TPC-W, реализующих несколько устаревшую, но по прежнему актуальную, модель интернет-вычислений, следует отметить SPECjAppServer и его идейного вдохновителя ECperf, послужившего основой целого ряда тестов. Однако основная тенденция в использовании целого ряда современных тестирующих продуктов это отход от бесприбыльных общественных организаций. Ряд компаний предлагают свои тесты и услуги по тестированию, но уже как коммерческий продукт. Не следует думать, что эти услуги обязательно дороже, чем «бесприбыльные» общественные тесты. Так стоимость членства в TCP составляет $15.000, а стоимость самого тестирования не афишируется, но может доходить до $1.000.000. Проблема этих компаний заключается в том, что при таком подходе тесты превращаются в средство настройки приложений, а их результаты не публикуются. Хотя такие тесты больше подходят для рассмотрения в третьей части нашего исследования «Оценка производительности программно-аппаратных решений. Проблема выбора» - Пилотные тесты, но поскольку компании производители часто ссылаются на результаты таких тестов в своих материалах, здесь будут приведены основные игроки. Mindcraft! Компания Mindcraft, основанная в 1985 году, является крупным центром тестирования (самая крупная лаборатория тестирования POSIX). Принимая участие в общественном проекте SPEC, эта компания разработала ряд собственных тестов, фокусирующихся на открытых интернет Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 протоколах HTTP, LDAP, POP3 и IMAP4. Результаты измерения производительности доступны. Основные тесты приведены ниже. DirectoryMark 1.0 DirectoryMark является тестом производимости LDAP на различных серверных платформах. DirectoryMark симулирует запросы от ряда клиентов производящих LDAP транзакции на сервере. При этом каждый клиент выполняет определенный набор операций характерный для реальных LDAP систем. WebStone Это тест базируется на тесте, разработанном компанией Silicon Graphics для определения интегральной производительности веб серверов. Mindcraft выкупила права на этот тест и внесла в него серьезные изменения. В частности этот тест был портирован на ряд новых операционных систем, кроме CGI скриптов расширена поддержка API протоколов. Результаты тестов последней версии 2.5 полностью совместимы с версией 2.0.1, при условии использования такой же нагрузки. AuthMark AuthMark – самый новый тест компании Mindcraft, оценивает производительность системы авторизации и идентификации доступа к веб сайтам. Идентификация это процесс определяющий кто именно пытается получить доступ к информации (обычно соответствует процессу Log In). Авторизация определяет к какого рода информации и сервисам идентифицированный пользователь может иметь доступ. AuthMark состоит и набора сценариев действий пользователей требующих идентификации и авторизации. Наиболее используемыми являются два сценария: Login – фокусируется на тестировании идентификации, симулируя запрос и получение первой страницы защищенного веб сайта. Extranet – симулирует поведение покупателя или поставщика при работе с закрытым веб сайтом и получение информации для доступа к которой он авторизован. Empirix Основанная в 2000 году компания Empririx еще более ориентирована на коммерческие тесты. Empirix предлагает следующие продукты. Perormance monitoring OneSight – приложение осуществляющее мониторинг веб сайтов и FarSight – удаленный сервис, позволяющий проводить дистанционный мониторинг аналогичный OneSught. Данные приложения нельзя отнести к универсальным тестам, скорее это средства оптимизации и настройки уже существующих приложений. Тесты e-TEST suite Набор тестов производительности современных веб приложений. Результаты также не публикуются и не могу служить данными для анализа. Состоит из следующих компонентов. e-Tester Оценка функциональности и уменьшения скорости отклика с увеличением нагрузки e-Load Нагрузочный тест, позволяющий оценить масштабируемость решения. e-Manager Enterprise Система управления процессом тестирования Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 e-LoadExpert. Remote load testing service Консультационная услуга, позволяющая с помощью тестовых пакетов Empirix производить дистанционную настройку производительности системы. Bean-test. EJB performance testing solution Дальнейшее развитие EJB тестов. Коммерческий продукт ориентированный более на настройку конечного приложения, чем на стандартные тесты. Используется компаниями Oracle и BEA для собственных тестов. FirstACT Тест для настройки производительности Веб Сервисов (Web Service), основанных на протоколе SOAP. Результаты не публикуются. IP Storage Test Пример слияния интегрального и компонентного подхода, характерный для современных технологий. Тестируется производительность хранения данных в сети на основе технологии SAN. VoIP Test Еще один пример того, как коммерческие компании быстрее реагируют на реалии сегодняшнего дня. Тест производительности систем передачи голоса по IP. Работает только в системах одного производителя. Ценности для выбора решения не имеет. NetBench I/O Тест, разработанный журналом PC Magazine. Оценивает работу сервера в качестве файл сервера для клиентов на основе Windows. Бесплатный. Результаты тестов различного оборудования доступны на сайте PC Magazine, но довольно сильно разбросаны по разным статьям и недостаточно систематизированы. dkftpbench Еще один бесплатный универсальный тест, ориентированный на оценку производительности FTP сервера. Учитывает ограниченность пропускной способности каналов клиентов. Методика тестирования перенесена с теста SPECweb99 на другую задачу. Не очень популярен, но практически единственный общедоступный тест в этой области. Платформозависимые тесты В этот отчет не входят интегральные тесты, не удовлетворяющие условию универсальности. В основном это тесты, ориентированные на продукты одного из производителей (например, Microsoft Active Directory), или работающие только под одной операционной системой (чаще Windows). Устаревшие тесты В 80-е и 90-е году было предложено большое число разнообразных интегральных и компонентных тестов. Не все из них дожили до сегодняшнего дня. Меньше всего повезло универсальным тестам, построенным на симуляции нагрузки сервера набором прикладных задач, таким как ZD ServerBench, AIM, Nhfsstone (послужил основой также устаревающего SPEC SFS97), устаревших тестов TPC – TPC-A, TPC-B и TPC-D и др. Аналитическое рассмотрение тестов TPC Тесты TPC на сегодняшний день остаются одними из наиболее востребованных на рынке интегральных универсальных тестов. Эти тесты проводят и поддерживают крупнейшие мировые производители, тестирование беспристрастно и сопровождается обязательным независимым аудитом, условия тестирования открыты, результаты общедоступны и весь процесс находится под управлением некоммерческой общественной организации обладающей высоким авторитетом. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 К сожалению, многие из перечисленных достоинств стали недостатками этих тестов. Так некоторые производители разрабатывают свои продукты, вводя в них функции, основное назначение которых показать высокие результаты в тестах TPC. Кроме того, тесты в значительной степени ориентированны на архитектуру клиент - сервер, в то время как современные информационные технологии все больше тяготеют к трехуровневой архитектуре (клиент – сервер приложений – сервер) и распределенным вычислениям (в приложении к Российской действительности, большая часть приложений по прежнему строится по схеме клиент-сервер, но наблюдаемая тенденция такая же, как и во всем мире). Тесты TPC, как и все перечисленные в этом обзоре тесты, имеют отношение только к производительности выполнения некой усредненной задачи и ничего не говорят о надежности системы, удобству средств администрирования, резервного копирования и восстановления баз данных, построения распределенных систем и репликации данных в них. Словом тем параметрам, которые с каждым годом становятся все более важными при принятии решения. Какие ограничения следует принять во внимание, при использовании данных TPC для оценки производительности систем? В первую очередь следует ограничиться тестом TPC-C. Тесты TPC-R и TPC-W, несмотря на более современную архитектуру последнего, эти тесты не пользуются большой популярностью у производителей. А использование теста TPC-H является частью более сложной задачи – построения хранилища данных, где вопрос производительности только часть более сложной задачи. ♦Основные достоинства теста TPC-C? 1. 2. 3. Это действительно универсальный интегральный кроссплатформенный тест. Трудно найти другой тест, сравнивающий большее количество аппаратных платформ (кластеры, SMP и др.), операционных систем и СУБД. Можно оценить стоимость решения в расчете на одну транзакцию. Интегральный тест позволяет точнее оценить общую производительность системы, в отличии от компонентных тестов. Проиллюстрировать это можно с помощью следующим образом (см. Таблицу 4). Таблица 4. Сравнение TPC-С и CINT2000 Rate Процессор Число CINT2000 процессоров Rate IBM eServer IBM RS64 IV 8 36.9 pSeries 660 750MHz Model 6M1 Fujitsu Fujitsu 16 82.5 PRIMESPARC64 GP POWER 850 675MHz Модель TPC-C (tpmC) 105,025 $/ tpmC 112,286 13.44 23.45 При очень близких результатах в тесте TPC-C, рейтинг процессорной мощности, полученной по тестам SPEC, отличается более чем в два раза. При этом стоимость одной транзакции также различается почти в два раза, что говорит о необходимости комплексного сравнения результатов тестов по нескольким параметрам одновременно. Очевидно, что компонентные тесты менее точно отражают общую производительность системы. Это неудивительно, так как такая задача не входит в их область применения. Тем не менее, использование результатов компонентных тестов позволяет специалистам, имеющим соответствующую квалификацию, понять, за счет чего была достигнута та или иная производительность в интегральных тестах и прогнозировать масштабируемость такого этого решения. 4. Проверка реальной масштабируемости SMP систем и кластеров (с учетом замечаний по кластерам далее в этом разделе). Рассмотрим рост производительности в SMP системах (Таблица 5). Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 Таблица 5. Сравнение TPC-C (СУБД SymfoWARE Server Enterp. Ed. VLM 3.0, OS Sun Solaris 8) Fujitsu PRIMEPOWER 2000 Fujitsu PRIMEPOWER 2000 Процессор Fujitsu SPARC64 GP Fujitsu SPARC64 GP 563MHz 563MHz Всего процессоров 48 128 TPC-C (tpmC) 222,772 455,818 Производительность 4640 3561 на один процессор (tpmC/CPU) $/ tpmC 43.42 28.58 Как видно из приведенных данных увеличение числа процессоров в 2.67 раза привело к двукратному росту производительности. Т.е. в пересчете на удвоение числа процессоров это дает прирост производительности на 75%, что является очень хорошим результатом для SMP систем. Следует отметить, что удвоения производительности при увеличении числа процессоров в 2 раза практически никогда не происходит. Другим интересным результатом нашего анализа является уменьшение стоимости одной транзакции в 1.5 раза с ростом производительности в 2 раза и увеличении числа процессоров в 2.67 раза. Аналогичный анализ для кластерной архитектуры приведен в Таблице 6. Таблица 6. Сравнение TPC-C (СУБД Microsoft SQL Server 2000 Enterprise Edition, OS Microsoft Windows 2000 Advanced Server) ProLiant DL760ProLiant DL760ProLiant DL760900-128P 900-192P 900-256P Процессор Intel Pentium III Intel Pentium III Intel Pentium III Xeon 900 MHz Xeon 900 MHz Xeon 900 MHz Всего процессоров 136 204 272 Процессоры рабо128 192 256 тающие с СУБД TPC-C (tpmC) 410,770 567,883 709,220 Производительность 3020 2784 2607 на один процессор (tpmC/CPU) Производительность 3209 2958 2770 на один процессор (tpmC/CPU) работающий с СУБД $/ tpmC 13.02 14.04 14.96 Различие в числе процессоров обслуживающих СУБД и общем числе процессоров связано с тем, что в тестируемых кластерах несколько компьютеров обслуживают функционирование кластера в роли DTC сервера. Таким образом, увеличение числа процессоров в два раза приводит к увеличению производительности примерно на 72%, что сравнимо с SMP решениями. Кластерные решения, при выполнении ряда условий, обеспечивают как дополнительные преимущества, так и дополнительные недостатки. Более подробно этот вопрос будет рассмотрен в следующем разделе. Следует также отметить, что стоимость решения в расчете на одну транзакцию меняется слабо. 5. Позволяет сравнить компьютеры разных производителей, даже базирующихся на разных технологиях и операционных системах (см. Таблица 4). Кроме того, можно провести сравнение разных линеек компьютеров одного производителя (см. Таблица 7). Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 Таблица 7. Сравнение компьютеров из двух линеек компании Hewlett-Packard ProLiant DL760-900-128P HP 9000 Model Superdome Enterprise Server Архитектура Кластер SMP Процессор Intel Pentium III Xeon 900 MHz HP PA-RISC 8700 875MHz Число процес136 64 соров OS Microsoft Windows 2000 AdHP UX 11.i 64-bit vanced Server СУБД Microsoft SQL Server 2000 En- Oracle 9i Enterprise Dataterprise Edition base Server 9.2.0.1 TPC-C (tpmC) 410,770 423,414 $/ tpmC 13.02 15.64 6. Сравнение программного обеспечения. Например, старые тесты на компьютерах Digital, показали 16.5% разницу в производительности на однотипных компьютерах операционной системы OpenVMS над OSF/1. Более актуальными являются данные, приведенные в Таблице 8. Таблица 8. Сравнение производительности и стоимости для СУБД Oracle и серверов HP, для операционных систем Windows 2000 и Red Hat Linux HP ProLiant DL580-PDC 32P HP ProLiant DL580-PDC 32P Архитектура Кластер Кластер OS Red Hat Linux Advanced Microsoft Windows 2000 AdServer vanced Server СУБД Oracle 9i R2 Enterprise EdiOracle 9i R2 Enterprise Edition tion TPC-C (tpmC) 138,362 137,261 $/ tpmC 17.38 18.46 Несколько большая производительность системы под Linux на самом деле составляет менее 1%, а вот отличие в цене составляет более 6%. Однако тщательный анализ стоимостного компонента, показывает, что отличие в стоимости программной компоненты решения, построенного на Linux, от решения на основе Windows составляет менее одного процента от общей стоимости. Что очевидно, при общей стоимости системы около двух с половиной миллионов долларов и стоимости СУБД Oracle для этой конфигурации свыше миллиона долларов, стоимость Linux на сервере в 6400 долларов или Windows 2000 порядка 25000 долларов (все цены с учетом поддержки на 3 года) не играет никакой роли. Возможно, что это соотношение будет отличаться для более дешевых систем. Кроме того, принятие решения, о выборе операционной системы основываясь на стоимостных параметрах, в значительно большей степени должно базироваться на оценке стоимости администрирования и обслуживания, не учитываемых в тестах TPC. Очевидно, что гораздо большее влияние на выбор будут оказывать надежность, отказоустойчивость и защищенность решения. ♦Основные недостатки тестов TPC-C Следует отметить, что тесты TPC-C в свое время были большим шагом вперед в области оценки производительности OLTP транзакций. Однако быстрое развитие технологий выявило ряд ограничений и недостатков этих тестов, которые следует принимать во внимание, используя их для выбора основы для своей информационной системы. Можно выделить две основных группы: архитектурные и методологические недостатки. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 Архитектурные: 1. 2. 3. 4. 5. 6. Тесты TPC-C являются классическими тестами в архитектуре клиент-сервер, в которых в качестве клиента используется клиентская часть приложения, написанная на каком либо языке программирования и размещенная на настольном компьютере под управлением какой-либо 32-х разрядной версии Windows. Это ограничение не учитывает все более популярные типы современных клиентов: браузеры, мобильные телефоны, мобильные компьютеры (PDA), кассовые терминалы, ридеры штрих кода и др. Тестирование проводится в двухуровневой архитектуре клиент-сервер. Не используется все более популярная трехуровневая архитектура (клиент – сервер приложений – сервер). Не тестируется поддержка индустриальных стандартов SOAP/XML. В тесте отсутствуют очень распространенные в современных иерархических базах данных транзакции требующие операцию двухфазного коммита (2-phase commit). В тестах отсутствуют необходимые операции по резервному копированию – восстановлению данных, являющиеся важной частью реальных бизнес систем. Тесты не оценивают возможности быстрого восстановления системы после сбоев. Отсутствует поддержка использования исполняемых модулей на современных языках программирования Java и C#. Методологические: 1. 2. 3. 4. 5. В тестах TPC-C все пользователи имеют равные права. Не поддерживаются опции защиты содержимого базы данных, включая шифрование и расширенный контроль доступа. Ограниченность модели данных. В тестах TPC-C используется структура данных, состоящая только из 9 таблиц. Многие реальные приложения большую часть времени также используют сравнительно небольшое количество таблиц, но для более реалистичного приближения необходимо, в небольшом числе случаев, использовать более сложную модель данных (см. следующий пункт). Кроме того, в реальных приложениях может использоваться больше триггеров и правил для обеспечения целостности данных. В тестах TPC-C используется пять типов транзакций отражающих основные бизнес операции реальных систем. Эти транзакции отражают только основные бизнес операции. В реальных бизнес процессах всегда присутствуют более редкие, но значительно более требовательные к ресурсам операции, такие как заказ запасных частей к существующему оборудованию и т.п. Подобные запросы часто возникают в ситуациях, когда предлагаемый товар состоит из нескольких частей, которые в свою очередь также могут состоять из нескольких компонентов. Эти запросы не столь сложны, как в системах поддержки принятия решений, но они часто встречаются в реальных системах, в то время как в тестах TPC-C они отсутствуют. Типы данных, используемые в тестах, ограничены. Не используются изображения, тексты и другие мультимедийные данные. Увеличение размеров базы данных при увеличении бизнеса в тестах TPC-C построено по линейному закону. Т.е. добавление еще одного склада приводит к пропорциональному росту объема данных во всех таблицах базы данных и добавлению 10 дополнительных пользователей. В реальном приложении это может не соответствовать действительности. Отдельно следует отметить вопрос, связанный с кластерными архитектурами Shared Disk и Shared Nothing. При первом подходе каждая нода кластера работает с общими для всего кластера дисковыми массивами, при этом диспетчер запросов осуществляет балансировку нагрузки. При втором подходе каждая нода отвечает за некоторую часть СУБД (скажем за записи от А до Е) и работает практически независимо. При таком подходе построение решения требует тщательной предварительной проработки с целью правильно распределить данные по нодам, что само по себе является нетривиальной задачей. Кроме того, изменения типичной активности пользователей может привести к тому, что спланированное заранее разбиение окажется неэффективным и потребуется очень большая работа по реорганизации и перенастройке базы. Кроме того, такая кон- Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 фигурация гораздо более чувствительна к сбоям аппаратуры. При выходе из строя одной из нод, часть базы данных будет недоступна пока другая нода не возьмет ее задачу на себя. При этом общая производительность системы деградирует сильнее, чем для архитектуры Shared Disk. Shared Disk кластеры лишены этих недостатков. С другой стороны, если в архитектуре Shared Nothing (федеративные базы данных по терминологии Microsoft), обработка запроса направляется к именно к той ноде, которая работает с этим участком базы данных, причем с высокой вероятностью запрошенные данные уже могут находиться в кэш-памяти и будут быстро обработаны, то в Shared Disk архитектуре - высока вероятность того, что запрошенные данные могут находиться в памяти на другой ноде. При этом если они находятся в кэш-памяти, то высока вероятность, что они могли быть изменены. При этом для сохранения целостности базы данных необходимо будет провести запись данных из кэша на жесткий диск, затем нода, к которой был обращен запрос будет должна считать их с диска. Т.е. в случае запроса к данным, обрабатывающимся на другой ноде, будет необходимо провести две медленных операции запись/чтение с диском. Кроме того, в такой архитектуре всегда присутствуют накладные расходы на разрешение таких конфликтов (DLM – distribution lock manager). Эта особенность кластеров архитектуры Shared Disk в определенной степени сдерживала их распространение. Однако, в настоящее время эта проблема в основном разрешена за счет того, что обмен данными из кэш памяти нод производится не через медленный диск, а через высокоскоростной канал связи между нодами. При этом скорость обработки запроса, данные которого находятся в кэше другой ноды, оказывается выше, чем если бы эти данные находились на разделяемом диске. Разумеется, такая возможность должна быть предусмотрена производителями СУБД (многие СУБД, использующие Shared Disk архитектуру, предусматривают такую возможность). Наиболее полная поддержка такой схемы предусмотрена сегодня в СУБД Oracle (Oracle Real Application Cluster – Oracle9iRAC). Таким образом, архитектура Shared Nothing позволяет достигать максимальной производительности и очень простой масштабируемости в задачах OLTP и хранилищах данных, что видно в тестах TPC-C и TPC-H. Платой за эту масштабируемость является меньшая устойчивость к сбоям аппаратуры и жесткая привязка к разбиению базы данных по нодам (partitioning) на этапе планирования, а следовательно затраты на возможный реинжениринг при эксплуатации в течение длительного времени в условиях изменяющегося бизнеса. Архитектура Shared Disk более устойчива к сбоям, позволяет добавлять дополнительные ноды, при необходимости увеличить общую производительность системы («плати когда понадобится»), при несколько больших накладных расходах при эксплуатации. Тесты TPC-C не учитывают этой специфики, поэтому следует осторожно оценивать результаты кластерных тестов, особенно с архитектурой Shared Nothing. ♦Корреляция тестов TPC-C и тестов приложений. Несмотря на абстрактный характер и перечисленные выше недостатки, попробуем оценить существует ли корреляция между тестами TPC-C и более специализированными тестами. Например, тестами SAP benchmark. Для сравнения возьмем результаты показатели тестов TPC-C (tpmC) и тест SAP ATO (Число полностью обработанных заказов на сборку - Fully Processed Assembly Orders Per Hour). Тест SAP ATO является несравнимо более сложным тестом, в нем используется большое число модулей SAP, множество сложных транзакций, моделируется ввод данных пользователем и т.п. Кроме того, конфигурации компьютеров, использованных в тестах, сильно различаются по количеству использованной памяти (в тестах SAP ее обычно меньше) и дисковым массивам. Тем не менее, учитывая эти отличия, было бы интересно сравнить эти тесты. Для того чтобы сравнивать эти тесты мы выбрали двухуровневую (2-tier) архитектуру SAP, как более соответствующую клиент-серверной природе тестов TPC-C. Результаты приведены в Таблице 9. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Таблица 9. Сравнение результатов тестов TPC-C и SAP АТО. Компьютер TPC OS/СУБД TPC-C SAP Fully Processed (tpmC) OS/СУБД Assembly Orders Per Hour (SAP ATO benchmark) IBM eServer AIX/Oracle 220,807 AIX/DB2 8,570 pSeries 680, 24 процессора Fujitsu Siemens Solaris 455,818 Solaris/Oracle 34,260 Primepower /SymfoWARE 2000, 128 процессоров HP NetServer Windows/SQL 43,047 Windows/SQL 1,610 LXr8500, 8 Server Server процессоров HP rx5670, 4 Windows/SQL 87,741 HP-UX/Oracle 3,090 процессора Server HP9000 Super- HP-UX/Oracle 389,434 HP-UX/Oracle 16,480 dome Enterprise Server, 64 процессора Часть 1 Соотношение (TPC-C/SAP) 25.8 13.3 26.7 28.4 23.6 Несомненно, что такая незначительная выборка не позволяет сделать точные выводы, но несомненно, что для SMP систем, вне зависимости от операционной системы и примененной СУБД, тесты TPC-C хорошо отражают производительность реальных OLTP систем. ♦Рекомендации по использованию результатов тестов Для того чтобы иметь возможность использовать любые тесты для выбора необходимого программного и аппаратного обеспечения необходимо тщательно проанализировать те задачи, которые будет выполнять планируемое решение, архитектуру компьютерной инфраструктуры предприятия, бизнес процедуры, планы развития и др. Такой анализ является обязательным в любом проекте, но в данном исследовании мы сфокусируемся на некоторых деталях более важных, если мы хотим сравнивать планируемое решение с существующими тестами. В процессе сбора этой информации необходимо оценить наиболее характерные задачи, стоящие перед сервером - файл сервер, почтовый сервер, веб или ftp сервер или веб приложение, приложение на основе СУБД (OLTP или хранилище данных и т.п.). Собрать информацию о типичной активности пользователей, наиболее часто выполняемыми бизнес операциями и оценить объемы данных, приходящихся на одного пользователя. Составить схему существующей информационной инфраструктуры и возможного ее развития на планируемый срок. Оценить сложность обслуживания. В каком режиме предполагается работа - 7х24 или 5х8? Требование к защите данных и т.п. Сбор такого рода информации является стандартным при разработке любого проекта. Если предполагается рассмотрение тестов для оценки производительности, то полезным было бы прочитать полную спецификацию теста и привести информацию в совместимый со спецификацией вид. Выбор решения. После того, как собрана информация о проекте, можно попробовать использовать тесты для оценки необходимого решения. Здесь следует отметить, что согласно заявлению TPC, результаты тестов TPC не могут быть использованы для sizing’а (подбора необходимого аппаратного и программного обеспечения с заданной производительностью). Это обескураживающие утверждение можно рассматривать в контексте западных лицензионных соотношений. То есть, TPC не может нести ответственности за ошибки связанные с использованием ее тестов т.к. в самих спецификациях TPC отсутствуют стандарты на проведение таких параллелей. Целью настоящего исследования является оценка: насколько это утверждение соответствует истине, и какую информацию все-таки можно получить из тестов TPC? Рассматривая применимость результатов тестов производительности, следует отметить, что результаты TPC тестов соответствуют максимальной производительности. Для реальных систем должен существовать запас производительности в 2-3 раза в пиковые периоды. К сожалению, оценить соотношение между сложностью задач решаемых в тестах TPC и задач, которые будет Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 решаться в рамках реальных проектах, еще никому не удавалось и, в этом отношении, запрет использовать тесты TPC для sizing’а полностью оправдан. Учитывая то, что в тестах TPC участвует высококвалифицированная команда от компаний производителей, имеющая огромный опыт настройки приложений вообще и тесты TPC-C в частности, а кроме того сама тестируемая задача в некоторой степени упрощена (см. раздел «Основные недостатки тестов TPC-C»), следует признать, что получить производительность на конкретных задачах выше чем производительность в тестах TPC-C, практически невозможно. В результате с помощью тестов TPC-C можно сделать только оценку производительности системы сверху (максимальной производительности). Таким образом, основная польза от тестов TPC на этапе выбора программно-аппаратного решения заключается в сравнительном анализе технологий различных производителей. Тесты TPC-C можно использовать для ранжирования систем по производительности и сравнения различных технологий между собой. С помощью тестов можно оценить масштабируемость SMP и кластерных решений, сравнить различные СУБД и OS, оценить перспективы той или иной архитектуры. Стоимостные результаты, полученные в тестах TPC, позволяют оценить стоимость/эффективность тех или иных технологий и развеять некоторые мифы относительно «дорогих» или «дешевых» решений. Эта дополнительная информация может существенно помочь в принятии решения. Как было показано в разделе «Основные достоинства теста TPC-C» рост производительности отстает от увеличения общего числа процессоров в системе. С нашей точки зрения, следует ожидать увеличения производительности на 70-75% при двукратном росте общего числа процессоров, как для кластерной, так и для SMP архитектуры. Кластерные системы, кроме высокой производительности, обеспечивают еще и высокую отказоустойчивость. Однако системы на основе архитектуры «shared nothing» могут потребовать значительных усилий при изменении характера типичных бизнес операций. В тоже время, современные реализации «shared disk» обладают сравнимой масштабируемостью и лучшей отказоустойчивостью. В общем случае, следует четко понимать, что тесты TPC применимы для оценки производительности OLTP задач и хранилищ данных в двухуровневой архитектуре клиент-сервер. Для оценки производительности Web систем и серверов приложений на J2EE следует применять тесты SPEC или соответствующие тесты других разработчиков. Тесты TPC в России Приведенные выше тезисы отражают ситуацию с тестами TPC в мире. Вместе с тем было бы интересно исследовать специфику отношения к TPC в России. ♦Методика исследования Для исследования особенностей России в отношении тестов TPC был выбран метод экспертной оценки. В качестве экспертов были выбраны сотрудники следующих компаний (см. Таблицу 10). Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Таблица 10. Компании, участвовавшие в исследовании. Компания Страна СУБД Серверы Intel RISC AS/400 Mainframe RISC Intel Часть 1 Участие в тестах TPC Да Международная DB2 Informix Др. Международная Нет Международная Нет Intel RISC Да Международная SymfoWARE Intel RISC Да Международная Нет Intel Да Россия Нет Intel Нет Россия Нет Intel Нет Россия Нет Intel Нет Международная SQL Server Нет Да Международная Oracle Нет Да Россия Linter Нет Нет Да (только TPCH) Как видно из таблицы 10, в исследовании были представлены все типы компаний: производители СУБД и серверов на различных платформах, международные и российские, участвующие и не участвующие в тестах TPC. Это позволяет надеяться на всесторонний охват различных точек зрения. В качестве экспертов со стороны компаний выступали технические специалисты, непосредственно участвующие в работе с клиентами в качестве технических консультантов. Им было предложено поставить оценки от 1 до 5 (не согласен – согласен) для следующих утверждений (см. Таблицу 11). Согласно условиям экспертного опроса численные значения данные конкретными экспертами не публикуются. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. № 1 2 3 4 5 6 Таблица 11. Тесты TPC – оценка экспертов. TPC Оценка производительности системы Sizing (возможность использования для составления спецификации) Технические достижения производителя TPC менее значимо чем тесты приложений Осведомленность заказчиков о тестах Производительность в тестах не отражает надежность Часть 1 Оценка Больше - лучше Больше - лучше Больше - лучше Меньше - лучше Больше - лучше Меньше - лучше Соответствующие результаты и их анализ приведены в следующих разделах. ♦Результаты На рисунке 1 и в таблице 12 приведены результаты экспертной оценки. В связи с большим разбросом мнений экспертов была проведена статистическая обработка результатов и рассчитаны доверительные интервалы для α = 0.05 (95% вероятность). Таблица 12. Средние значения и доверительный Среднее № Критерий значение 1 Оценка производитель3,7 ности системы 2 Sizing (возможность ис2,5 пользования для составления спецификации) 3 Технические достижения 4,4 производителя 4 Тесты приложений зна4,8 чимее 5 Осведомленность заказ2,7 чиков о тестах 6 Производительность в 4,4 тестах не отражает надежность интервал ± 0,8 0,4 0,6 0,6 0,7 0,6 Рисунок 1. Средние значения и доверительный интервал 6 Значение 5 4 3 2 1 0 1 2 3 4 5 6 Критерий ♦Анализ оценок При планировании опроса ожидалось, что на оценки экспертов может повлиять участие или неучастие компании в тестах TPC и ее успехи в этих тестах. Ожидалось, что российские компании Kraftway, Aquarius, Forward и Relex, не имеющие результатов тестов TPC, будут значимо Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 отличаться от западных компаний представленных в таблице результатов TPC. Однако, анализ данных показал отсутствие ярко выраженных групп в экспертных оценках, что говорит о том, что ориентация на тщательно отобранных технических специалистов позволяет получить более независимые и значимые оценки. Кроме того, относительно небольшая статистическая погрешность оценок позволяет использовать средние значения, для обобщенной оценки. Отдельные группы в соответствии с позиционированием компаний на рынке и их результатов в тестах TPC удалось выявить только по отношению к отдельным критериям. Рассмотрим результаты экспертных оценок по критериям и попробуем оценить мотивацию экспертов при выставлении этих оценок. Оценка производительности системы Средняя оценка по этому критерию составила 3.7±0.8, что соответствует самому большому разбросу мнений. Очевидно, что производители СУБД поставили в среднем более высокие оценки, чем производители серверов. Это не означает, что оценки производителей ПО завышены по маркетинговым соображениям – тесты TPC являются основными для них и отражают достижения одного из их основных продуктов. Очень низкая оценка Sun, скорее всего, связана с позицией компании не участвовать в тестах TPC-C. Кроме того, Sun активно участвует в других тестах (SPEC, специализированных тестах, тестах серверов приложений и т.п.). В целом, округленная оценка (4) отражает позитивное отношение большинства компаний к тестам TPC. Sizing (возможность использования для составления спецификации) Средняя оценка 2.5±0.4. Самый маленький разброс результатов и низкая оценка возможности использовать результаты тестов TPC для выбора конкретной модели компьютера и ПО для реальных приложений, позволяет однозначно сделать утверждение, что тесты TPC невозможно использовать для этой цели. Технические достижения производителя Средняя оценка 4.4±0.6. В целом единодушное признание тестов TPC, как Формулы-1 компьютерного мира. Оценка ниже средней сделанная экспертом из Sun, связана с общей постановкой вопроса, т.к. Sun отдает должное качеству и значимости тестов TPC-H, но считает TPC-C полностью неадекватным реалиям сегодняшнего дня. Не очень понятна низкая оценка эксперта из Oracle, компании имеющей очень неплохие результаты, хоть и уступающие результатам конкурентов. Особенно непонятно это в связи с высокой оценкой по первому критерию. Дело в том, что первый и третий критерии специально сделаны пересекающимися, чтобы оценить валидность оценок. В целом результаты оценок по этим критериям хорошо коррелируют, за исключением оценок Oracle. Однако, учитывая, что тесты кластерной архитектуры Oracle9RAC, где у Oracle есть реальная возможность снова выйти на лидирующие позиции, только начинаются, следует посмотреть на поведение компании после изменения таблицы рекордов в ее пользу. Если оно изменится, то отклонение вызвано скорее маркетинговыми причинами. TPC менее значимо чем специализированные тесты Средняя оценка 4.8±0.6. Самый высокий бал в ответах и небольшой разброс говорят о смещении фокуса тестирования производителей ближе к нуждам заказчиков. Компании практически единодушны. Резкое выпадение Microsoft, поставившего маленькую оценку, скорее всего связано с тем, что в отличии от Oracle, предлагающего Oracle Applications, и производителей серверов, имеющих возможности тестировать приложения на своем оборудовании, Microsoft была недостаточна мотивирована в таких тестах. Вполне вероятно, что в связи с приобретением компании Navision и общим движением в сторону приложений, Microsoft начнет менять свое мнение. Также отличается в меньшую сторону от средней оценка HP, что, возможно, связано с тем, что в области тестов приложений у HP нет такого отрыва от конкурентов, как в тестах TPC. Осведомленность заказчиков о тестах Средняя оценка 2.7±0.7. Еще одно почти единодушное решение экспертов. Следует признать, что российские заказчики крайне мало осведомлены о тестировании систем на западе, что открывает определенные перспективы перед производителями. Поставившая более высокие оценки и выпадающая из общей картины группа компаний – Hewlett Packard, Fujitsu Siemens Computers и Oracle, скорее всего, просто много сделали для образования своих заказчиков, чем отли- Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 чаются по своим заказчикам от других компаний. Общая оценка – неудовлетворительная информированность. Производительность в тестах не отражает надежность Средняя оценка 4.4±0.6. Здесь наблюдается четкое расслоение на две группы. Первая – производители серверов, считающие, что надежность не связана с производительностью в тестах TPC, вторая – производители СУБД, не согласные с этим утверждением. Мотивация такого подхода производителей СУБД не очень понятна. Однако средняя оценка экспертов (4.4) небольшой доверительный интервал находятся в хорошем соответствии со спецификациями и документами TPC, утверждающих, что тесты TPC оценивают только производительность системы и никоим образом не характеризуют ее надежность. Комментарии экспертов Кроме выставления экспертных оценок, представители компаний сделали комментарии в свободной форме, уточняющие позицию их компаний и отношение к тестам в России. Эти комментарии приведены в данном разделе с некоторыми сокращениями. Dell Компания Dell серьезно относится к независимым тестам производительности серверов, в том числе к тестам TPC, считая их в достаточной степени показательными. Особо важное значение эти тесты приобретают в свете сравнения решений на платформе Intel с RISC-серверами. Тесты демонстрируют сравнимую производительность этих систем, однако при этом продукты на базе стандартной архитектуры Intel очевидно выигрывают по соотношению цена / производительность. Кроме того, выбирая сервер, построенный с использованием промышленно стандартных технологий Intel, заказчик получает полностью стандартизованное решение, что обеспечивает дополнительное преимущество в совместимости, управляемости и возможности расширения. Развитие технологий на данном этапе позволяет гарантировать достаточно высокий уровень производительности серверов для решения большинства задач, встающих перед заказчиками. В данной ситуации успех вендора зависит от обеспечения дополнительных преимуществ, наиболее важными из которых являются приспособленность продукта для решения конкретных задач и конкурентоспособная цена. Решения Dell традиционно занимают высокие места в рейтингах, основанных на соотношении цена / производительность. Компания придает большее значение сравнению именно по этому критерию, так как считает его более показательным и интересным для пользователя. В определенном смысле, компьютеры, которые Dell представляет на тестирование, являются наиболее сбалансированными и востребованными на рынке серверов моделями. Практическое использование результатов тестов при работе с российскими заказчиками зачастую бывает затруднительным в силу низкой осведомленности IT-специалистов о деятельности ТРС. Далеко не все российские заказчики знакомы с результатами последних тестов ТРС. Для тех же, кто интересуется подобными данными, результаты тестов представляют лишь общую рекомендацию. Выбор конкретного решения, разумеется, бывает основан на большем числе факторов. Основополагающим при выборе серверной платформы является приспособленность системы для решения конкретных задач заказчика. В связи с этим для заказчиков важна возможность протестировать сервер в собственной инфраструктуре. Dell обеспечивает своим заказчикам такую возможность. Forward С нашей точки зрения, TPC тесты позволяют оценить исключительно общие технические достижения производителя, но имеют мало отношения к выбору конкретной спецификации для заказчика. Для заказчика гораздо важнее специализированные тесты производительности установленных у него систем, чем тесты TPC. Именно поэтому так популярны тестирования специализированного софта, программы типа ”try & buy” и тестирование «живьем». Кроме того, TPC тесты применимы только для серверных систем. Имея большую статистику продаж, можно отметить, что том секторе, где мы работаем, очень мало заказчиков обращают внимание на тесты ТРС, все судят о производительности системы по косвенным признакам – количество процессоров и производительность процессоров. Тех наших заказчиков, которые хорошо знакомы с тестами TPC и понимают их назначение и условия проведения можно заносить в «красную книгу» Кроме того, TPC тесты учитывают только максимальную производительность системы и ничего не говорят о надежности системы в реальных условиях эксплуатации, а надёжность в системах среднего и высокого уровня приоритет №1. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 Fujitsu Siemens Computers Вопрос о технологическом лидерстве по результатам тестов TPC, с нашей точки зрения, вообще ставить неуместно. Разброс результатов целого ряда моделей компьютеров не превышает 1% (а так чаще всего и бывает у серверов с процессорами Intel). Один вендор публикует рекордный результат, спустя месяц другой (тоже рекорд, с ничтожной разницей результатов), потом третий, и так далее. Повторных рекордов не ставит почти никто (слишком дорогие тесты, наверное). У всех рекорды, все счастливы. Другое дело, если какая-либо комбинация процессор – чипсет - тип памяти встречается не у всех (например, PRIMERGY F200, рекорд в тесте TPC-C на процессорах Pentium III видимо, так и не будет побит), вот здесь результаты могут ощутимо различаться. И, конечно, системы на процессорах RISC, поле, где вендоры могут отличиться фирменными технологиями и показать значительный отрыв от конкурентов. Компания Fujitsu Siemens Computers имеет прекрасные результаты в тестах TPC, но мы предпочитаем применять специализированные тесты (например, тесты SAP R/3). Считаем, что они лучше соотносятся с реальностью. В тоже время для России весьма характерно крайне скептическое отношение к тестам TPC – сравнивая его с физиком из известного анекдота про «модель абсолютно упругого шарообразного коня в вакууме» для оценок шансов выигрыша в скачках. С нашей точки зрения, заказчики очень мало используют тесты TPC в своей оценке предлагаемых решений. HP С точки зрения нашей компании, ТРС тесты действительно один из лучших показателей, так как тестируют всю компоненты системы в целом (в отличие от spec int и spec fp). Они являются неким общим знаменателем для сравнения различных систем и систем различных производителей. Не участие компании в тестах или отсутствие данного теста может скрывать некие “недостатки” и недоработки предлагаемых производителями систем. Следует особо отметить, что TPC-тесты говорят о максимально возможной производительности, в случае если с системой работают технически грамотные люди. IBM IBM традиционно участвует в TPC тестах. Системы IBM, работающие под управлением разных операционных систем, являются лидерами TPC тестов. Для IBM участие в TPC-тестах является своего рода проверкой и дополнительным доказательством сбалансированной работы всех составляющих серверных систем. Одновременно с этим, результаты тестов являются дополнительным фактором, который помогает нашим клиентам принять решение об использовании технологий IBM. Особенно хотелось бы отметить, что тесты TPC разнообразны и их результаты обновляются достаточно часто, поэтому мы рекомендуем следить за результатами тестирования непосредственно на сайте TCP, чтобы быть в курсе последних достижений и отслеживать тенденции на рынке технологий. Наши заказчики в России обращают внимание данные тестов TPC как на одно из средств сравнения систем. Нужно отметить, что TPC тесты являются одним из компонентов при принятии решений о покупке серверных систем. Kraftway Наша компания не участвует в тестах ТРС. Участие было бы возможно, если бы стоило хотя бы на порядок дешевле. Как правило, наши заказчики практически не знают о том, что такое тесты ТРС, и руководствуются при выборе решения собственными представлениями о критериях оценки производительности системы. Microsoft ПО корпорации Microsoft регулярно проходит тестирование по тестам TPC - и весьма успешно. Мы хотим отметить, что кластерные системы на базе ПО Microsoft регулярно занимают первые места по производительности в тесте TPC-C. Кроме того, наши продукты уже очень длительное время занимают все первые 10 позиций по соотношению цена/производительность в тесте TPC-C. Соотношение цена/качество всегда было сильной стороной ПО Microsoft, и тесты TPC еще раз подтверждают это. Мы информируем о результатах тестов TPC наших заказчиков на мероприятиях и ссылаемся на них в наших документах. На наш взгляд, заказчики прислушиваются к этой информации и используют ее при принятии решений о выборе платформы. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 Oracle Тесты TPC мы, безусловно, используем, и очень часто. В основном мы рекомендуем заказчикам воспользоваться результатами TPC-тестов, чтобы они могли примерно оценить параметры вычислительного комплекса (число процессоров и их производительность, размер базы данных и т.д.), которые позволяют достигнуть желаемой производительности (число транзакций в минуту). Кроме того, мы используем данные тестов на сверхбольших базах данных, чтобы показать, что Oracle показывает отличную производительность на базах данных объемов от 100 Гигабайт до 3 Тбайт. Relex Мы используем эти тесты для оценки сравнительной производительности. Естественно, реализации тестов мы используем свои, и результаты достаточно трудно сравнивать с западными результатами. Мы можем сравнивать только с нашими же тестами, но на других СУБД. Кроме этого у нас отсутствует то оборудование, на котором выполняется тестирование иностранных СУБД по причине его дороговизны и, скорее, даже эксклюзивности. Наших заказчиков очень мало беспокоят результаты этих тестов. Их больше беспокоит надежность системы и способность выполнять их требования на их оборудовании. Если рассматривать сферу применимости тестов у нас, то это, во-первых, сравнительное тестирование определенной конфигурации программно-аппаратных комплексов на соответствующем классе задач. И оптимизация этой конфигурации. Во-вторых, это средство (достаточно удобное) оптимизации вендором компонентов СУБД с целью добиться максимальных результатов теста. При этом зачастую действительно находятся интересные решения, влияющие не только на результаты конкретного теста, но и производительность системы в целом. Sun С точки зрения компании Sun тесты TPC не являются одинаково значимыми. На наш взгляд тесты TPC-C безнадежно устарели, и многие производители нашли способ, как получать рекордные показатели в этих тестах с помощью методов, которые никогда не будут востребованы в реальной жизни. Особенно это касается кластерных результатов TPC-C. Здесь можно привести компании по перевозкам, которая на основе большого количества параметров, таких как стоимость перевозки одного килограмма на километр, суммарная производительность по перевозкам грузов, общая стоимость владения и т.п. выбрала для перевозок малолитражные автомобили. Первый заказ, который она получила, был на перевозку рояля! Похоже, что тесты TPC-C зашли в тупик, методика рекордной производительности, не имеющая ничего общего с реальными задачами, найдена, и теперь просто невыгодно ставить новые рекорды, т.к. они тут же будут перекрыты. При этом компании просто втянутся в новую чрезвычайно дорогую гонку с неясным финалом. С другой стороны, тесты TPC-H вполне адекватно описывают реальную ситуацию в области хранилищ данных и систем поддержки принятия решений. Кроме того, мы четко следуем правилам совета TPC о том, что НЕЛЬЗЯ использовать тесты TPC для sizing’а. Поэтому мы относимся к ним, как некоторой выставке достижений технологий, которая имеет ограниченное применение. Мы считаем, что те тесты, которые реально нужны заказчикам, должны быть ближе к реальности, а не лаборатории. Не говоря уж об оптимизации, когда есть большая разница между тем, что могут сделать лучшие специалисты в лаборатории вендора и тем, чего можно добиться в реальной жизни. Отношение к тестам TPC в России неоднозначное. У многих заказчиков еще сохраняется желание привести все к общему знаменателю, и им ничего не остается, кроме TPC тестов. Многим незнаком состав и смысл TPC тестов, многие не знакомы с позицией TPC по поводу неприменимости для sizing’а, многие обобщают "транзакции в минуту", не делая различий между разными приложениями и тестами. При этом не все понимают, что TPC тесты учитывают только максимальную производительность системы и ничего не говорят о надежности системы в реальных условиях эксплуатации. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 Выводы Анализ собранной информации, позволяет сделать следующие выводы: Для заказчиков: 1. Тесты TPC являются лучшей на сегодня оценкой производительности систем клиент – сервер сверху (максимальной производительности в идеальных условиях). 2. К сожалению, использовать эти тесты для выбора конкретного решения для решения бизнес задач заказчика, не представляется возможным. 3. Тесты TPC могут быть успешно использованы для анализа предлагаемых производителями технологий и решений и сравнения их между собой, сравнения различных архитектур и продуктов. Зачастую эти тесты - единственная достоверная информация такого рода. 4. Очень важной частью тестов TPC является оценка соотношения стоимость/производительность. 5. Вопросы администрирования и надежности систем не рассматриваются в этих тестах. 6. Для других задач и архитектур помимо двухуровневой клиент-серверной, существуют менее раскрученные, но не менее достоверные интегральные универсальные тесты SPEC. 7. Для решения задач выбора оптимального программно-аппаратного обеспечения для проекта более оптимальными являются интегральные тесты приложений. Для производителей: 1. Тесты TPC несут значительную, полезную для заказчиков информацию. Но они, зачастую, не знают как ей воспользоваться. 2. Уровень знаний заказчиков об интегральных универсальных тестах незаслуженно низок. Следует больше уделять внимания пропаганде и обучению своих заказчиков и партнеров. 3. Тесты TPC являются наиболее известными из интегральных универсальных тестов. При этом осведомленность заказчиков о них очень мала. Из этого можно сделать вывод, что имеющие большое будущее и очень важные для заказчика тесты приложений еще менее известны. Необходимо заранее сфокусироваться на пропаганде специализированных тестов, имеющих большое будущее. 4. Для российских производителей участие в тестах TPC экономически нецелесообразно. Реально, российские производители смогут участвовать лишь в соревновании по критерию стоимость/производительность, но стоимость таких тестов слишком велика. 5. Оптимальным, для российских производителей, будет участие в более дешевых, менее известных, но не менее качественных интегральных универсальных тестах SPEC. Это позволит им сравнить свои результаты с результатами международных вендоров при относительно меньших затратах. 6. Ориентация на тесты SPEC позволит российским компаниям совершить прыжок и сразу вкладывать ресурсы в тестирование более современных архитектур, чем двухуровневые, и более современных задач, чем клиент – сервер. Это можно реализовать на основе участия в некоммерческой структуре SPEC, создании подобной организации в России или использовании существующих российских структур. 7. Другим решением для использования российскими компаниями интегральных тестов может быть использование тестов российских приложений типа 1С, Галактика, Парус и т.п. (Договоренности о тестировании с западными разработчиками типа SAP, Oracle и др. могут оказаться весьма проблематичными). Это тем более привлекательно, так как в ближайшем будущем специализированные тесты будут приобретать все большее значение. 8. Международным компаниям также следует внимательно рассмотреть участие в специализированных тестах российских производителей приложений. Специальная лицензия для факультета информационных технологий НГУ Оценка производительности программно-аппаратных решений. Часть 1 Адреса использованных в исследовании ресурсов. TPC SPEC Empirix Mindcraft NetBench ECPerf Dkftpbench www.tpc.org www.spec.org www.empirix.com www.mindcraft.com www.veritest.com www2.theserverside.com/ecperf/index.jsp www.kegel.com/dkftpbench/ Copyright и торговые марки Авторские права на данное исследование принадлежат компании Elashkin Research. Все упоминаемые изделия и названия компаний могут быть торговыми марками или зарегистрированными торговыми марками соответствующих владельцев. Специальная лицензия для факультета информационных технологий НГУ
