Глава 6 - Правила и оценки исполнения   

Содержание:

6.1.Введение
6.2.Архитектуры реализации драйвера
6.3.Сочетание Транзакций
6.4 Параметры Транзакций
6.5 Время отклика и задержки шага.
6.6 Выполнение тестов
6.7 Необходимая отчетность




6.1 Введение


Этот пункт определяет правила выполнения и методы для вычисления показателя эталонного теста.
6.1.1 Определение терминов

6.1.1.1 Понятием Отчетный обозначаются элементы, являющиеся частью FDR. (см. Пункт 9 для более подробной информации о требованиях).

6.1.1.2 Понятие Действительная транзакция относится к любой Транзакции, входные данные для которой были полностью отправлены драйвером, обработка которой была успешно выполнена в SUT, и корректные выходные данные которой были полностью получены Драйвером
Примечание 1: Транзакционные ошибки недопустимы во время выполнения теста. Транзакцию, которая никогда не завершается, считают ошибкой.
Примечание 2: Транзакция Trade-Order, которая требует отката, и которая выполняется успешно и производит правильный вывод, считают Действительной Транзакцией.
Примечание 3: Транзакция, которая прервалась и повторена SUT, и в конечном счете завершается успешно и производит правильный вывод, не считается ошибкой. Транзакция не может быть повторена Драйвером.

6.2 Архитектуры Реализации Драйвера

Хотя использование кода EGenDriver является обязательным при реализации соответствующего спецификации Драйвера (см. пункт 0), по-прежнему существует достаточная степень гибкости в рамках общей архитектуры драйверов. Изменения в архитектуре, которые следуют из этой гибкости, оказывают влияние на понимание и интерпретацию правил выполнения эталонного теста. Поэтому, эта секция обеспечивает краткий обзор ключевых архитектурных вариаций. Эти модели являются лишь примерами и не представляют собой исчерпывающий список. Для простоты, внимание будет уделяться СЕ, но те же принципы применяются к MEE.

6.2.1 Простой CE
В его самой простой форме CE имеет:

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


                                     Рисунок 6.a - Простой CE

6.2.2 Реплицированный CE

Есть пределы производительности, которую может обеспечивать Простой CE, а потому разрешена репликация Простого CE. Это позволяет множеству копий Простого CE генерировать необходимую Номинальную Производительность для любого размера базы данных. Поскольку будут существовать несколько экземпляров класса CCE, они будут эквивалентны EGenDriverCE размера N (где N - число экземпляров CCE).
Факт принудительного использования auto-RNG сидирования EGenDriverCE (см. пункт 5.8.2) означает, что они не будут абсолютно идентичными копиями Простого CE. Каждая копия начнется в различной точке потока RNG. Следующая диаграмма показывает Реплицированный CE.


                               Рисунок 6.b - Реплицированный CE


6.2.3 Асинхронный CE

В среду организатора CE может быть внесена дополнительная гибкость путем ввода асинхронизации. Есть два места, где это может быть сделано.
Между кодом CESUTInterface и кодом EGenDriver Connector
Между кодом EGenDriver Connector и кодом EGenTxnHarness Connector
Следующие разделы описывают эти сценарии более подробно.

6.2.3.1 Асинхронный Транзакционный Генератор

Асинхронность между кодом CESUTInterface и кодом EGenDriver Connector достигается при использовании некоторой формы очереди. Это позволяет одному потоку исполнения действовать как транзакционный генератор для одного или более потоков Драйвера выполнения. При такой организации поток генератора Транзакций использует код EGenDriverCE, чтобы генерировать Транзакции связанные с ними входные данные. Эта информация помещается в очередь. Тогда один или более потоков Драйвера выполнения может убрать из очереди предварительно сгенерированные Транзакции и послать их в SUT для обработки. Следующая диаграмма отображает Асинхронный Генератор Транзакций


                                          Рисунок 6.c – Асинхронный Генератор Транзакций


