Объемное тестирование на стадии выбора архитектуры

Когда речь заходит об объемном тестировании или тестировании производительности, люди обычно понимают под этим испытание уже готовой программы. Такой подход мне кажется неверным. Объясню почему. Несоответствие требованиям может означать не просто ошибки программирования, но неправильный выбор архитектуры. А изменение архитектуры – это землетрясение. Как справедливо говорит Алан Купер «Создание кода по отношению к проектированию – все равно, что заливка бетонной смеси в строительстве». И изменение архитектуры в этом случае можно рассматривать как изменение формы, в которую уже залили бетон.

При разработке программы можно столкнуться с недостаточной производительностью. Но еще хуже резкая потеря производительности при достижении некоторого порога данных. Если производительность пузырьковой сортировки на сотне записей меньше необходимой в два раза – это ерунда. Возьмем сервер помощнее. А что делать, если пользователю нужно работать с тысячей записей? Мне могут возразить, что тут делов на пять минут – просто сменить алгоритм. Хорошо, изменим задачу. Для сайта принято решение хранить картинки в файловой системе. Нормальное архитектурное решение. Для небольшого количества файлов. А для пары миллионов? Так, время на исправление несколько увеличилось. Ну а если для исправления потребуется переход на другую платформу? Например с MySQL на MSSQL (или наоборот, это неважно)? Переписать несколько сотен хранимок, перелопатить кучу кода, … Срыв проекта гарантирован.

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

В MSSQL2005 появилась прекрасная возможность хранить XML в одном поле и работать с ним напрямую. Экономия при программировании колоссальная. Те, кто сталкивался с реализацией работы с объектами произвольной структуры в реляционной базе, меня поймут. Я участвовал в проектах, где подобное было реализовано двумя различными методами. Это ужасно. Нет, конечно, пальцы после этого можно загибать веером, но времени и сил на реализацию такой архитектуры уходит масса.

XML тип в каком то смысле панацея. Только вот не оказалось бы лекарство хуже болезни. Механизм новый, возможности неизвестны. Риск получить неудовлетворительную производительность при реальных данных – очень высок.

Для проверки были предложены следующие тесты.
——————————————————–
Структура объекта
Тестирование проводится на тестовой базе данных, хранящая записи о книгах, ценах, категории и авторах. У каждой книги может быть от одного до десяти авторов. В моделях не учитывается, что у разных книг может быть один и тот же автор. Каждая книга относится к одной из категорий. У каждой книги есть цена.
Пример объекта:


  Освой XML
  

23,18  
 
     Белов А. Е.
     Иванов Александр
     Олди (соавторы)
 

Тестируемые архитектуры БД.
Классическая реляционная модель

Book 

Id Int
Name Varchar
Category Int
Price Decimal

Author

Id Int
BookId Int
Name Varchar

Промежуточная

Id Int
Name Varchar
Category Int
Price Decimal
Authors XML

XML

Id Int
Book XML

Метод проведения тестов
Осуществляем последовательно 100-1000 запросов с параметром. Тесты проводятся несколько раз, после чего результат усредняется.
Последовательно увеличиваем объем данных, начиная с десяти тысяч. Приращение осуществляем следующим образом: 10 тыс, 30 тыс, 100 тыс, …и так до миллиона.
В случае резкого падения производительности, участок, на котором это произошло исследуется с меньшими приращениями.

Исследуемые типы запросов
Вставка записей
В данном тесте исследуется время вставки объекта «книга-авторы» в БД.

Изменение записей
В тесте исследуется изменение объекта «книга-авторы» в БД. Изменение:
• Меняется название книги
• Удаляется автор
• Добавляется автор

Простой запрос объекта
Выдать объекта «книга-авторы» для книги с определенным названием

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

Агрегированные функции
Вычисляем среднюю сумму по одной из категорий
——————————————————–
Это тестирование проводилось до написания первой строчки кода. В качестве заглушки использовались тестовые данные, в качестве драйвера – скрипты. Движок – сам MSSQL. Никакое специализированное средство автоматизированного тестирования (типа LoadRunner) не использовалось.

Я не привожу ни результатов тестов, ни скриптов, ни еще некоторых важных моментов. Главную идею статьи они не иллюстрируют.

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

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.