Исходники.Ру - Программирование
Исходники
Статьи
Книги и учебники
Скрипты
Новости RSS
Магазин программиста

Главная » Статьи по программированию » .NET - Все статьи »

Обсудить на форуме Обсудить на форуме

Сравнение производительности: управление транзакциями
В этой статье рассматриваются аспекты производительности управления транзакциями, влияющие на производительность, масштабируемость и надежность, путем сравнения моделей транзакций, таких как транзакции базы данных, ручные транзакции Microsoft ADO.NET и автоматические транзакции ADO.NET в общих сценариях приложений с базой данных Microsoft SQL Server 2000.

Введение

Варианты архитектуры для управления транзакциями влияют на производительность, масштабируемость и надежность. В этой статье подробно рассматриваются аспекты производительности этих вариантов путем сравнения относительной производительности различных моделей транзакций, таких как ручные транзакции Microsoft® ADO.NET и автоматические транзакции ADO.NET в общих сценариях приложений с базой данных Microsoft SQL Server™ 2000.

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

Варианты архитектуры

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

Транзакция базы данных

Транзакции базы данных реализуются в Transact-SQL, который заключает в обертку требуемые операции в рамках операторов BEGIN TRANSACTION и COMMIT/ROLLBACK TRANSACTION.

Ручная транзакция

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

Автоматическая транзакция

Для участия втранзакции класс .NET регистрируется вMicrosoft Windows® 2000 Component Services (COM+). Класс помечается декларативными атрибутами, определяющими его участие в транзакции.

Сценарии тестирования

Для сравнения моделей транзакций использовался метод, при котором в соответствующие таблицы базы данных вставлялся заголовок заказа и подробные сведения о заказе. Если какая-либо вставка оказывалась неуспешной, транзакция откатывалась. Транзакция совершалась после успешного выполнения всех вставок.

Для того чтобы тест был максимально реалистичным, в базу данных было загружено более 100.000 строк учетных записей клиентов, один миллион строк заказов (10 заказов на одного клиента) и более пяти миллионов строк подробных сведений о заказе (5 строк подробных сведений на один заказ). Данные находятся в базе данных SQL Server 2000, для подключения к SQL Server используется провайдер данных SQL Server .NET. Некоторыми из сравниваемых здесь подходов используются возможности XML в SQL Server 2000.

InsertOrder

При использовании метода InsertOrder данные, представляющие заказ с рядом подробных сведений, принимаются и вставляются в таблицы базы данных Order и OrderDetails как часть одной транзакции.

Инструментарий и стратегия тестирования

В данных тестах Web-страницей ASPX вызывается сборка .NET, содержащая тестовый код. Хотя при непосредственном тестировании методов управления транзакциями, в отличие от тестирования в рамках Web-сервера, производительность была бы выше, тестирование в не сохраняющей состояния (stateless) среде является реалистичным для общих сценариев приложений. Кроме того, существует широкий спектр инструментария для стресс-тестирования Web-страниц, позволяющего выполнить многопоточное тестирование.

Для тестирования использовался Microsoft Application Center Test (ACT), предназначенный для стресс-тестов Web-серверов и анализа проблем с производительностью и масштабируемостью Web-приложений, в том числе ASP-страниц и используемых ими компонентов. Более подробная информация о создании и запуске тестов содержится в документации к ACT. С помощью Application Center Test можно смоделировать большую группу пользователей путем открытия нескольких подключений к серверу и быстрой отправки HTTP-запросов. Он также позволяет построить реалистичные сценарии тестирования, где можно вызвать один и тот же метод со случайным набором значений параметров. Это важно, поскольку один и тот же метод с одинаковыми значениями параметров не будет вызываться пользователями многократно. Другая полезная возможность Application Center Test - это запись результатов тестирования, в которых содержатся наиболее важные сведения о производительности Web-приложения.