При использовании Асинхронной архитектуры Генератора Транзакций для Вызванных Клиентом и Вызванных Брокером транзакций необходимо придерживаться следующих ограничений.
  •  У каждого генератора должна быть уникальная очередь, и должна быть одна и только одна очередь на генератор.
  •  Очередь каждого генератора должна быть в порядке FIFO.
  •  Потоки выполнения EGenDriver Connector должны всегда убираться из одной и той же очереди.
Примечание: Хотя это и не является обязательным, Асинхронную архитектуру Генератора Транзакций принято использовать в сочетании с классом CMEE для реализации Эмулятора фондовой биржи. Необходимо отметить, что пункт 4.4.1.4 накладывает ограничения на реализацию. Например, в то время как нет никаких ограничений на число очередей, которое может иметь генератор MEE, пункт 4.4.1.4 устанавливает требование, чтобы очереди были в порядке FIFO, и запрещает им быть основанным транзакционным типом (это считалось бы неявной маршрутизацией).

6.2.3.2 Неблокирующие потоки исполнения Драйвера
Существует обязательное Сетевое подключение между кодом EGenDriver Connector и кодом EGenTxnHarness Connector (см. пункт 4.1.3.8). Организатор может выбрать, использовать ли блокирующие или неблокирующие Сетевые подключения. Использование неблокирующих Сетевых подключений вводит асинхронность между Драйвером и SUT. Это позволяет потоку исполнения Драйвера передавать в SUT новую Транзакцию до завершения других Транзакций, ранее переданных тем же самым потоком. Завершение Транзакций может быть обработано инициирующим потоком или совершенно иным потоком. Следующая диаграмма отображает неблокирующий Драйвер.


                                    Рисунок 6.d – Неблокирующие потоки исполнения Драйвера

6.2.4 Комбинации
Возможны комбинации некоторых или всех вышеописанных вариантов архитектуры. Например, Асинхронный Генератор Транзакций может использоваться в сочетании с неблокирующими потоками исполнения Драйвера. Затем эта архитектура могла быть многократно реплицирована.

6.2.5 Требования к отчетам Драйвера
В Отчете должно быть указано число экземпляров классов EGenDriverMEE и EGenDriverCE, используемых в контрольном тестировании.

6.3 Сочетание Транзакций

Рабочая нагрузка TPC-E составляется из группы Транзакций, работающих с базой данных, следуя заданному Сочетанию Транзакций. Во время Выполнения Теста, код CCE управляет созданием Брокерских и Клиентских типов Транзакций через методику колоды карт, созданную, чтобы соблюсти заданное пропорциональное сочетание Транзакций (см. CETxnMixGenerator.cpp). Вызванные Рынком Транзакции не генерируются CE, но являются результатом асинхронных акций в MEE.

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

6.3.1 Требования к сочетанию
Следующая таблица показывает целевой процент сочетаний. Организатор теста должен показать, что фактический процент, полученный для каждой Транзакции за весь Интервал Измерения, находится в пределах заданного Необходимого Диапазона.


Примечание: на каждую непрерваную Транзакцию Trade-Order приходится одна завершенная Транзакция Trade-Result. Однако, ожидающие заявки по уровню откладываются до тех пор, пока не будет достигнута их цена срабатывания. Соответственно, процентное сочетание на коротких промежутках времени может варьироваться. Аналогично, число Транзакций Market-Feed управляется кодом CMEE таким образом, чтобы оно было равно одной на десять сгенерированных Транзакций Trade-Result generated. Следовательно, частоты сочетаний могут варьироваться на коротких промежутках времени. Однако в основном они будут стремиться близко следовать отношению процентного сочетания Транзакций Trade-Result, равному 1/10.

6.3.2 Необходимая точность для Сообщения Процентного сочетания.
О процентах транзакционных сочетаний нужно сообщить с той же точностью, как показано в Необходимом Диапазоне в таблице в пункте 6.3.1.
Вычисление частот сочетания, фактически полученных во время Интервала Измерения, должно быть сделано по крайней мере с четырьмя знаками после запятой и при составлении отчета должно быть округлено до трех ближайших знаков. Например, 7.2344 должен быть сообщен как 7.234 и 7.2345 должен быть сообщен как 7.235.

