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

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

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

Сравнение производительности: .NET Remoting и Web-сервисы ASP.NET

В этой статье сравнивается относительная производительность Web-сервисов Microsoft ASP.NET, имеющих самый высокий уровень возможности взаимодействия с полной поддержкой WSDL и SOAP по HTTP, и Microsoft .NET Remoting, разработанного для точности систем общеязыковой среды выполнения и поддерживающего дополнительные форматы данных и каналы взаимодействия.

Введение

В Web-сервисах ASP.NET и .NET Remoting содержится полный набор проектных решений для общего для всех процессов взаимодействия в распределенных приложениях. В общем, Web-сервисы ASP.NET предлагают самый высокий уровень возможностей взаимодействия с полной поддержкой WSDL и SOAP по HTTP, а .NET Remoting разработан для систем общеязыковой среды выполнения (CLR) и поддерживает дополнительные форматы данных и каналы взаимодействия. Дополнительная информация и код примера BDADotnet.msi содержатся в разделе Web-сервисы ASP.NET или .NET Remoting: что выбрать?.

В этой статье представлено сравнение относительной производительности этих методов.

Web-сервисы ASP.NET

ASP.NET предлагает инфраструктуру, которая использует Microsoft® IIS и поддерживает такие промышленные стандарты, как SOAP, XML и WSDL. Хотя .NET Remoting поддерживает хостинг IIS и стандарт SOAP по HTTP, ASP.NET предлагает самый высокий уровень возможности взаимодействия SOAP, в частности поддержку SOAP Section 5 и документа/литерала.

ASP.NET позволяет расширить такие возможности IIS, как безопасность и регистрация. Устойчивость хостинга IIS состоит также в повторном порождении Aspnet_wp.exe в случае его прерывания. Кроме того, Web-сервисы ASP.NET создаются и используются намного проще, чем предоставленные с помощью .NET Remoting службы, вследствие упрощенной конфигурации сервера и клиента.

Более подробная информация содержится в разделе Построение XML Web сервисов с помощью ASP.NET в Руководстве разработчика .NET Framework.

.NET Remoting

.NET Remoting более универсален и расширяем с точки зрения взаимодействия между объектами, которые используют различные транспортные протоколы и форматы сериализации. Протоколы TCP, HTTP и пользовательские протоколы поддерживаются как бинарный, SOAP и пользовательский форматы. Поддерживается создание нескольких объектов и жизненные режимы, такие как Singleton, SingleCall и Client-Activated (активизируемый клиентом). Для ремоутинга требуется хост-процесс, такой как IIS, служба Microsoft® Windows или исполняемый файл, написанный в .NET.

Объект .NET Remoting, использующий форматтер SOAP, может быть предоставлен в виде XML Web сервиса при хостинге в IIS с ASP.NET. Поскольку полезная нагрузка кодируется в SOAP по HTTP, любой клиент, поддерживающий формат кодирования SOAP, может обращаться к объектам через Интернет. Другим преимуществом использования протокола HTTP является его свободное проникновение через большинство брандмауэров. Канал TCP и бинарный форматтер могут использоваться в среде интранета, в которой сервер и клиент работают под управлением .NET Framework. Этот подход оптимизирован на производительность, поскольку неструктурированные сокеты используются для передачи данных по сети с помощью пользовательского протокола, более эффективного по сравнению с HTTP. Хотя при этом подходе достигается превосходная производительность в закрытой среде, он не может использоваться в межплатформенных сценариях, в которых клиент не работает под управлением .NET Framework.

Хостинг IIS обеспечивает безопасное взаимодействие для защиты канала передачи данных при помощи протокола SSL; кроме того, аутентификация и авторизация на уровне IIS и ASP.NET могут быть усилены. Канал TCP, как и канал HTTP, не поддерживает безопасную сокетную передачу без хостинга IIS, поэтому данные передаются открытым текстом. При использовании каналов TCP или HTTP с хостингом на процессах, отличных от IIS, необходима реализация собственных средств защиты.

Более подробная информация содержится в разделе .NET Remoting: обзор в Руководстве разработчика .NET Framework.

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

Производительность межпроцессного взаимодействия в распределенных приложениях зависит от ряда факторов.

Каналы, в том числе TCP и HTTP, используемые для передачи сообщений между приложениями через границы ремоутинга, влекут за собой издержки различной величины. Сокеты TCP более эффективны, чем сокеты HTTP.

