Home

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

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

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

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

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

Для проверки были предложены следующие тесты

Структура объекта

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

Пример объекта:

<book>
  <name>Освой XML</name>
  <price>23,18</price>
  <category>детектив</category>
  <authors>
     <author number=”1”>Белов А. Е.</author>
      <author number=”2”>Иванов Александр</author>
      <author number=”3”>Олди (соавторы)</author>
  </authors>
</book>

Тестируемые архитектуры БД

Классическая реляционная модель

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) не использовалось.

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