Приложения работают на различных уровнях изоляции транзакции в зависимости от бизнес-потребностей. Изоляция – это требуемая степень обособления одной транзакции от других транзакций. Высокий уровень изоляции позволяет обеспечить непротиворечивость данных, однако может существенно повлиять на масштабируемость приложения. Низкий уровень изоляции позволяет увеличить масштабируемость приложения в ущерб правильности данных. Microsoft SQL Server 2000 поддерживает четыре уровня изоляции: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ иSERIALIAZABLE. По умолчанию используется уровень изоляции READ COMMITTED. Более подробная информация содержится в документации по Microsoft SQL Server 2000. В COM+ (версии 1.0), работающем в Windows 2000, поддерживается только сериализуемая изоляция – самая высокая степень изоляции. Такой высокий уровень защиты данных достигается за счет снижения производительности. (Примечание: COM+ 1.5, поставляемый с Microsoft Windows .NET Server (в настоящее время  - Beta 3), позволяет сконфигурировать уровень изоляции для компонента транзакции). Для более точного сравнения моделей транзакции запускались на уровне сериализуемой изоляции.

Конфигурация системы

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

Таблица 1. Конфигурация клиентской системы

Кол-во клиентов

Компьютер/CPU

Кол-во CPU

Память

Жесткий диск

Программное обеспечение

1

Dell Precision WorkStation 530 MT 1694 МГц

1

512 Мбайт

16,9 Гбайт

Windows XP

Application Center Test

Таблица 2. Конфигурация Web-сервера

Кол-во серверов

Компьютер/CPU

Кол-во CPU

Память

Жесткий диск

Программное обеспечение

1

Compaq Proliant 400 МГц

4

640 Мбайт

50 Гбайт

Windows 2000 Advance Server SP 2

Выпущенная версия .NET Framework

Таблица 3. Конфигурация сервера базы данных

Кол-во серверов

Компьютер/CPU

Кол-во CPU

Память

Жесткий диск

Программное обеспечение

1

American Megatrends Atlantis
800 МГц

2

1 Гбайт

28 Гбайт

Windows 2000 Advance Server SP 2

SQL Server Enterprise Edition SP 2

Результаты тестирования производительности

Ключевые показатели производительности – это пропускная способность и время ожидания. Для заданного объема возвращаемых данных пропускная способность - это число клиентских запросов, обработанных за определенную единицу времени, обычно за одну секунду. Поскольку пиковая пропускная способность может произойти за время ответа, что недопустимо с точки зрения применимости, отслеживалось время ожидания, измеряемое как время ответа с помощью отчета, сгенерированного Application Center Test для каждого тестового прогона.

InsertOrder с помощью OPENXML

В первом наборе тестов заказ и подробные сведения о нем передаются в формате XML из таблиц DataSet хранимой процедуре Microsoft SQL Server 2000. Код Transact-SQL в хранимой процедуре использует метод OPENXML для выполнения соответствующих вставок в таблицы Orders (Заказы) и OrderDetails (Подробные сведения о заказе) в одном цикле обработки базы данных. Сначала тест выполняется для одного заказа и 10 подробных сведений о нем.

 

Дополнительная информация по рисунку

Request / Second vs. User Load = число запросов в секунду к числу пользователей

Order = заказ

Details = подробные сведения о заказе

Response Time vs. User Load = время ответа к числу пользователей

Рис. 1. InsertOrder_OpenXml (1 заказ, 10 подробных сведений о заказе)

Примечания

  • В подходе DatabaseTxn хранимая процедура заключают в обертку операции с операторами BEGIN TRANSACTION и COMMIT/ROLLBACK TRANSACTION.
  • В подходе ManualTxn транзакция управляется объектом ADO.NET SQLTransaction.
  • В подходах ManualTxn_COM+_IP и ManualTxn_COM+_OP транзакция управляется объектом ADO.NET SQLTransaction, однако сборка конфигурируется в COM+ как пакет библиотеки и пакет сервера соответственно.
  • Сборка .NET, в которой содержатся реализации AutomaticTxn и AutCompleteTxn, регистрируется с помощью COM+. В подходе AutomaticTxn транзакция явно совершается или отменяется, тогда как в подходе AutoCompleteTxn совершение или отмена текущей транзакции определяется в сборке .NET.
  • В подходах AutomaticTxn_IP и AutoCompleteTxn_IP приложение COM+, содержащее сборку, - это активизируемое библиотекой приложение, поэтому оно выполняется в процессе создавшего его клиента.
  • В подходах AutomaticTxn_OP и AutoCompleteTxn_OP приложение COM+, содержащее сборку, - это активизируемое сервером приложение, поэтому оно выполняется в процессе-заменителе (dllhost.exe).