6.3.3 Data-Maintenance
Каждые шестьдесят секунд должна быть вызвана единственная Транзакция Обслуживания данных. Фактический интервал между выполнением двух последовательных Транзакций должен составить не менее 58 секунд и не более 62 секунд. Каждая Транзакция Data-Maintenance должна успешно завершиться через 55 секунд или меньше.

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

6.4 Параметры Транзакций

Каждый тип Транзакций имеет переменные входные данные. Некоторые из Транзакций имеют заданные процентные соотношения (см. DriverParamSettings.h) возможных значений этих входных величин. Во время Выполнения теста, код EGenDriver управляет генерацией значений для этих входных величин, используя генератор случайных чисел, предназначенный для соблюдения заданного отношения (см. CETxnInputGenerator.cpp). Однако, ввиду того, что допустимы отклонения от заданного процентного соотношения, в обязанности Организатора теста входит обеспечение гарантий, что следующие характеристики Интервала измерения были действительно соблюдены, для того чтобы Интервал измерения был корректен. Для того, чтобы проверить, что эти критерии выполнены, должны быть подсчитаны входные данных для всех Транзакций, значения sTn и eTn которых находятся в Интервале измерения.

6.4.1 Требования к сочетанию входных значений.
Следующая таблица показывает целевые процентные соотношения значений. Организатор теста должен показать, что фактическое процентное соотношение, достигнутое по каждому типу входных данных на Интервален измерения, находится в пределах Необходимого диапазона.



(*) Примечание: Соотношение количества прерванных торгов к завершенным торгам равно 1/100 или 1%, и таким образом соотношение прерванных торгов ко всем торгам равно 1/101 или ~1%. Фактическое процентное соотношение ближе к 0.99%, и по этой причине диапазон допустимых значений лежит в промежутке от 0.94% до 1.04% (а не от 0.95% до 1.05%), посколько центром диапазона является матиматическое ожидание, равное 0.99%.

6.4.2 Разделение Клиентов

Одновременно может исполняться более одного экземпляра CE. Экземпляры CE могут быть разделены по C_ID (идентификатор клиента).

6.4.2.1 Требования к конфигурации

  •  поддиапазон C_ID для заданного экземпляра EGenDriverCE должен быть непрерывным набором идентификаторов C_ID.
  •  минимальным значением C_ID в поддиапазоне должно быть начальное значение C_ID в Единице обработки.
  •  минимальный размер поддиапазона идентификаторов C_ID равен 5,000.
  •  Размер поддиапазона идентификаторов C_ID должен быть производной величиной от размера Единицы обработке.
  •  Размер поддиапазона идентификаторов C_IDs не обязан быть одинаков для каждого экземпляра CE.
Помимо этого, в случае использования разделения C_ID, код EGenDriverCE обеспечит контроль того, что:
  •  значения C_ID выбираются из всего диапазона Сконфигурированных клиентов в 50% случаев.
  •  значения C_ID выбираются из предоставленного разделенного поддиапазона клиентов в 50% случаев.
Примечание: возьмем в качестве примера некую гипотетическую базу данных, содержащую 60,000 Сконфигурированных Клиентов, с четырьмя (4) экземплярами CE. Первые два экземпляра будут использовать 20,000 клиентов,а остальные два экземпляра будут использовать 10,000.
  •  Экземпляр 1 будет настроен на использование iMyStartingCustomerId со значением 1, iMyCustomerCount со значением 20,000 и iPartitionPercent, равным 50%.
  •  Экземпляр 2 будет настроен на использование iMyStartingCustomerId со значением 20,001, iMyCustomerCount со значением 20,000 и iPartitionPercent, равным 50%.
  •  Экземпляр 3 будет настроен на использование iMyStartingCustomerId со значением 40,001, iMyCustomerCount со значением 10,000 и iPartitionPercent, равным 50%.
  •  Экземпляр 4 будет настроен на использование iMyStartingCustomerId со значением 50,001, iMyCustomerCount со значением 10,000 и iPartitionPercent, равным 50%.
6.4.2.2 Тест корректности выполнения.

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

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

