Порівняння продуктивності:. 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
(ID клієнта) і параметр, що визначає кількість рядків
клієнта, які потрібно прочитати. Читаються верхні 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: пропускна здатність і час
очікування

Примітки

Як показано на рис. 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): пропускна здатність і час
очікування

Примітки

Як показано на рис. 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.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*