Другим фактором является сериализация. Сериализованный поток может быть закодирован при помощи XML, SOAP или компактного бинарного представления. Web-сервисы ASP.NET используют класс XMLSerializer, позволяющий сериализовать объект в поток XML, который является чрезвычайно быстрым, но влечет за собой некоторые издержки на синтаксический анализ XML. Для сериализации объекта в бинарный формат и формат SOAP при ремоутинге используются соответственно BinaryFormatter и SOAPFormatter. Поскольку эти форматтеры используют отражение (Reflection), для ссылочных объектов их производительность высока, однако она может снижаться для типов значений, которые для прохода через API Reflection необходимо упаковывать и распаковывать. SOAPFormatter имеет некоторые дополнительные издержки на генерацию закодированных сообщений SOAP.

Используемые в этом сравнении тесты основаны на общих бизнес-сценариях, обращающихся к данным клиента и заказа. Для того чтобы тест был максимально реалистичным, в базе данных содержатся более 100 000 строк учетных записей клиентов. Данные находятся в базе данных Microsoft® SQL Server 2000, для подключения к SQL Server используется провайдер данных SQL Server .NET.

В сравнении производительности используются следующие методы.

GetOrderStatus

С помощью метода GetOrderStatus принимается OrderId (Идентификатор заказа) и возвращается целое число, представляющее статус заказа.

GetCustomers

С помощью метода GetCustomers принимается CustomerId (Идентификатор клиента) и параметр, определяющий количество строк клиента, которые требуется прочитать. Читаются верхние n строк, CustomerId которых превышает CustomerId, отправленный методу Web-сервиса.

Тестирование выполнялось путем пролистывания небольшого набора строк клиента, имеющего страницы различных размеров: 20 и 50.

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

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

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

Как было отмечено ранее, существуют два типа активации объектов ремоутинга: активация сервером и активация клиентом. Время жизни активизируемого сервером объекта управляется непосредственно сервером. Существуют два режима активации для активизируемых сервером объектов: Singleton и SingleCall. Для Singleton-типов одновременно выполняется только один экземпляр. Все клиентские запросы обслуживаются единственным экземпляром, поэтому этот режим активации позволяет поддерживать состояние между клиентами. При использовании SingleCall-типов отдельным экземпляром обслуживается каждый клиентский запрос. Активизируемые клиентом объекты создаются на сервере, однако время жизни этих объектов управляется доменом вызывающего приложения. Этот режим позволяет поддерживать состояние между запросами того же самого клиента. ASP.NET поддерживает только SingleCall; другими словами, каждый запрос обслуживается новым экземпляром, и если у службы должно быть какое-либо состояние, то она должна управляться при помощи cookies, SessionState или пользовательских заголовков SOAP. Во всех тестах, проведенных для сравнения различных вариантов ремоутинга, для более точного сравнения применялся режим SingleCall.

Хотя Web-сервисами ASP.NET поддерживаются варианты SOAP, HTTP-GET и HTTP-POST, для непротиворечивости в тестах использовался только вариант SOAP.

Согласно HTTP/1.1, у любого клиента может быть не более двух подключений к одному серверу. Поэтому при использовании протокола HTTP для взаимодействия (как в ремоутинге с каналом HTTP и ASP.NET) в любое время к заданному серверу открываются по умолчанию только 2 подключения, а при использовании канала TCP число открывающихся подключений соответствует числу потоков, отправляющих запросы на сервер. Для моделирования нескольких клиентов, посылающих одновременные запросы удаленному объекту, в файле конфигурации клиента число подключений к серверу по умолчанию 2 было изменено на 100 для одного клиента.

При выполнении ремоутинга с каналом HTTP следует использовать атрибут clientConnectionLimit в .config-файле клиента:

<system.runtime.remoting>
   <application>
         …
    <channels>
      <channel ref="http" clientConnectionLimit="100">
         <clientProviders>
            <formatter ref="soap" />
         </clientProviders>
      </channel>
   </channels>
      </application>
 </system.runtime.remoting>

Для Web-сервисов ASP.NET следует использовать атрибут maxConnection в <system.net> в.config-файле клиента:

    <system.net>
        <connectionManagement>
            <add address="*"
                 maxconnection="100"
            />
        </connectionManagement>
    </system.net>

Поскольку число HTTP-подключений к "локальному хосту" (когда клиент и сервер находятся на одном компьютере) не ограничено, файл конфигурации изменять не требуется.

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

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

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

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

Компьютер/CPU

Кол-во CPU

Память

Жесткий диск

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

1

Compaq Proliant 1130 МГц

2

1 Гбайт

16,9 Гбайт

Windows 2000 Advance Server SP 2

Application Center Test

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

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

Компьютер/CPU

Кол-во CPU

Память

Жесткий диск

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

3

Compaq Proliant 1000 МГц

2

1 Гбайт

16,9 Гбайт

Windows 2000 Advance Server SP 2

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

