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

В качестве примера можно упомянуть серию популярных тестов TPC, служащих для оценки параметров СУБД. Так, тест TPC-C, определяющий производительность систем онлайновой обработки транзакций, среди специалистов называется тестом «кэш-машины», и в процессе оптимизации систем для этого теста внимание уделяется именно взаимодействию процессора с кэшем. Другой тест, TPC-H, разработанный для оценки производительности запросов к хранилищам данных, имеет репутацию теста производительности процессора. Нельзя сказать, что этот факт делает такие тесты хуже. Действительно, для задач обработки транзакций и хранилищ данных взаимодействие с кэшем или производительность процессора критически важны, а значит, соответствующие результаты тестов вполне применимы к этому классу задач. Но главная задача тестов — нагрузка на всю систему и нахождение слабых мест — уходит здесь на второй план.

Тесты SAP

Сейчас фокус внимания ИТ-специалистов смещается в сторону тестов реальных приложений — естественно, эти приложения должны быть достаточно распространены. Пальма первенства в данной области принадлежит корпорации SAP, поставщику ERP-решений. Тесты SAP benchmark стали таким же стандартом, как и TPC, хотя корпорация разработала их с целью показать масштабируемость своих же приложений. Многие производители аппаратного обеспечения используют эти тесты для того, чтобы подчеркнуть характеристики своих серверов. Кроме того, SAP заявляет о возможности использования этих тестов для сайзинга (т. е. для подбора конфигурации необходимой мощности), в том числе для выдачи рекомендаций по аппаратному и программному обеспечению и СУБД. SAP также разрешает использовать эти тесты для сравнения возможностей различных систем. В настоящее время процедура тестирования полностью стандартизована и сравнима по качеству проработки стандартов с лучшими в своем классе тестами TPC. Однако стандартизацией TPC ведает общественная организация, а стандартизацией тестов SAP управляет Совет по производительности SAP (SAP Benchmark Council), основанный в 1995 году и состоящий из представителей SAP и технологических партнеров корпорации. При этом SAP сама разрабатывает и контролирует содержание тестов и устанавливает правила, определяющие процедуру тестирования, а технологические партнеры представляют результаты тестов в SAP на сертификацию. Эта структура в принципе более закрыта, чем система тестирования, основанная на открытых стандартах (например, TPC). Но поскольку речь не идет о сравнении продуктов SAP с конкурирующими продуктами, а интересы SAP не противоречат интересам технологических партнеров, эта модель вполне работоспособна.

Существует определенный набор правил тестирования, в который входят, например, следующие:

  • среднее время реакции системы в диалоговых формах не должно превышать 2 с;
  • при эмуляции действий пользователя по заполнению форм время его размышлений фиксировано и равно 10 с;
  • все использованные в тестах программные и аппаратные решения должны быть доступны для покупателей;
  • тестируемая аппаратная платформа должна быть доступна заказчикам не позднее чем через три месяца с момента сертификации результатов тестов.

Если рассмотреть эти правила внимательнее, то становится очевидно, что основное свойство тестов SAP — это их ориентация на массовое обслуживание клиентов; между тем тесты TPC ориентированы на достижение максимальной производительности.

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

При использовании методики SAP тестируется работа всех систем и подсистем — процессоров, системы ввода-вывода, сетевого трафика, обработки ошибок и т. д. Сам тест должен продолжаться не менее 15 мин, а его результаты потом интерполируются и нормируются.

SAP Standard Application Benchmark состоит из набора исполняемых сценариев, которые симулируют типичные транзакции и бизнес-процессы, соответствующие обычным сценариям работы с системой (типичная бизнес-нагрузка ERP-системы). Чтобы уравнять условия тестов, SAP предлагает набор тестовых данных, соответствующий типичным данным ERP-систем. В тестах SAP симулируется поведение клиента, заполняющего стандартные формы, — это обеспечивает соответствие тестов реальным условиям эксплуатации и позволяет применять их для сайзинга. Каждому симулируемому клиенту задается время задержки в 10 с перед выполнением очередного шага в диалогах, что соответствует среднему реальному времени размышления опытных операторов. Во время выполнения тестов число одновременно работающих симулированных клиентов непрерывно возрастает до тех пор, пока время отклика системы в диалоговом режиме не превысит установленные спецификацией на тесты 2 с.

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

