Введение   

Содержание:

0.1 Введение
0.2 Основное руководство по применению
0.3 Общие рекомендации по измерениям

---

0.1 Введение

TPC Benchmark™ C (TPC-C) – это один из тестов OLTP (Он-лайн Обработки Транзакций). Он сочетает в себе запросы на чтение и интенсивное обновление, которые моделируют действия, обнаруженные в сложной прикладной OLTP программе. Это достигается путем тестирования мощности компонентов системы, связанных с данной программой, которая характеризуется:

Система показателей производительности, полученная по результатам TPC-C теста, выражает "производительность бизнеса", которая измеряется числом заказов в минуту. Многочисленные транзакции используются для моделирования активности обработки заказа, и на выполнение каждой транзакциитребуется определенное время. Система показателей производительности для контрольного теста выражается числом транзакций в минуту-С (т/мин – С). Для соответствия TPC-C стандарту все результаты TPC-C теста должны включать в себя число транзакций в минуту (т/мин-С), соответствующую стоимость транзакции в минуту, и дату появления в наличии конфигурации установленной стоимости.

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

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

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

Результаты контрольных измерений сильно зависят от нагрузки, особых требований к программе, дизайна систем и разработки. Относительная производительность системы будет варьироваться в зависимости от этих и других факторов. Таким образом, ТРС-С тест не должен использоваться в качестве замены особого пользовательского программного тестирования, когда предусмотрены критическая пропускная способность и/или стоимость программы.

Поскольку заказчики данного контрольного тестирования придерживаются концепции, описанной и проиллюстрированной в главе 6, им предоставляется на выбор несколько возможных вариантов системы. Согласно Главе 8, вместе с заявленными результатами тестирования должен быть предоставлен Полный Отчет с описанием деталей разработки.

Комментарий: Комментарии, отделенные для удобства чтения от главного текста, являются частью стандарта и обязательны. Однако образец программы, прикрепленный в Приложении А, сводный отчет (Приложение В), справка о численныхпоказателях (Приложение С), являются всего лишь примерами, а не частью данного стандарта.

0.2 Основное руководство по применению

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

• Как правило, доступны пользователям.

• Соответствуют сегменту рынка, который представляется и моделируется определенным ТРС тестом (например, ТРС-А моделирует и представляет крупномасштабные, простые OLPT условия).

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

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

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

Следующие характеристики должны использоваться при определении - является ли конкретная реализация упрощенным тестом.

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

• Имеет ли данная разработка значительные ограничения на ее использование или она имеет ограниченную применимость вне контрольного ТРС измерения?

• Насколько разработка, или ее часть, интегрирована в большую программу?

• Имеет ли реализация особое преимущество над природой ТРС теста (например, параметры транзакции, набор транзакции, взаимосовместимость и/или конфликт транзакций, локализация транзакции) в том виде, который не может быть применим к условиям, представляющие контрольные измерения.

• Поощряется ли данная разработка компанией-производителем? (Это включает в себя сбой при переносе разработки в виде, схожем с другими программами и технологиями).

• Требует ли разработка особого усовершенствования со стороны конечного пользователя, программиста или системного администратора?

• Является ли стоимость необычной или нетипичной для компании-производителя, или необычной и нетипичной для нормальной деловой практики? Для дополнительной информации обратите внимание на текущие особенности ТРС тарификации.

• Используется ли реализация (включая бета-версии) или приобретается конечными пользователями на том сегменте рынка, на который ориентирован контрольный тест? Как часто? С разных ли сторон? Если на данный момент реализация не используется конечными, то будет ли она будетприменятся в будущем?

0.3 Общие рекомендации по измерениям

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

• Приближения являются общепринятой инженерной практикой или стандартом.

• Они не улучшают результат.

• Используемое при измерениях оборудование откалибровано в соответствии с установленными стандартами качества.

• Правильность и точность поддерживается при учете всех необычных результатов, даже если они не указаны в требованиях к тестированию.

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