После Выполнения теста, когда было определено расположение и продолжительность Интервала измерения, необходимо обработать записанные значения sTn СЕ и выполнить следующие расчеты для всех непересекающихся 30-секундных интервалов «t», полностью располагающихся в пределах Интервала измерения:

1. Для всех экземпляров CE в каждом Диапазоне раздела «r» в пределах каждого 30-секундного интервала времени «t» подсчитайте количество начатых CE Транзакций (тех, которым назначено sTn). Дайте этой величине название Cr,t.
2. Разделите Cr,t на количество Единиц обработки в Диапазоне раздела «r». Назовите эту нормализованную величину Nr,t.
3. Подсчитайте «среднюю оценку управления CE на каждую Единицу обработки во все базе данных» At, суммируя все Cr,t и разделяя на общее количество Единиц обработки в базе данных.
4. Подсчитайте количество величин Nr,t, которые не удолветворяют неравенству At * 0.95 <= Nr,t <= At * 1.05. Назовите эту величину Dt.
5. Назовите общее число Диапазонов разделов R. Если Dt / R > 0.05, то считается, что на временном интервале «t» тест был провален, и значение Ft устанавливается равным 1; в противном случае Ft устанавливается равным 0.

Суммируйте значения Ft по всем величинам «t». Назовите эту величину S.
Назовите число 30-секундных временных интервалов в Интервале измерения как T.
Интервал измерения должен соответствовать следующим требованиям:
  •  S / T <= 0.05.

6.5 Время отклика и задержки шага.

6.5.1 Время отклика

6.5.1.1 Время отклика (RT) определяется по формуле:
                 RTn = eTn - sTn,
                                    где:
                                           sTn и T n измеряются в Драйвере;
                                           sTn = время, измеренное перед тем, как первый байт входных данных Транзакции отправлен Драйвером в SUT;
                                           eTn = время, измеренное после того, как первый байт выходных данных Транзакции получен Драйвером в SUT;

Примечание: промежуток между отметками времени, используемыми для измерения Времени отклика, должно быть не меньше 0.01 секунды.

6.5.1.2 Во время Интервала измерения не менее 90% Транзакций каждого типа должны иметь Время отклика меньше или равное ограничений, указанных в нижеследующей таблице.



6.5.1.3 Следующая диаграмма отображает, где измеряются Времена откликак для каждого типа Транзакций. Отметки времени осуществляются Драйвером.

                                                        Рисунок 6.e – Измерение Времени отклика.

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

6.5.1.5 Транзакция Data-Maintenance не имеет требований среднего и 90-процентильного значений. Вместо этого каждая Транзакция Data-Maintenance должна успешно завершиться за 55 секунд или менее.

6.5.1.6 Для Транзакции Trade-Cleanup также не устанавливается никаких требований ко Времени отклика. Она должна успешно завершиться прежде, чем может начаться Выполнение теста и, соответственно, прежде, чем может быть исполнена любая Транзакция.

6.5.2 Время отсылки и задержка шага

6.5.2.1 Каждый поток исполнения EGenDriverCE, вызывающий интерфейс EGenDriver Connector, создает последовательность Транзакций, определяемых хронологически как { T1, T2, … Tn }. В пределах каждой последовательности Время отклика Транзакции n определяется следующим образом:
  •  в случае архитектуры Неблокирующего потока Драйвера (см. 6.2.3.2)
                    • For n=1: DTn = 0
                    • For n>1: DTn = (sTn – sTn-1)
  •  Для всех прочих архитектур в Пункте 6.2
                           • For n=1: DTn = 0
                    • For n>1: DTn = (sTn – eTn-1)
  •  Где sTn иeTn определены в Пункте 6.5.1.1
6.5.2.2 Время Отсылки во время Интервала измерения должно быть менее (или равно) 1 с.

6.5.2.3 Задержка шага определяется как общее время, внедренное во Время отсылки (DTn), и его назначением является снижение скорости, с которой Транзакции отправляются в SUT.

6.5.2.4 Задержка шага может быть скорректирована Организатором теста для контроля частоты, с которой Транзакции отправляются в SUT. Задержка Шага может быть скорректирована для обеспечения производительности, соответствующей масштабу сконфигурированной базы данных (см. Пункт 6.7.1).
Примечание: Значение Задержки Шага может меняться во время Стабильного состояния и между различными экземплярами класса CCE.