Как показано на рис. 1, производительность подходов DatabaseTxn, ManualTxn и ManualTxn_COM+_IP примерно одинакова, хотя в подходе DatabaseTxn пропускная способность  немного выше, чем в модели ручной транзакции. Причина этого состоит в том, что ручной транзакции ADO.NET требуются дополнительные циклы обработки базы данных для начала и завершения транзакции.

Издержки на возможность взаимодействия с COM+ в подходе ManualTxn_COM+_IP минимальны, поскольку этот подход не использует службы COM+. Поэтому его поведение похоже на поведение ManualTxn, при котором COM+ вообще не используется.

При сравнении подходов ManualTxn и ManualTxn_COM+_IP с AutomaticTxn_IP видно, что автоматические транзакции медленнее в среднем на 30%. Это обусловлено тем, что затраты на настройку транзакции с помощью распределенного контроллера транзакций (DTC) высоки по сравнению с общим объемом работы, выполненной в ходе транзакции (11 вставок). В подходе AutomaticTxn_IP также используется вызов межконтекстного метода, требующего перехода между контекстами, и, следовательно, некоторых дополнительных издержек.

Производительность подхода AutomaticTxn_IP выше, чем у подходов ManualTxn_COM+_OP и AutomaticTxn_OP, поскольку в AutomaticTxn_IP сборка выполняется пакетом библиотеки в процессе вызывающего приложения (в данном случае aspnet_wp.exe), без использования маршалинга. В подходе AutomaticTxn_IP общие издержки, в том числе затраты на DTC, меньше издержек на маршалинг данных в подходе ManualTxn_COM+_OP. Этим объясняется несколько более высокая производительность в AutomaticTxn_IP, чем в ManualTxn_COM+_OP.

Как показано нарисунке, поведение версий AutoComplete, т.е. AutoCompleteTxn_IP иAutoCompleteTxn_OP, полностью идентично поведению версийAutomaticTxn_IP иAutomaticTxn_OP соответственно. Недостатком использования фиксации AutoComplete является возможное уменьшение производительности приложения по причине увеличения времени, требуемого транзакции для освобождения ресурсов сервера, поскольку фиксация определяет совершение транзакции при успешном возвращении метода. Кроме того, этот метод не позволяет сгенерировать удобное для пользователя сообщение, если транзакция оказывается неудачной.

 

Дополнительная информация по рисунку

Request / Second vs. User Load = число запросов в секунду к числу пользователей

Order = заказ

Details = подробные сведения о заказе

Response Time vs. User Load = время ответа к числу пользователей

Рис. 2. InsertOrder_OpenXml (1 заказ, 100 подробных сведений о заказе)

При использовании в тесте 1 заказа и 100 подробных сведений о нем различия в производительности между подходами становятся очень незначительными.

Производительность модели транзакции базы данных по-прежнему немного выше, чем у других подходах.

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

InsertOrder с помощью нескольких DataAdapter

Во втором наборе тестов с таблицами базы данных Orders и OrderDetails были связаны отдельные DataAdapter. Хранимые процедуры для InsertCommand определены в DataAdapter. Сначала вызывается метод Update в DataAdapter таблицы Orders, возвращающий OrderId (Идентификатор заказа) недавно вставленного заказа. Затем вызывается метод Update в DataAdapter таблицы Details. Поскольку метод Update не отправляет базе данных изменения в виде пакета, в этом методе используются несколько циклов обработки базы данных для выполнения вставок.

