COM+ и .NET – практичный подход - часть 1 - Типы приложения Com+ и как они влияют на производительность приложения

Типы приложения Com+ и как они влияют на производительность приложения

COM+ может двумя путями разместить компоненты .Net: приложение библиотеки и приложение сервера. Приложение библиотеки выполняет компонент в вызывающем процессе, тогда как приложение сервера выполняет компонент в специальном процессе, созданном COM+, под названием Dllhost.exe. Тип приложения COM+ влияет на все составляющие размещенного компонента. Приложение сервера работает в отдельном процессе, влияя на общую производительность приложения, которому приходится пересекать границу процессов для вызова служб компонента. Межпроцессное взаимодействие является ведущим фактором в различиях касательно производительности и ограничений между приложениями библиотеки и сервера.

COM+ основан на контексте. Контекст является средой для объектов с одинаковыми требованиями к исполнению. Контекст может перехватить вызов метода или активацию объекта и вследствие этого выполнить одну из служб COM+. Чтобы зарегистрировать класс .Net в COM+, класс должен наследоваться от ServicedComponent. Реализация ServicedComponent базируется на дистанционной связи, перехватывающей вызов метода. Если CLR требуется для создания экземпляра нового производного объекта ServicedComponent, делается вызов управляемого C++. Вызов управляемого C++ CoCreateInstance, позволяющий COM+ привязать объект к неуправляемому контексту и задать неуправляемые службы, предопределенные для регистрации класса в каталоге COM+. CLR также способен использовать атрибуты, связанные программистом с классом, чтобы установить метаданные класса в COM+, если они не установлены ранее. Во время регистрации ключ InProcServer32, обычно указывающий на путь COM DLL или COM EXE, указывает на mscoree.dll, являющийся механизмом .NET JIT(just in time – точно вовремя) (как ни странно, mscoree.dll является COM DLL). Со времени обратного вызова CLR созданный фактический объект является настоящим управляемым объектом.

Описанный процесс происходит, когда требует объект библиотеки COM+, и в конце CLR создает чистый управляемый класс. Объекты, зарегистрированные как приложение сервера, получили другой путь экземпляра. Межпроцессный характер приложения сервера требует дистанционной связи и DCOM(распределённая модель компонентных объектов) для вызова зарегистрированного объекта из управляемого кода. На самом деле происходит два вызова дистанционной связи в ходе активации объекта: один для получения URI объекта сервера, а второй для фактической активации. Межоперационные вызовы COM производятся в ходе активации и демаршалинге данных. В обоих случаях (библиотека, сервер) объект является управляемым объектом, созданным CLR, только объект сервера требует дистанционной связи и DCOM для активации объекта и для каждого вызова для демаршалинга параметров. Влияние этих различий показано в разделе производительность.

Производительность

После объяснения шагов, касающихся активации приложения библиотеки и сервера, рассматривается, как каждая из этих опций влияет на производительность веб-приложения. Как сказано ранее, данная статья посвящена практичному подходу, поэтому одновременно с проверкой производительности приложений COM+ проверяются другие службы COM+, способные повлиять на производительность веб-приложения в определенных ситуациях. Эти службы включают в себя JIT, организацию пула объектов и поддержку синхронизации. Подробно они не разбираются, полное описание их смотрите в http://www.ondotnet.com/pub/a/dotnet/excerpt/com_dotnet_ch10/index.html?page=1 или в документациях MSDN.

Испытание производительности основано на обычном приложении ASP.NET, созданном в традиционной слойной архитектуре. Приложение ASP.NET состоит из 6 страниц:
1.    GetDataNoCom.aspx : страница, получающая около 20 записей из базы данных и отображающая их.
2.    GetDaataCom.apsx : страница, вызывающая класс, зарегистрированный в COM+, чтобы извлечь около 20 записей из базы данных и отобразить их.
3.    GetLargeDataNoCom.aspx : страница, получающая около 1000 записей из базы данных и отображающая часть из них
4.    GetLargeDataCom.aspx : страница, вызывающая класс, зарегистрированный в COM+, чтобы извлечь около 1000 записей из базы данных и отобразить часть из них.
5.    LongInit.aspx : страница, вызывающая ресурс с длительным временем инициализации.
6.    LongInitCom : страница, вызывающая класс, зарегистрированный в COM+. Класс com+ использует ресурс с длительным временем инициализации.