6.6 Выполнение тестов

6.6.1 Определение терминов.

6.6.1.1 Термин Выполнение теста относится к следующему понятию: период времени, в течение которого SUT выполняет Транзакции, отправленные в нее Драйверами, за исключением Trade-Cleanup. Выполнение теста подразделено на три последовательные непрерывные и непересекающиеся периоды времени Нарастания, Стабильного состояния и Угасания.

6.6.1.2 Понятие Нарастание описывает период времени от начала Выполнения теста до начала Стабильного состояния

6.6.1.3 Понятие Стабильное состояние обозначает период времени от окончания Нарастания до начала Угасания.

6.6.1.4 Понятие Угасание обозначает период времени от конца Стабильного состояния до конца Выполнения теста

6.6.1.5 Понятие Интервал измерения означает Интервал измерения: период времени во время Стабильного состояния, выбранный Организатором для подсчета Отчётной производительности.

6.6.1.6 Понятие Рабочий день обозначает период из восьми часов деятельности по обработке транзакций

6.6.1.7 Производительность SUT называется Устойчивой, если она соответствует производительности на заданном промежутке времени (рассчитываемая как средняя производительность на этом промежутке), в которой не возникает значительных изменений..

6.6.2 Содержимое базы данных

6.6.2.1 Перед началом первого Выполнения теста начальная база данных должна соотвествовать требованиям пункта 2.6.1. Перед любым Выполнением теста база данных должна соответствовать требованиям пунктов 2.4 и 2.6.2.

Примечание: Пункт 2.6.2 определяет изменения в размерностях по мере того, как Транзакции выполняют операции с базой данных. Если не было выполнено ни одной транзакции, то применяются начальные размерности пункта 2.6.1 .

6.6.2.2 В момент начала Выполнения теста в базе данных не. должно содержаться каких либо ожидающих или отправленных запросов. Это может быть достигнуто путем использования либо базы данных с начальным наполнением, либо запуском Транзакции Trade-Cleanup перед началом Выполнения теста..

6.6.2.3 Изменения, которые могут быть внесены в таблицы базы данных TPC-E (если иное не указано Аудитором) между начальным наполнением и корректным Выполнением теста, должны быть осуществлены при помощи запуска действительных Транзакций, как указано в этой спецификации.

6.6.3 Устойчивая производительность

6.6.3.1 Во время Стабильного состояния производительность SUT должна быть Устойчивой до окончания Рабочего дня, начавшегося в начале Стабильного Состояния.

6.6.3.2 Некоторые особенности реализации контрольного тестирования могут привести к незначительным, но частым изменениям в производительности при расчете на неких более коротких периодах времени. Для соответствия требованиям Устойчивой производительности, суммарный эффект этих изменение на протяжении Рабочего дня не должен превосходить 2% Отчетной производительности.

Примечание: это требование является соблюденным, когда производительность, рассчитанная на любом периоде продолжительностью в один час, скользящему вдоль периода Стабильного состояния приращениями в десять минут, отличается от Отчетной производительности не более 2%.

6.6.3.3 Некоторые аспекты реализации контрольного тестирования могут привести к весьма нечастым, но случайным изменениям в производительности при расчетах на некоторых значительно более коротких периодах времени. Для соблюдения требования Устойчивой производительности суммарный эффект изменений за один Рабочий день не должен превышать 20% Отчетной производительности.
Примечание: Это требование является соблюденным, когда производительность, рассчитанная на любом периоде продолжительностью в десять минут, скользящему вдоль периода Стабильного состояния приращениями в одну минуту, отличается от Отчетной производительности не более, чем на 20%.

6.6.3.4 Любые ресурсы или компоненты, необходимые SUT для соответствия требованиям Устойчивой производительности, должны быть сконфигурированы на всем времени Выполнения теста.