Дополнительная информация содержится в статье Сравнение производительности: методы доступа к данным, вМетодов Доступа к данным, которой сравниваются различные методы доступа к данным, такие как подход OPENXML и подход с несколькими DataAdapter.

Сначала тест выполняется для одного заказа и 10 подробных сведений о нем.

 

Дополнительная информация по рисунку

Request / Second vs. User Load = число запросов в секунду к числу пользователей

Order = заказ

Details = подробные сведения о заказе

Response Time vs. User Load = время ответа к числу пользователей

Рис. 3. InsertOrder_DataSet (1 заказ, 10 подробных сведений о заказе)

Примечания

  • В подходе ManualTxn транзакция управляется объектами ADO.NET SQLTransaction.
  • В подходах ManualTxn_COM+_IP и ManualTxn_COM+_OP транзакция управляется объектом ADO.NET SQLTransaction, однако сборка конфигурируется в COM+ как пакет библиотеки и пакет сервера соответственно.
  • Сборка .NET, в которой содержатся реализации AutomaticTxn и AutCompleteTxn, регистрируется с помощью COM+. В подходе AutomaticTxn транзакция явно совершается или отменяется, тогда как в подходе AutoCompleteTxn совершение или отмена текущей транзакции определяется в сборке .NET.
  • В подходах AutomaticTxn_IP и AutoCompleteTxn_IP приложение COM+, содержащее сборку, - это активизируемое библиотекой приложение, поэтому оно выполняется в процессе создавшего его клиента. 
  • В подходах AutomaticTxn_OP и AutoCompleteTxn_OP приложение COM+, содержащее сборку, - это активизируемое сервером приложение, поэтому оно выполняется в процессе-заменителе (dllhost.exe).

Производительность подходов ManualTxn и ManualTxn_COM+_IP практически одинакова по причине минимальных затрат на возможность взаимодействия с COM+.

AutomaticTxn_IP значительно медленнее вышеупомянутых подходов, потому что затраты на настройку транзакции с помощью распределенного контроллера транзакций (DTC) высоки по сравнению с общим объемом работы, выполняемой в ходе транзакции (11 вставок). Кроме издержек на DTC в подходе AutomaticTxn_IP имеются также некоторые дополнительные затраты на возможность взаимодействия с COM+ и переход между контекстами, как отмечалось ранее.

Производительность подхода AutomaticTxn_IP выше, чем у подходов ManualTxn_COM+_OP и AutomaticTxn_OP, поскольку в последнем подходе приложение COM+ сконфигурировано как пакет сервера, выполняющийся в отдельном процессе-заменителе (dllhost.exe), несущем издержки на маршалинг данных.

Как и ожидалось, поведение версий AutoComplete, т.е. AutoCompleteTxn_IP и AutoCompleteTxn_OP, полностью идентично поведению версий AutomaticTxn_IP и AutomaticTxn_OP соответственно.

 

Дополнительная информация по рисунку

Request / Second vs. User Load = число запросов в секунду к числу пользователей

Order = заказ

Details = подробные сведения о заказе

Response Time vs. User Load = время ответа к числу пользователей

Рис. 4. InsertOrder_DataSet (1 заказ, 100 подробных сведений о заказе)

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

Заключение

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

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

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

В модели автоматической транзакции имеются дополнительные издержки на взаимодействие с DTC и на межоперационное время с COM. Как показали тесты, затраты на DTC снижаются при увеличении длины транзакции. Преимущество использования этой модели состоит в значительном упрощении дизайна приложения и уменьшении требований к кодированию. Автоматическую транзакцию следует выбирать, если транзакцией охватывается несколько менеджеров ресурсов, работающих с транзакциями, таких как базы данных SQL Server, очереди сообщений MSMQ и т.д.


Может пригодится:


Автор: Прия Дхаван
Прочитано: 2807
Рейтинг:
Оценить: 1 2 3 4 5

Комментарии: (0)

Добавить комментарий
Ваше имя*:
Ваш email:
URL Вашего сайта:
Ваш комментарий*:
Код безопастности*:

Рассылка новостей
Рейтинги
© 2007, Программирование Исходники.Ру