Каждый из объектов COM+ будет испытан во время работы в качестве библиотеки и сервера с JIT, организацией пула объектов и временем вызова методов. Испытание проведено на компьютере с одним процессором Intel 4 1,80ГГц и 500 Мб ОЗУ. Полученные числа - RPS (запросов в секунду), возвращенные ACT (испытание центра приложений). Каждое испытание выполняется 5 секунд с 10 одновременными пользователями.

Таблица1.0 результаты испытания
	нетCOM+	библиотека				сервер
		организация пула	JITA	время вызова	PRS	организация пула	JITA	время вызова	RPS
GetDataNoCom – 90 записей	300	X	X	X	X	X	X	X	X
GetDaataCom – 90 записей	X	-	-	-	233	-	-	-	111
	X	+	+	-	200	+	+	-	105
	X	+	+	+	200	+	+	+	105
GetLargeDataNoCom - 900 записей	50	X	X	X	X	X	X	X	X
GetLargeDataCom – 900 записей	X	-	-	-	49	-	-	-	36
	X	+	+	-	48	+	+	-	28
	X	+	+	+	48	+	+	+	28
LongInit	1	X	X	X	X	X	X	X	X
LongInitCom	X	-	-	-	1	-	-	-	1
	X	+	+	-	0.3	+	+	-	100
	X	+	+	+	0.3	+	+	+	100

Как видно в таблице 1.0, есть различие в производительности не COM+ страниц и страниц, использующих библиотеку COM+. Различия в производительности минимизируются, так как страница выполняет более трудоемкие задачи. Напротив, страницы, использующие приложение сервера COM+, в 2 раза медленнее, чем страницы, использующие приложения библиотеки COM+. Одно исключение – обработка задачи, требующей длительного времени инициализации, где использование организации пула резко повышает производительность. Подробно этот вопрос будет рассмотрен позже. Использование данных о времени вызова для отслеживания компонентов приложения никак не влияет на вывод страницы. Позже будет показано, как применять эти данные для проверки проблем приложения во время выполнения.

Использовать ACT полезно в процессе разработки. Проверка страницы на RPS по мере разработки помогает найти проблемы и узкие места в ходе разработки. Проблемы, обнаруженные рано в процессе разработки, решаются легче, чем когда процессы разработки завершены. Настоятельно рекомендуется максимально использовать ACT, чтобы хорошо понимать состояние приложения в каждой фазе разработки.

Доступ и ограничения

Помимо производительности, надо рассмотреть ограничения, о которых необходимо знать,  решив использовать приложения COM+. Ограничение касается только приложения сервера COM+ из-за его внепроцессной природы. Класс библиотеки сервера не имеет доступа к встроенному объекту ASP.NET. Это можно сделать, если многопоточное состояние страницы изменится на единственный поток с помощью атрибута ASPCOMPAT, но использование этого атрибута навредит производительности приложения.
Размещение сборки .Net в DLLHOST.exe, являющемся процессом, выполняющимся в каталоге системы, приводит к ограничению из-за того, что приложение ASP.NET и вызванная сборка сервера COM+, выполняющаяся в другом месте, заставляют программиста разместить сборки, содержащие общие данные (интерфейсы, перечисления, и т.д.) в GAC(глобальный кэш сборок). Помещение сборок общих данных в GAC предотвращает развертывание этих сборок в нескольких физических местах.

Использование дистанционной связи для вызова приложения сервера COM+ из приложения ASP.NET налагает еще несколько ограничений. Если ASP.NET вызывает класс COM+ и требует данные – все работает гладко, так как CLR обрабатывает дистанционную связь для регистрации класса COM+. Но если классу COM+ нужно создать обратный вызов к вызывающему приложению ASP.NET или вернуть ссылочный тип (например, DataReader), то  должно быть предпринято какое-то действие, чтобы сделать класс страницы Дистанционная связь сервером. Позже будет показано, как добиться такого поведения.
Еще одно ограничение, вытекающее из дистанционной связи, является требованием передачи параметров, поддерживающих сериализацию. Дистанционная связь сериализует объект, чтобы переместить его через канал дистанционной связи. Передача в качестве параметра объекта, не поддерживающего сериализацию, вызовет ошибку времени исполнения.

Из-за использования DCOM и дистанционной связи при каждом вызове для регистрации класса в качестве приложения сервера COM+ лучше использовать массивные, а не неряшливые вызовы. Лучше создать несколько вызовов с параметрами, а не использовать свойства для классов, вызываемых из приложений ASP.NET. Массивный вызов вместо неряшливого подходит только для классов «входной точки». Остальные классы, используемые в рамках обработки запроса, должны использовать классический объектно-ориентированный подход.