Примечание 1: примером несоответствующей спецификации конфигруации будет система, в которой файл журнала базы данных размещен на неоднородном устройстве, начинающем работу с высокой производительностью и затем перенаправляющем данные на более медленный диск, и таким образом достигается уровень производительности в первые часы лучший, чем в оставшуюся часть дня.
Примечание 2: Примером соответствующей спецификации реализации будет система, в которой журнал базы данных размещен на однородном устройстве с объемом достаточным для использования на всем промежутке между контрольными точками и настроенном на повторное использование на каждом последующем цикле между контрольными точками, достигая таким образом Устойчивой производительности во время Стабильного состояния и в оставшуюся часть Рабочего дня.

6.6.4 Стабильное состояние

6.6.4.1 Все действия или события, которые должны быть выполнены через регулярные интерваны Тестируемой системой во время Стабильного состояния должны быть осуществлены в полной мере по меньшей мере один раз между началом Стабильного состояния и начальном Интервала измерения. (Пример см. в пунктах 6.6.5.3 и 6.3.3).
 
6.6.4.2 Продолжительность Стабильного состояния устанавливается Организатором и должна быть достаточной для:
  •  Включения в себя соответствующего Интервала измерения;
  •  Предоставления достаточных, по мнению Аудитора, свидетельств, что требования к Устойчивой производительности достигнуты.
6.6.5 Интервал Измерения

6.6.5.1 Интервал измерения должен быть подолжительностью не менее двух часов и должен полностью пройти во время Стабильного состояния.

6.6.5.2 Для задач расчетов отчетной статистики Транзакций используются все Транзакции и только те, чьи sTn и eTn находятся в пределах Интервала измерения.

6.6.5.3 Во время Интервала измерения содержимое базы данных (за исключением журнала исполнения), хранящееся на Постоянном носителе, не может быть старше, чем на 15 минут, любого Подтвержденного состояния в базе данных.

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

6.6.5.4 Все потоки исполнения, которые выполняют Транзакции CE во время Интервала измерения, должны:
  •  Выполнить по меньшей мере одну Транзакцию до начала Интервала измерения.
  •  Выполнить по меньшей мере одну Транзакцию после окончания Интервала измерения.
Создание, начало, остановка, удаление потоков исполнения, которые выполняют Транзакции CE, не разрешено во время Интервала измерения.

6.6.6 Рост базы данных

6.6.6.1 Ресурсы или компоненты, настроенные в SUT для поддержания выполнения Сочетания транзакций на Отчетной производительности во время периода требуемой Устойчивой производительности (см. пункт 6.6.3) должны допускать результирующее увеличение в размерах файлов данных СУБД (называемое Ростом данных) и файлов журнала СУБД (называемое Ростом журнала).

6.6.6.2 Суммарный объем для хранения файлов данных СУБД может быть разделен на следующие части:
  •  Свободное пространство, которое включает в себя любое пространство, выделенное для тестовой базы данных и доступное для будущего использования. Оно включает все пространство для хранения базы данных еще не использованное для хранения объектов базы данных (рядов, индексов, Метаданных базы данных) или еще не использованное как издержки форматирования СУБД.
  •  Растущее пространство, которое включает в сея любое пространство для хранения существующих рядов из Растущих таблиц и связанных с ними Определенными пользователем объектами. Оно включает все пространство хранения базы данных, добавляемое к тестовой базе данных в результате добавления нового ряда в Растущие таблицы, такое как данные рядов, данные индексов, и заголовки, такие как заголовки индексов, заголовки страниц, заголовки блоков и заголовки таблиц.
  •  Фиксированное пространство, которое включает в себя любое иное пространство, используемое для хранения статической информации и индексов. Оно включает все пространство, выделенное для хранения тестовой базы данных, которое не является ни Свободным пространством, ни Растущим пространством.
Примечание: хотя размерность не-Растущих таблиц и не меняется, все же возможно, что хранилище Фиксированного пространства может увеличиться по другим причинам. Если рассчитанный прирост за Рабочий день любого из таких объектов будет более, чем 5%-ое увеличение размерности, уже применяемое к не-Растущим таблицам по пункту 2.3.9, то вместо 5%-го прироста должен быть использован больший прирост.

