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

       

Тестовый набор TPC-W


Поскольку нас интересовала сквозная производительность корпоративных Web-приложений, включающих обработку транзакций, мы использовали тестовый набор TPC-W [28]. В других тестовых наборах для OLTP (таких как TPC-C и TPC-E) упор делается на влиянии на общую производительности системы баз данных, и не имитируется какая-либо сложная логика приложения. Хотя организация TPC не рекомендует использовать TPC-W, этот тестовый набор остается популярым и в индустрии, и в академических организациях.

Тестовый набор TPC-W моделирует онлайновый книжный магазин с использованием смеси из пятнадцати видов запросов: поиск продуктов, выдача информации о продуктах, оформление заказа на покупку и т.д. Кроме того, в TPC-W специфицируются три вида рабочих нагрузок: (a) просмотр товаров (browsing), (b) подбор товаров (shopping), (c) оформление заказов (ordering). Для каждого вида рабочей нагрузки устанавливается вероятность появления в ней каждого вида запроса. Во всех экспериментах, описываемых в этой статье использовалась смесь "оформление заказов", поскольку в ней содержится больше всего запросов на обновление данных (примерно треть от общего числа запросов). Наконец, рабочий набор TPC-W позволяет изучать различные рабочие нагрузки с учетом темпа поступления запросов. Для этой цели в рабочем наборе TPC-W используются эмулируемые пользовательские браузеры (emulated browser, EB). Каждый EB имтирует действия одного пользователя, который выдает запрос (в соответствии с вероятностями, установленными для используемой смеси), ожидает ответа и по истечении специфицированного времени выдает следующий запрос. Мы изменяли параметр EB от 1 (≈ 500 запросов в час) до 9000 (≈ 1250 запросов в секунду). В смеси "оформление заказов" запросу уровня TPC-W соответствовало в среднем 6,6 HTTP-запросов, поскольку Web-страницы TPC-W содержат несколько встроенных компонентов (например, изображений).

В тестовом наборе TPC-W имеются два показателя. Первый показатель – это показатель пропускной способности, т.е.
число допустимых запросов TPC-W, поступающих за одну секунду. Для этого показателя обычно (и в данной статье) используется аббревиатура WIPS (от Web Interactions Per Second). Важно, что учитываются только допустимые запросы, время обработки которых соответствует установленным требованиям. В зависимости от вида запроса допустимое время ответа изменяется от 3 до 20 секунд. Результаты выполнения тестового набора принимаются во внимание, если 90% всех запросов каждой категории являются допустимыми, и система обеспечивает полный ответ на каждый из этих запросов в пределах допустимого времени. Нельзя, например, игнорировать все запросы на обновление данных и добиваться высокого значения WIPS за счет выполнения только запросов на чтение.

Вторым показателем, определяемым в TPC-W, является Cost/WIPS. Этот показатель связывает производительность (т.е. WIPS) с совокупной стоимостью владения (total cost of ownership) компьютерной системы. Чтобы обеспечить возможность измерения этого показателя, в тестовом наборе TPC-W приводятся точные правила вычисления стоимости системы. Для данного исследования эти правила пришлось ослабить, потому что они не применимы ни к каким исследуемым "облачным" службам. Во всех наших экспериментах стоимость определялась размером счета, который мы должны были оплатить.

Кроме упрощения правил вычисления показателя Cost/WIPS, мы ввели в тестовый набор TPC-W следующие изменения:



  • База данных тестового набора: В тестовом наборе TPC-W указывается, что размер тестовой базы данных возрастает линейно в зависимости от числа EB. Поскольку нас особо интересовали масштабируемость служб по отношению к транзакционной рабочей нагрузки и эластичность этих служб при изменении рабочей нагрузки, мы выполняли все свои эксперименты с использованием фиксированной тестовой базы данных, соответствующей стандартной базе данных TPC-W для 100 EB. Эта база данных содержала информацию о 10000 единицах товаров, и ее исходные данные составляли 315 мегабайт, что обычно приводило к размерам баз данных около 1 гигабайта при добавлении индексов (подраздел 6.5).



  • Содержание раздела