Система mySAP Business Suite содержит обширный набор модулей, соответственно, и тесты SAP также представляют собой целый набор тестов, связанных с работой тех или иных модулей или, точнее, с выполнением той или иной бизнес-функции (их описание приведено в таблице). Наиболее распространен из них тест SD (Sales and Distribution — продажи и дистрибуция). Когда речь заходит о SAP benchmark без указания теста, то в большинстве случаев имеется в виду именно SD.

Характеристики набора тестов SAP
Тест Сокращение Тип теста (бизнес-функция)
Advanced Planner and Optimizer APO mySAP Supply Chain Management
Assemble-To-Order ATO mySAP Supply Chain Management
Materials Management MM mySAP Supply Chain Management
Production Planning PP mySAP Supply Chain Management
Sales and Distribution SD mySAP Supply Chain Management
Warehouse Management WM mySAP Supply Chain Management
MySAP Banking - Banks Customer Accounts BCA Industry Solutions
MySAP Retail   Industry Solutions
mySAP Utilities - Customer Care and Service ISU-CCS Industry Solutions
Financial Accounting FI mySAP Financials
Project System PS mySAP Product Lifecycle Management
Business Information Warehouse BW mySAP Business Intelligence
Cross Application Time Sheet CATS mySAP Human Resources
Payroll PY mySAP Human Resources

Еще один важный параметр для понимания результатов тестов — архитектура системы, в которой проводятся тесты. Так, One-tier (одноуровневая архитектура) — система, в которой представление данных (интерфейс с пользователем), приложение и СУБД находятся на одном компьютере. Она соответствует ПК или связке неинтеллектуальный терминал — мэйнфрейм. Two-tier — традиционная двухуровневая архитектура клиент-сервер, в которой реализация интерфейса выделена и размещена на отдельном компьютере (обычно ПК). Three-tier — трехуровневая архитектура, включающая клиент, сервер приложений и сервер СУБД. В такой архитектуре данные и логика исполнения приложения на сервере разделены между двумя и более отдельными машинами.

В настоящее время активно развивается также многоуровневая архитектура (Multi-tier) — технология распределенных вычислений, основанная на Web-сервисах (J2EE и .NET).

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

Распределенная многоуровневая архитектура пока мало представлена в тестах. Но, учитывая общую популярность Web-сервисов и использование платформы NetWeaver в последних версиях SAP, роль этой архитектуры и в данной области будет расти.

Тесты Oracle

Тесты Oracle Applications Standard Benchmark (OASB) находятся на втором месте по популярности среди тестов такого уровня, что отражает соотношение сил между самими приложениями SAP и Oracle. В области тестирования Oracle придерживается методики, отличной от подхода SAP. Стандартные тесты Oracle Applications Standard Benchmark основываются на усредненных результатах работы системы Oracle Applications. OASB — некоторая смесь, охватывающая функционирование семи наиболее часто используемых модулей Oracle Applications. Сюда входят модули Oracle Financials — Payables (AP), Receivables (AR), General Ledger (GL) и Assets (FA), а также Supply Chain Management — Purchase Orders (PO), Order Entry (OE) и Inventory (Inv).

Примечательная особенность этих тестов состоит в том, что новые пользователи в них добавляются не независимо, а так называемыми атомарными группами. Эта методика разработана на основе опыта работы реальных внедрений. В целом она соответствует реальной бизнес-ситуации, когда на шесть новых пользователей, вводящих счета, добавляется восемь пользователей Основной книги (General Ledger).

Важная характеристика тестов OASB — линейная зависимость числа выполняемых транзакций от числа пользователей. Oracle подчеркивает это достоинство своего теста: «Пользователи не становятся проще, когда их число растет». Впрочем, подобный подход используется не только в технологии OASB, он характерен и для многих других тестов, включая TPC.

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

Результат тестов OASB — число пользователей системы, при котором не менее 90% ответов на запросы выполняется менее чем за 4 с. Другой параметр, характеризующий систему, — среднее время ответа на запрос, которое обычно составляет около 1 с. Следует отметить, что, в отличие от SAP benchmark, здесь версии тестов меняются чаще и сравнение результатов тестов предыдущих версий с текущими невозможно. Поэтому число доступных текущих результатов тестов по OASB значительно меньше, чем по SAP benchmark.

***

Подобные тесты существуют и у других производителей, в частности, PeopleSoft, Siebel и Navision, но их значимость гораздо меньше. Эти тесты не стали стандартом, и из-за отсутствия достаточного числа сопоставимых результатов их трудно использовать.

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

Михаил Елашкин – директор аналитической компании Elashkin Research (http://www.elashkin.com)