6.6.6.3 Рост данных должен быть рассчитан на основе Выполнения теста следующим образом:
  •  Записывается Растущее пространство перед Выполнением теста.
  •  Выполнение теста осуществляется в полной мере.
  •  Записывается измеренное Растущее прострнаство после Выполнения Теста.
  •  Расчитывается отношение объема данных на каждую Транзакцию Trade-Result как общий прирост Растущего пространство на протяжении Выполнения теста, разделенный на общее числов Транзакций Trade-Result, завершенных во время Выполнения теста.
  •  Рост данных рассчитывается путем умножения отношения объема данных на каждую Транзакцию на Отчетную производительность и на продолжительность требуемой Устойчивой производительности.:
Рост данных: объем файлов данных СУБД, необходимый для вмещения увеличения размеров Растущих Таблиц, вызванных выполнением Сочетания Транзакций на Отчётной производительности во время периода требуемой Стабильной работы.

6.6.6.4 Рост Журнала должен быть рассчитан на основе Выполнения теста следующим образом:
  •  Записывается объем, занятый файлом журнала базы данных перед Выполнением теста.
  •  Выполнение теста проводится в полной мере.
  •  Записывается объем, занятый файлом журнала данных после окончания Выполнения теста.
  •  Суммарное увеличение занимаемого журналом базы данных объема делится на количество Транзакций Trade-Result, завершенных за время Выполнения теста, в результате будет получена величина Объем-Журнала-за-Trade-Result.
  •  Объем-Журнала-за-Trade-Result умножается на Отчетную производительность и на продолжительность требуемой Устойчивой производительности, чтобы в результате получить величину Роста журнала, представляющую собой следующее: объем файлов данных СУБД, необходимый для вмещения Журнала Отмены/Возврата, создаваемого в результате выполнения Сочетания Транзакций на Отчётной производительности во время периода требуемой Стабильной работы.
6.6.7 Производительность и размера базы данных

6.6.7.1 Для поддержания производительности пропорциональной размеру базы данных, Оцененная производительность должна располагаться в определенных пределах, основанных на размерах базы данных.

6.6.7.2 Номинальная производительность контрольного тестирования TPC-E равна 2.00 Транзакций-в-секунду-Е (tpsE) на каждые 1000 рядов клиентов в Настроенных клиентах

6.6.7.3 Другим способом выражения Номинальной производительности является использование Масштабирующего коэффициента. Масштабирующий коэффициент – это число рядов клиентов на одну транзакцию-в-секунду. Масштабирующий коэффициент для Номинальной производительности равен 500.

6.6.7.4 Оцененная производительность рассчитывается как полное число корректно выполненных Транзакций Trade-Result, выполненных в течение Интервала измерения, разделенное на длительность Интервала измерения в секундах

6.6.7.5 Количеств сконфигурированных Единиц обработки должно быть равно количеству Единиц обработки, к которым фактически были обращения во время Выполнения теста.

6.7 Необходимая отчетность

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

6.7.1.1 Оценка производительности, отображаемая TPC-E, является Отчетной производительностью. Единицей измерения Отчетной производительности SUT является tpsE. Значение этой величины основывается на Измеренной производительности, и ограничено требованиям, описанным в Пункте 6.7.1.2.

6.7.1.2 Если Оцененная производительнсоть составляет от 80% до 100% от Номинальной производительности, то Отчтетная производительность устанавливается равной Оцененной производительности. В противном случае, если Оцененная производительность превышает Номинальную производительность, но не более, чем на 2%, эта оценка может быть использована, но Отчетная производительность должна быть установлена равной Номинальной производительности. В результате этого возникает требование о том, чтобы Оцененная производительноссть превышала Отчетную Производительность не более, чем на 2%. Если Оцененная производительность не находится в этих пределах, то тогда измерения и оценки неверны и не могут быть представлены в отчете.
Примечание 1: К примеру, в случае базы данных, содержащей информацию о 5000 клиентах, номинальная производительность равна 10.00 tpsE. Выполнение измерений с результатами производительности между 10.00 tpsE и 10.20 tpsE будут представлено в отчете со значением 10.00 tpsE. Выполнение измерений с производительностью между 8.00 tpsE и 10.00 tpsE будет представлено в отчете как есть. Выполнение измерений с производительностью ниже 8.00 tpsE или превышающее 10.20 tpsE является недействительным для заданного размера базы данных и не должно быть приведено в отчете.
Примечание 2: Для увеличения уровня производительности, который может быть представлен в отчете, необходимо увеличить количество Сконфигурированных клиентов в базе данных. Для понижения уровня производительности, который может быть представлен в отчете, необходимо уменьшить количество Сконфигурированных клиентов в базе данных. Каждое из двух этих действий требует создания новой базы данных.

