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

1

Размещено на http://www.allbest.ru/

Абакан

2006

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

1. Область применения программы

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

Процесс нагрузочного тестирования разделяется на несколько самостоятельных этапов:

– анализ и проектирование нагрузки;

– настройка стенда реализации;

– разработка типовых сценариев;

– реализация модели нагрузки;

– проведение нагрузочных испытаний;

– анализ результатов испытаний и построение прогнозных моделей.

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

– модель нагрузки;

– типовые сценарии эксплуатации;

– реализация модели нагрузки;

– нагрузочные испытания;

В общем случае данные понятии раскрываются следующим образом.

Модель нагрузки.

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

Типовые сценарии эксплуатации.

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

Реализация модели нагрузки.

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

Нагрузочные испытания.

Выполнение типовых сценариев эксплуатации с использованием реализованной моделью нагрузки и замер значений заданных критериев эффективности.

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

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

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

Под нагрузочными испытаниями понимается выполнение или моделирование типовых сценариев эксплуатации с целью оценки критериев эффективности функционирования системы под нагрузкой.

1.1 Модель нагрузки

Для моделирования нагрузки используется следующая формула: , где M - модель нагрузки для тестирования системы управления иерархическими данными, MD - модель данных, которыми управляет система, MF - модель функциональности системы.

Модель данных.

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

,

где n - общее количество элементов в иерархии, flevel(x) - функция плотности распределения элементов по уровням и , - множество, а fchildren,j(x) - функция плотности распределения количества сыновей у элементов j-го уровня и , MEMmax - верхнее ограничение по использованию памяти в пересчете на один элемент иерархии.

Идентификация элемента в дереве.

Для идентификации элемента в дереве применяются следующие координаты: номер уровня, на котором находится элемент, и номер элемента среди элементов данного уровня. На рис. 1.1. и 1.2. представлен пример дерева с расставленными координатами элементов.



Рис. 1.1. Пример построения дерева.

Модель функциональности.

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



Рис. 1.2. Пример построения дерева.

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

,

где Fi - единица функциональности системы управления иерархическими данными, а n - общее количество таких функций.

,

где ki - коэффициент важности данной функции для системы, Tmax,i - верхнее ограничение по времени выполнения рассматриваемой функции, Hi - множество описаний вызовов элементарных иерархических операций, Ai - алгоритм данной функции, описанный в терминах элементарных иерархических операций. В описании функции системы может присутствовать либо Hi, либо Ai.

, где m - количество описываемых в множестве вызовов, oj - вид элементарной иерархической операции, hj - весовой коэффициент в контексте задачи Fi для j-го вызова операции, gj(x,y) - двумерная функция плотности распределения выборки для j-го вызова операции.

Далее рассмотрим пример модели функциональности системы управления иерархическими данными с одной функцией F1. Данная функция описывается двумя иерархическими операциями («поиск множества сыновей» и «поиск множества предков»). Для рассматриваемых операций приведена функция плотности распределения аргументов данных операций. График данной функции представлен на рис. 1.3.

,

где (см. рис. 1.3.), o1 - операция поиска множества сыновей, o2 - операция поиска множества предков.

1.2 Критерии эффективности способов реляционного моделирования систем управления иерархическими данными

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

Основными критериями эффективности функционирования системы управления иерархическими данными являются:

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

– необходимая для работы системы память - размер базы данных.

Критерии производительности.

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

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



Рис. 2.3. График функции

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

В данной формуле - производительность системы с иерархией из m и из n элементов соответственно.

Критерий использования памяти.

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



где N - количество элементов иерархии в базе данных, а M - занимаемый базой данных объем памяти.

2. Роль программы в процессе тестирования

Процесс тестирования реляционных реализаций систем управления иерархическими данными можно разбить на следующие этапы (см. рис. 2.1):

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

– описание модели нагрузки;

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

– тестирование;

– получение оценок критериев эффективности в разрезе функциональных единиц;

– получение интегральной оценки критериев эффективности.

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

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

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



Рис. 2.1. Процесс тестирования реляционных реализаций систем управления иерархическими данными

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

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

3. Функциональность программы

При проектировании системы тестирования способов реляционного моделирования систем управления иерархическими данными устанавливаются особые требования к архитектуре. Ключевыми требованиями к архитектуре системы тестирования являются:

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

