Порівняння продуктивності:. NET Remoting і Web-сервіси ASP.NET, Web Services, ASP, статті

У цій статті порівнюється відносна продуктивність 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, що викликає в свою чергу метод у віддаленому об’єкті.

Додаткова інформація по малюнку

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>

*

*