6.7.1.3 Отчетная производительность должна быть измерена без интерполяций и экстраполяций и округлена вниз до двух ближайших знаков после запятой. К примеру, предположим, что во время Интервала измерения, для которого соблюдены все требования к 90%-му Времени отклика было получено значение производительности 105.748 tpsE, и для Интервала измерения, 90%-е Время отклика которого превышает заданные ограничения, получено значение производительности 117.572 tpsE. В таком случае Отчетная производительность развна 105.74 tpsE, а не 105.75 или какое-либо усредненное значение между 105.748 и 117.572.

6.7.2 График выполнения теста
Для всего периода выполнения теста должен быть приведен График отношения Измеренной производительности ко времени, замеряемому по настенным часа в минутах. На оси Х отображается время, прошедшее с момента начала выполнения теста. На оси Y откладывается значение производительности в tpsE. Шаг значений должен быть установлен равным одной минуте. На графике должны быть отображены Период нарастания, Интервал измерения и Стабильное состояние. График Выполнения теста должен быть приведен в Отчете.


                                                     Рисунок 6.f – Пример графика зависимости Оцененной производительноси от прошедшего времени

6.7.3 Основные показатели

6.7.3.1 Для соответствия стандарту TPC-C и следования Политике Законного Использования и Рекомендациям TPC, все публичные ссылки на результаты TPC-C для каждой конфигурации должны включать следующие компоненты, которые будут называться Основными показателями.

  •  Отчётная производительность TPC-E, выраженная в tpsE. Это называется Оценкой производительности.
  •  Оценка цена/производительность. Оценка стоимости TPC-E на промежутке в 3 года, разделенная на Отчётную производительность, выражаемая как цена/tpsE. (См. Пункт 8 ).
  •  Дата доступности. Дата, когда все средства, необходимые для достижения указанной производительности, будут доступны (указанной как одна дата на Сводном исполнительном указании). (См. пункт 9.2.1.1).
6.7.4 Результаты EGenValidate

6.7.4.1 Каждая Единица обработки должна во время Интервала измерения создавать примерно одно и тоже количество завершенных транзакций Trade-Result. Соответствие этому требованию должно быть продемонстрировано при помощи прохождения теста EGenValidate и представления этих результатов в Дополнительных файлах. EGenValidate – это исходный код, предоставляемый TPC. Организатор должен создать исполняемый файл EGenValidate соответствующий его среде работы.

6.7.4.2 Когда организаторы выполняют EGenValidate, они должны предоставить следующие входные данные:
  •  количество Сконфигурированных Клиентов.
  •  стандартное отклонение числа транзакций Trade-Result, выполняемых для каждой Единицы Обработки во время Интервала измерения (см. пункт 6.6.5.2)
стандартное отклонение =

где ni = количество транзакций Trade-Result завершенных на каждую Единицу обработки i за время Интервала измерения.

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

  •  количество секунд в Интервале измерения
  •  фактическое количество tpsE, зафиксированное во время Интервала измерения.
6.7.4.3 EGenValidate осуществляет следующие действия:

1. Считывает входные величины.
2. Использует код EGen для имитации 10,000 запусков на базе данных TPC-E для этого количества Сконфигурированных Клиентов. Программа подсчитывает среднее количество и стандартное отклонение количества транзакций Trade-Result на Единицу Обработки за время Интервала измерения.
3. Выводит надпись «Passed!», если максимальное рассчитанное стандартное отклонение по 10,000 имитациям запусков больше или равно стандартному отклонения Интервала измерения. В противном случае выводится надпись «Failed!».