Таблица 3. Конфигурация сервера приложений

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

Компьютер/CPU

Кол-во CPU

Память

Жесткий диск

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

1

Compaq Proliant 1126 МГц

2

1 Гбайт

16,9 Гбайт

Windows 2000 Advance Server SP 2

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

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

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

Компьютер/CPU

Кол-во CPU

Память

Жесткий диск

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

1

Compaq Proliant 700 МГц

4

4 Гбайт

18 Гбайт

Windows 2000 Advance Server SP 2

SQL Server Enterprise Edition SP 2

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

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

Межкомпьютерный сценарий

В межкомпьютерном сценарии клиент и объект ремоутинга находятся на различных компьютерах. Запросы отсылаются клиентами ACT Web-странице ASPX, вызывающей в свою очередь метод в удаленном объекте.

 

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

ACT Clients = клиенты ACT

Remouting Client (ASPX Web page) = клиент ремоутинга (Web-страница ASPX)

Host process = хост-процесс

Remote Object = удаленный объект

Database = база данных

Рис. 1. Межкомпьютерный сценарий

Как показано на рис. 1, тестирование выполнялось в рамках Web-сервера; кроме того, имели место доступ к базе данных и передача по сети на внешние компьютеры, что повлекло за собой дополнительные издержки. Поэтому показатели производительности, сгенерированные для пропускной способности и времени ожидания, являются лишь основанием для сравнения этих технологий. Эти показатели не представляют собой абсолютную производительность. Точная пропускная способность и время ожидания для распределенных систем, построенных с помощью Web-сервисов ASP.NET и .NET Remoting, зависят от используемой архитектуры.

GetOrderStatus

Здесь сравнивается поведение различных методов при получении отдельного значения из базы данных.

 

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

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

Single Value = отдельное значение

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

Рис. 2. GetOrderStatus: пропускная способность и время ожидания

Примечания

  • ASMX – это Web-сервис ASP.NET.
  • Все остальные варианты представляют различные конфигурации .NET Remoting.
  • Во всех остальных вариантах в имени содержится используемый хост, транспортный протокол и формат, например, Host_TransaportProtocol_Format.
  • 'WS' – это сокращение для службы Windows, являющейся хостом типа ремоутинга.
  • IIS_HTTP_Binary/SOAP имеют хостинг в IIS с ASP.NET.

Как показано на рис. 2, производительность варианта WS_TCP_Binary, в конфигурации объекта которой используется канал TCP, бинарный форматтер и хост, являющийся службой Windows, выше, чем в других методах распределения. Причина этого состоит в том, что в этом подходе двоичные данные передаются через неструктурированные сокеты TCP, более эффективные, чем HTTP, и там издержки на обработку меньше, поскольку данные не требуется кодировать и декодировать. Разрыв в производительности между WS_TCP_Binary и самым медленным подходом составляет приблизительно 60%.

Хотя в подходах WS_HTTP_Binary и IIS_HTTP_Binary полезная бинарная нагрузка одинакова, в последнем подходе имеется дополнительная передача процесса из IIS (Inetinfo.exe) в Aspnet_wp.exe. Этим же объясняется различие в производительности между IIS_HTTP_SOAP и WS_HTTP_SOAP.

Производительность в подходах WS_HTTP_Binary и WS_TCP_SOAP практически одинакова. Несмотря на дополнительные издержки на синтаксический анализ HTTP в первом подходе и на синтаксический анализ SOAP в последнем, издержки на синтаксический анализ HTTP и SOAP в этом случае примерно равны.

Производительность Web-сервиса ASP.NET выше, чем у IIS_HTTP_SOAP и WS_HTTP_SOAP, поскольку сериализация ASP.NET XML эффективнее сериализации .NET Remoting SOAP. Кроме того, как показано на рис. 2, производительность Web-сервиса ASP.NET и IIS_HTTP_Binary также примерно одинакова.

GetCustomers с использованием пользовательского класса

В этом случае удаленный метод позволяет получить записи клиента из базы данных, отправить их в DataReader, заполнить объект Customers на основе данных в DataReader и возвратить объект Customers. Для тестирования использовался набор результатов, состоящий из 20 и 50 строк и позволяющий определить влияние объема возвращенных данных на производительность.

 

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

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

Customers = клиенты

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

Рис. 3. GetCustomers (n=20): пропускная способность и время ожидания

Относительная производительность остальных вариантов значительно превосходит WS_TCP_Binary, поскольку издержки на маршалинг объекта Customers становятся здесь существенным фактором. В этом тесте сравнивается сериализация объекта Customers, состоящего из 20 клиентов, с сериализацией целого числа в предыдущем тесте.