– возможность задания различных планов тестирования;

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

– возможность использования различных исходных данных, также и возможность генерирования исходных данных;

– совместимость формата выходных данных тестирующей системы с математическими пакетами программ. Например, MathCad.

Рис. 3.1. UML диаграмма компонентов системы тестирования

Исходя из поставленных задач, систему тестирования можно разделить на два основных компонента (см. рис. 3.1.):

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

– подсистема тестирования реляционной модели.

Каждый из приведенных компонентов использует определенный набор функций. Преобразователь математической модели в реляционный вид использует математические функции, функции работы с промежуточным реляционным видом модели, функции работы с планом тестирования. Подсистема тестирования реляционной модели в своей работе не использует математические функции, а пользуется уже сформированным планом тестирования. Однако, дополнительно подсистема тестирования использует функции работы с РСУБД и модули реляционного моделирования иерархий.

Рис. 3.2. IDEF0 диаграмма процесса тестирования

Роли описанных выше компонентов в процессе тестирования показаны на рис. 3.2. На данном рисунке представлена IDEF0 диаграмма процесса тестирования, где A0 - компонент «Преобразователь математической модели в реляционный вид», а A1 - подсистема тестирования реляционной модели.

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

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

– построение на основе математической модели промежуточной реляционной модели, по которой уже будут строиться модели в фазе тестирования;

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

Рис. 3.3. UML диаграмма классов преобразователя математической модели в реляционный вид

Для решения данных задач используется система классов, продемонстрированная на рис. 3.3. В их число входят следующие группы классов:

– классы, определяющие различные математические функции и функции, вычисляющие интегралы с одним и двумя аргументами;

– классы для работы с математической моделью;

– классы для построения дерева;

– классы для работы с планом тестирования.

Подсистема тестирования реляционной модели.

Для достижения достаточной доли абстракции при разработке тестирующей системы применяется прием объектно-ориентированного проектирования, называемый паттернами (или шаблонами) проектирования. Результатом проектирования является объектная модель подсистемы тестирования реляционной модели (см. рис. 3.4). Данная объектная модель включает следующие группы классов:

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

– классы для работы с реляционными моделями иерархий;

– класс для работы с планом тестирования.

Для реализации абстракции от применяемого для тестирования метода и реализации абстрактного плана тестирования был применен шаблон проектирования «Стратегия». В тестирующей системе данный шаблон определяет семейство алгоритмов организации древовидных иерархий в реляционной среде, инкапсулирует каждый из них и делает взаимозаменяемыми. Семейство методов в системе задается классами: CDBTree_AdjacentList, CDBTree_MaterializedPath, CDBTree_NestedSets, CDBTree_NestedIntervals.

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

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

Реализация системы тестирования.

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



Рис. 3.4. UML диаграмма классов подсистемы тестирования реляционной модели

В листинге 3.1. приведен пример XML файла для следующей математической модели данных:

Листинг 3.1. Пример XML файла математической модели данных

<?xml version="1.0" encoding="windows-1251"?>

<model>

<data_model element_count=”20”>

<elements_by_level_distribution>

<function type="normal_distribution" begin="0" end="1" average="0.8" deviation="0.2"/>

</elements_by_level_distribution>

<children_distribution>

<function type="uniform_distribution" begin="0" end="1"/>

</children_distribution>

</data_model>

</model>

Реализация измерения использования памяти.

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

Листинг 3.2. SQL-код для оценки использования памяти для реляционной модели в PostgresSQL

SELECT

relname AS name, relfilenode AS oid,

(relpages * 8192 / (1024))::int as size_kb, reltuples as count

FROM pg_class

WHERE relname NOT LIKE 'pg%' ORDER BY relpages DESC;

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

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

Для программной реализации ранее разработанного алгоритмического обеспечения рассматриваемых методов реляционного моделирования древовидных иерархий и составления плана тестирования был выбран язык программирования PHP и его интерпретатор версии 5.0. Данная версия интерпретатора позволяет организовать объектно-ориентированную архитектуру приложения и обеспечить более простую реализацию тестирующей системы.

Специальные условия применения и требования организационного, технического и технологического характера

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

Условия передачи программной документации или ее продажи

Передача материалов исследования для их использования в каких либо целях происходит с письменного согласия автора.

Размещено на Allbest.ru

...