 |
 |
|||||||||||||||||||||||||||||||||||||||||||||
Тестирование CORBA и COMИсточник: «Технология Клиент-Сервер»В таблице 1 приведены результаты тестов, целью которых является сравнение скорости вызовов в COM и CORBA. Для этого были созданы объекты, содержащие пять методов. Каждая строка таблицы отражает вызов одного из методов. Первый метод имеет входной целочисленный параметр. Остальные имеют in/out параметр - массив целых (256 (1 килобайт), 512 (2 килобайта) и 1280 (5 килобайт) элементов соответственно). В первом столбце указан объем передаваемых методом данных. Учтите, что данные передаются в обе стороны. В VB-вариантах под массив каждый раз динамически занимается оперативная память. К этой таблице необходимо дать кое-какие пояснения. Дело в том, что, хотя стандарт CORBA и предусматривает сервис защиты, но на практике он не реализован большинством производителей CORBA-серверов. Так, в нашем случае в поставку VisiBroker сервис защиты тоже не входил. Его можно купить отдельно, но во время произведения тестов нам он был недоступен. COM+ же не только поддерживает защиту, которая просто включена в ОС от Microsoft, но она к тому же еще по умолчанию включена в довольно-таки суровый режим, а именно в режим Call - режим проверки безопасности при каждом вызове удаленного объекта. Из-за принятого по умолчанию режима имперсонации клиент (вернее, прокси удаленного объекта) при каждом вызове помещает в RPC-буфер данные о защите потока, из которого происходит вызов. Сервер распаковывает эти данные и проверяет условия защиты. Естественно, все это занимает некоторое время. Отнимает время и мониторинг, хотя и не так много как защита. Мониторинг в COM+ тоже включен по умолчанию. Он позволяет визуально контролировать, сколько объектов того или иного класса загружено в данный момент, находится ли некоторый объект в вызове, определять продолжительность последнего вызова и т.п. Таблица 1. Время, затраченное на осуществление 10000 статических вызовов в миллисекундах
В общем случае время, затрачиваемое на защиту и мониторинг не велико, по нашим тестам оно составляет от половины времени требующегося для вызова до сотых долей, в зависимости от количества и размера параметров. В приведенной таблице колонка "VB (1)" содержит время, требующееся на выполнение 10 000 вызовов с атрибутами защиты по умолчанию и с включенным мониторингом, а колонка "VB (2)" и все остальные содержат данные, полученные при отключенной защите и мониторинге. В CORBA есть два типа вызовов методов - динамический и статический, но, по существу, маршалинг в обоих случае осуществляется одинаково. И в первом, и во втором случае запаковкой параметров в stream занимается клиентское приложение. Разница лишь в том, что в первом запаковка скрыта в стабе, а во втором осуществляется явно. В COM код маршалинга, а значит, и код запаковки данных, содержащихся в параметрах, отделены от приложения. Более того, код маршалинга разделяется между несколькими приложениями, запущенными на одном компьютере и может иметь разную природу. Есть два типа маршалинга: proxy/stub и typelib-маршалинг. Proxy/stub-маршалинг похож на маршалинг в CORBA, с той лишь разницей, что и proxy и stab помещаются не в само приложение, а в отдельную DLL-библиотеку. Typelib-маршалинг подразумевает отсутствие кода маршалинга для конкретного интерфейса. Вместо этого используется библиотека типов. Она уже содержит некоторую информацию об интерфейсе. Если при передаче указателя на интерфейс в другой апартамент или другое приложение COM определяет, что для интерфейса отсутствует статический proxy/stub, то он читает соответствующую библиотеку типов и создает на ее базе динамический proxy/stub. Естественно, что у этих способов может оказаться разная производительность. Чтобы оценить разницу в скорости, мы приводим результаты тестов обоих вариантов. Так как typelib-маршалинг появился с Automation, а Automation ближе к VB, мы решили делать эти тесты на VB. Многие оценивают VB, исходя из представлений, полученных еще с версии 3 этого продукта. С тех пор многое изменилось. VB стал настоящим компилятором, он даже позволяет добавлять в исполняемые модули символьную отладочную информацию. Это позволяет отлаживать VB-проекты средствами профессионального низкоуровневого отладчика, входящего в состав VC++. На наших тестах VB показал очень достойный результат, а клиентское приложение, написанное на нем, даже обогнало аналогичное приложение Borland C++ Builder. Колонка "VB (2)" - это первый тест, который подлежит сравнению со статическим тестом CORBA. Он несколько проигрывает и VC-, и CORBA-аналогам, но надо учитывать, что он использует typelib-маршалинг и работает, по существу, с динамическими массивами. Преимуществами создания COM-объектов на VB являются потрясающая простота и скорость их создания. VB-пример был создан за ТРИ минуты, а клиентское приложение еще за пять. В колонках "VB (1)", "VB (2)" и "VС" использовалось статическое связывание, Пример, реализующий proxу/stab-маршалинг, написан на C++. В примерах, написанных на VB, используется динамически массив (SAFEARRAY), а в C++-примере - простой массив и MIDL-атрибуты size_is и length_is. В примере эти атрибуты заданы статически и массив, в сущности, тоже является статическим. Но если их задать через другие параметры того же метода, он станет динамическим. Колонка "VB (3)" содержит результаты вызовов методов через IDspatch (динамическое связывание). Вызовы производились из программы, написанной на C++. При этом перед циклом вызывался GetIDsOfNames, и DISPID (номер метода) помещался в локальную переменную. Вызовы внутри цикла производились по этому DISPID (без вызова GetIDsOfNames). Это кардинально отличается от того, как ведет себя VB. Он перед каждым вызовом метода удаленного объекта вызывает GetIDsOfNames, что сильно снижает производительность. Так же ведут себя оболочки для IDispatch из Borland Delphi и Borland C++ Builder, но в этих языках можно произвести вызовы вручную. Если вам нужен полиморфизм, то вместо IDispatch лучше воспользоваться полиморфными свойствами COM-интерфейсов, ведь даже оптимальный тест на VC значительно медленней своих статических аналогов, а код, работающий с IDispatch и созданный на высокоуровневых средствах, работает крайне медленно. Первый тест CORBA использует статический массив и маршалинг, аналогичный proxi/stub-маршалингу из C++-примера для COM, только код маршалинга в CORBA включается непосредственно в код сервера и клиента. Второй использует DII (Dynamic Invocation Interface) для динамического вызова методов удаленного объекта. Динамический CORBA-тест превосходит своего COM-аналога, но в CORBA используется только динамический вызов на клиенте, сервер обрабатывает вызов так, как будто он сделан статически, а COM, в виду специфики IDispatch и на серверной стороне принимает вызов динамически, преобразовывая динамический вызов в статический уже на сервере. Возможно, положение изменилось бы, если динамической была бы и серверная сторона обоих испытуемых, но это уже тема для отдельной статьи. Можно сказать, что COM и CORBA работают примерно с одинаковой скоростью. Неизвестно, как изменится обстановка, если к CORBA подключить сервис защиты. У CORBA есть некоторое преимущество при динамическом связывании, но при грамотной реализации динамических вызовов в COM разница становится очень незначительной. И CORBA, и COM ведут себя примерно одинаково при параллельном запуске нескольких копий тестовой клиентской программы. Но все это относится к сетевым вызовам. На локальном компьютере COM значительно, в два-три раза опережал CORBA. По-видимому, дают себя знать настольные корни COM и OLE. Что же касается скорости, то она очень высока и приближается к показателям утилиты Ping. Тесты производились на сети 10-МВ Ethernet, работающей под управлением Windows 2000 Server (SP1). В качестве клиентских и серверных компьютеров применялись ПК на базе Intel PII/PIII от 233 до 677 МГц, работающие под управлением Windows 2000 Professional (SP1). Загрузка процессора сервера (PIII 677) в обоих случаях составляля около 20-30 процентов. Мы пробовали разрывать сеть как перед, так и во время вызовов. При этом оба пациента чувствовали себя нормально и продолжали работу после восстановления соединения. Если же время разрыва превышало время таймаута, то и COM, и CORBA выдавали сообщения об ошибке. Сообщения COM были более осмысленными (CORBA-приложение на любую ошибку выдавало общение "C++ Exception"), но это проблемы умолчальной реализации обработки ошибок в C++ Builder. Подытоживая скажу, что по поведению приложения, написанные с использованием COM, очень трудно отличить от приложений, написанных на CORBA. |
||||||||||||||||||||||||||||||||||||||||||||||
 |
 |