Незначительное снижение производительности IIS_HTTP_Binary по сравнению с WS_HTTP_Binary обусловлено дополнительной передачей процесса в описанном выше случае. Обратите внимание, что производительность Web-сервиса ASP.NET и IIS_HTTP_Binary примерно одинакова.

Производительность WS_TCP_SOAP значительно снизилась при увеличении объема данных и теперь сопоставима с WS_HTTP_SOAP и IIS_HTTP_SOAP. В данном случае причиной этого является то, что большая часть времени тратится на сериализацию данных, которая становится существенным фактором, влияющим на производительность.

 

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

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

Customers = клиенты

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

Рис. 4. GetCustomers (n=50): пропускная способность и время ожидания

Примечания

  • SOAPExtension используется в ASMX_SOAPExtn для решения проблемы буферизации с ASP.NET.

Как показано на рис. 4, при увеличении размера данных постепенно уменьшается различие в производительности между WS_TCP_Binary и другими вариантами.

Обратите внимание, что Web-сервис ASP.NET отстает по производительности от IIS_HTTP_Binary. Причиной этого является проблема буферизации сообщений большого размера в ASP.NET, которая была исправлена в следующей версии. После решения проблемы буферизации вариант ASMX не будет отставать по производительности от IIS_HTTP_Binary, как это было в предыдущих тестах.

Проблема буферизации была решена путем реализации SOAPExtension, обеспечивающей некоторую буферизацию между XmlSerializer и сетью. Как показано на диаграмме, производительность варианта ASMX_SOAPExtn (использующего реализованный SOAPExtension) значительно выше варианта ASMX и немного ниже IIS_HTTP_Binary.

Производительность WS_TCP_SOAP, WS_HTTP_SOAP и IIS_HTTP_SOAP примерно одинакова, при этом производительность WS_TCP_SOAP немного выше.

GetCustomers с использованием DataSet

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

 

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

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

Customers = клиенты

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

Рис. 5. GetCustomers (n=20): пропускная способность и время ожидания

Относительная производительность между WS_TCP_Binary и другими подходами уменьшилась, поскольку издержки на маршалинг набора данных становятся здесь существенным фактором.

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

Обратите внимание, что производительность Web-сервиса ASP.NET значительно снизилась и достигла уровня производительности подходов WS_TCP_SOAP, WS_HTTP_SOAP и IIS_HTTP_SOAP. Это снижение производительности произошло из-за двух известных проблем в ASP.NET, которые будут исправлены в следующих версиях. Проблема буферизации была рассмотрена ранее; вторая проблема связана с сериализацией DataSet в ASP.NET. После решения этих проблем Web-сервис ASP.NET будет сопоставим по производительности с IIS_HTTP_Binary. Как показано на рис. 5, решение проблемы буферизации сообщений большого размера позволило ASMX_SOAPExtn в значительной степени превзойти ASMX, однако производительность сохраняется на низком уровне из-за проблемы сериализации DataSet.

 

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

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

Customers = клиенты

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

Рис. 6. GetCustomers (n=50): пропускная способность и время ожидания

Относительная производительность между WS_TCP_Binary и другими подходами существенно снизилась из-за увеличения объема данных по сравнению с предыдущим тестом. Производительность WS_HTTP_SOAP и IIS_HTTP_SOAP практически одинакова.

Web-сервис ASP.NET все больше отстает по производительности по причине известных проблем, рассмотренных ранее. Обратите внимание, что решение только проблемы буферизации позволило ASMX_SOAPExtn в значительной степени превзойти ASMX.

Заключение

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

Хотя межпроцессное взаимодействие может быть реализовано как в инфраструктуре .NET Remoting, так и в Web-сервисах ASP.NET, каждый подход спроектирован с определенным уровнем экспертизы и гибкости и позволяет извлечь выгоду различным потенциальным клиентам. Если для приложения необходима возможность взаимодействия с другими платформами или операционными системами, рекомендуется использовать более гибкие Web-сервисы ASP.NET, поддерживающие SOAP Section 5 и документ/литерал. С другой стороны, если требуется более богатая объектно-ориентированная модель программирования, рекомендуется использовать .NET Remoting. Более подробная информация содержится в разделе Web-сервисы ASP.NET или .NET Remoting: что выбрать?. Если в сценарии производительность является главным требованием, а управление безопасностью и жизненным циклом процесса второстепенно, лучшим выбором является.NET Remoting TCP/Binary; однако не следует забывать об увеличении производительности реализаций с хостингом на IIS путем добавления в систему нескольких компьютеров, что невозможно при использовании реализации .NET Remoting TCP/Binary.


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


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

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

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

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