UBS | Публикации о технологиях веб-сервисов

Публикации о технологиях веб-сервисов

Использование SOAP в высокопроизводительных бизнес-приложениях: торговые системы реального времени

Christopher Kohlhoff, Tenermerx Pty Ltd, Австралия
Robert Steele, Сиднейский технологический университет, Австралия

© Christopher Kohlhoff, Robert Steele, 2004, Оригинальный текст на английском языке
© UBS 2004, Перевод и адаптация на русский язык

На русском языке публикуется впервые с разрешения авторов

Аннотация

Веб-сервисы, с их акцентом на открытые стандарты и гибкость использования, могут иметь преимущества по сравнению с существующими методами интеграции финансовых систем. Однако, веб-сервисы должны прежде всего удовлетворять определенным техническим требованиям, включая производительность, безопасность и отказоустойчивость. Данная работа делает попытку экспериментальной оценки производительности протокола SOAP на примере его применения в реальном бизнес-приложении. С целью определения применимости SOAP для высокопроизводительных финансовых систем, полученные результаты сравнивались с результатами аналогичных экспериментов для существующих и широко используемых в настоящее время протоколов. Результаты данного исследования показали, что хотя SOAP и имеет относительно низкую производительность по сравнению с этими протоколами, разница в производительности меньше, нежели при использовании SOAP для решения научных вычислительных задач. Более того, мы обнаружили, что в реальных бизнес-приложениях, в случае использования текстовых форматов сообщений, можно достичь производительности, сопоставимой с производительностью приложений, использующих двоичные форматы. Мы также установили, что применение в SOAP текстового формата сообщений не является достаточным объяснением его неэффективности. Это дает основания полагать, что дальнейшие разработки помогут сделать SOAP жизнеспособным форматом передачи данных для использования в высокопроизводительных бизнес-приложениях.

<...>

Введение

На протяжении последнего десятилетия быстрое развитие компьютерных технологий вызвало впечатляющие изменения в финансовом секторе. Необходимость обеспечения онлайновых сервисов, таких как, например, коллективное осуществление торговых операций в реальном времени, вызвало переход на новые бизнес-модели, такие как глобализация рынков, круглосуточное осуществление торговых операций и прямая обработка данных [21]. Огромный рост числа финансовых сетей вызвал увеличение конкуренции и ускорение разработки усовершенствованных автоматизированных торговых систем [7].

Чтобы конкурировать эффективно, существующие организации вынуждены формировать альянсы и разрабатывать единые укрупненные сервисы. Однако, b2b-интеграция не является новой концепцией для финансовых рынков - в финансовом секторе индустриальные стандарты протоколов используются для интеграции распределенных приложений с 70-х годов прошлого века [26].

В настоящее время веб-сервисы развиваются как технология систематичной и гибкой интеграции приложений [5]. Веб-сервисы отличаются от большинства существующих ныне методов интеграции приложений тем, что используют хорошо устоявшиеся, проверенные веб-протоколы и открытые XML-стандарты.

Применение технологий веб-сервисов может быть выгодно для финансовых систем. Существующая практика интеграции приложений характеризуется наличием нескольких конкурирующих между собой индустриальных стандартов и множества протоколов, авторские права на которые принадлежат различным вендорам. В этой ситуации веб-сервисы, с их акцентом на открытые стандарты, могут способствовать достижению согласия между основными игроками рынка. Использование XML и его формального языка описания XML Schema, путем устранения некоторых неопределенностей в их применении наряду с поддержкой автоматической валидации сообщений, может помочь сделать использование интеграционных протоколов более распространенным. Наконец, расширяемость веб-сервисов и XML способствует развитию интеграционных механизмов, т. к. рынку постоянно требуется все новая функциональность финансовых систем, при нежелательности увеличения количества применяемых для ее реализации протоколов.

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

Существующие исследования производительности SOAP были посвящены применению SOAP в областях, связанных с решением научных вычислительных задач (например, таких как распределенные вычисления (grid computing)), где основной задачей SOAP-сообщений была передача числовых данных. Учитывая это, наибольшие затраты и основные недостатки XML-сообщений связывались с кодированием/декодированием значений с плавающей запятой [4].

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

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

В данном исследовании особое внимание было также уделено изучению ограничений производительности, характерных для различных форматов передачи данных. И SOAP и FIX используют текстовый формат передачи данных; в силу этого представляется уместным основанное на данных проведенных исследований предположение о том, что оба эти протокола подвержены одним и тем же факторам, ограничивающимих производительность. По этой причине, для оценки затрат, обусловленных текстовым форматом передачи данных, в перечень сравниваемых протоколов был включен также двоичный формат передачи данных CDR.

Исследование показало, что по сравнению с двоичным протоколом передачи данных CDR для бизнес-приложений SOAP демонстрирует, несомненно, довольно низкую производительность. Размер SOAP-сообщений превышает размер эквивалентных CDR-сообщений в 2-4 раза. Время, необходимое сообщению для преодоления пути от источника до приемника (пункта назначения), при передаче по локальным сетям существенно больше, при этом кодирование сообщения является более затратным в 8-10 раз, а декодирование - в 5 раз. Данные результаты схожи с результатами более ранних исследований, хотя и показывают несколько меньшие отличия между характеристиками SOAP и CDR нежели при передаче числовых данных.

По сравнению с FIX, SOAP также показывает меньшую производительность. SOAP-сообщения в 3,5-4,5 раза больше аналогичных FIX-сообщений, время, необходимое сообщению для преодоления пути от источника до приемника, больше в 2-3 раза, а увеличение затрат на кодирование/декодирование доходит до примерно 9 раз.

Учитывая, что FIX, как и SOAP, имеет текстовый формат передачи данных, тот факт, что производительность FIX сравнима с производительностью CDR кажется неожиданным. Отсюда можно заключить, что низкая производительность SOAP, при его использовании в реальном бизнес-приложении, не может быть вполне объяснена недостатками текстового формата передачи данных по сравнению с двоичным. Это позволяет предположить, что улучшение характеристик производительности кодировщиков/декодировщиков SOAP может сделать его использование в высокопроизводительных бизнес-приложениях обоснованным.

Предварительные сведения

Программные системы, используемые финансовыми рынками, можно классифицировать в соответствии с их положением в торговом жизненном цикле [21]:

  • Предпродажные сервисы. Осуществляют доставку актуальных и исторических данных рынка, анализ этих данных, а также маршрутизацию поручений на осуществление транзакций.
  • Торговые. Обеспечивают исполнение собственно торговой операции на торговой площадке, такой как, например, Австралийская Фондовая Биржа (Australian Stock Exchange, ASX).
  • Послепродажные сервисы. Осуществляют операции, выполняемые перед завершением торговой сделки, такие как надзор за исполнением сделки, проверка на соответствие условиям сделки или управление рисками.
  • Оплата. Осуществляют завершение торговой сделки - перечисление денежных средств покупателя продавцу.
  • Регистрация. Осуществляют передачу прав собственности на ценные бумаги от продавца покупателю.



Рис. 1: Интеграция торговых систем реального времени

Данная работа сосредоточена на предпродажной части торгового жизненного цикла, и в особенности - на интеграционных потребностях торговых систем реального времени. Интеграция торговых систем реального времени, как правило, затрагивает потоки реальных данных рынка наряду с потоками поручений на покупку и продажу, как показано на рис. 1. Учитывая потенциально большие объемы данных и необходимость их своевременной доставки, при интеграции торговых систем реального времени, исходя из опыта авторов, требования к производительности таких систем наиболее высоки.

Протокол FIX

Протокол Financial Information eXchange (протокол обмена финансовой информацией, FIX) [10] является стандартом обмена сообщениями, разработанным специально для осуществления в реальном времени транзакций электронного обмена ценными бумагами.



Рис. 2: Пример фрагмента сообщения протокола FIX

Сообщения, сформированные согласно протоколу FIX (далее для простоты - FIX-сообщения - прим. перев.), являются текстовыми и состоят из парных тегов, отделенных специальным символом (SOH, имеющим ASCII-код 0x01) , как показано на рис. 2. Теги представляют собой короткие строки цифр, а типы значений включают строки, целые значения, значения с плавающей запятой, даты и обычные двоичные данные. Хотя содержание сообщения определяется приложением, схема кодированного сообщения является плоской с нестрогим следованием полей. Спецификация протокола в терминах привычного языка описывает теги протокола, соответствующий им бизнес-смысл и соответствующую структуру сообщения.

Последние версии протокола FIX ввели в обиход формат сообщений FIXML, основанный на XML [9]. Это позволяет FIX-сообщениям иметь более сложную структуру, позволяющую автоматическую валидацию и уменьшающую характерную для тегов неопределенность. Применение XML в отношении протокола FIX также позволяет разрабатывать новую функциональность без нежелательного увеличения количества применяемых для ее реализации версий протокола.

Поскольку данная работа оценивает пригодность SOAP для финансовых систем, протокол FIX будет использоваться как база для сопоставления результатов проводимых экспериментов. FIX был выбран нами для этой цели среди других индустриальных протоколов в силу его широкого применения. Проводившийся в 1999 году опрос участников рынка [12] показал, что 82% опрошенных брокеров используют FIX. Многие организации также используют различные варианты стандартного протокола либо описания сообщений, схожие с протоколом FIX (например, SEATS Open Interface ASX [1]).

Работы, также посвященные теме оценке производительности SOAP и XML

Несколько более ранних исследований уже были посвящены оценке производительности SOAP и XML [6, 13, 3]. Все эти исследования показали, что и SOAP и XML имеют меньшую производительность по сравнению с двоичными протоколами.

Работа [6] содержит экспериментальное исследование производительности различных реализаций SOAP в сравнении с другими протоколами, такими как Java RMI и CORBA/IIOP. Вывод, который следует из результатов этого исследования - SOAP имеет меньшую производительность, хотя в отдельных случаях наиболее "медленных" SOAP-систем (т.е. систем с невысокой производительностью - прим. перев.) это может объясняться слабой реализацией системы.

В работе [13] проводилась оценка производительности SOAP для решения научных задач, требующих высокопроизводительных вычислений. Для SOAP и Java RMI проводились эксперименты по передаче больших массивов значений типа данных double (18-значные числа с плавающей запятой) и затем их результаты сравнивались. Сравнение результатов показало, что SOAP является протоколом с существенно меньшей производительностью, чем Java RMI - обычно производительность была ниже примерно в 10 раз. Результаты экспериментов также показали, что XML-сообщения SOAP в действительности не подходят для передачи большого количества данных, однако, в силу гибкости и доступности формата, SOAP может быть полезен как часть мультипротокольной системы (т. е. системы, использующей несколько коммуникационных протоколов - прим. перев.), использующей SOAP в качестве лингва-франка (лингвистический термин, здесь обозначающий базовое единое средство коммуникации - прим. перев.).

Работа [3] содержит результаты экспериментов, в ходе которых сравнивались кодирование/ декодирование и производительность сети при использовании различных форматов сообщений, в том числе XML. Результаты этих экспериментов показали, что затраты на маршаллинг (расположение в нужном порядке, сортировку по необходимому критерию - прим. перев.) и передачу сообщений для XML поразительно высоки по сравнению с более привычными подходами, а также то, что кодирование/декодирование XML-сообщений происходит на 2-4 порядка величины медленнее нежели кодирование/декодирование сообщений при использовании CORBA/IIOP и схожих с ним двоичных форматов. Данные результаты дали основания для выводов, говорящих о том, что XML является неподходящим форматом передачи данных для высокопроизводительных систем, так как производительность любых систем во многом определяется используемым форматом передачи данных.

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

Качество реализации

Проектные и технические решения, принимаемые производителями инфраструктурных приложений на базе SOAP в ходе реализации систем, имеют значительное влияние на производительность систем. Факторы, оказывающие наибольшее влияние, следующие:

  • Метод XML-парсинга. Различные модели XML-парсинга имеют различные возможности в отношении обеспечения эффективного использования памяти, скорости вычислений и простоты использования. Среди широко распространенных моделей XML-парсинга т. н. pull parsing обеспечивает наибольшую производительность наряду с высокой эффективностью использования памяти [14]. Однако, работа [4] показала, что ориентированные на определенные схемы XML-документов парсеры могут существенно увеличить производительность по сравнению с XML-парсерами, использующие общие модели парсинга. Это особенно характерно для случаев передачи больших массивов данных.
  • Длина сообщения. В случае использования SOAP совместно с HTTP/1.0-привязкой, длина сообщения должна указываться в заголовочном поле "Content-Length" [2]. Присвоение определенного значения полю HTTP "Content-Length" в случае динамических данных является достаточно трудной задачей, т.к. сообщение помещается в буфер для определения его длины и не отправляется до тех пор, пока его кодирование не будет полностью закончено [6].
  • Затраты на установление соединения. HTTP/1.0 [2] требует установления нового соединения для выполнения каждой операции. Установление нового соединения для осуществления каждой транзакции может иметь негативное влияние на производительность в силу существования определенных особенностей протокола TCP [23], таких как трехшаговое подтверждение установления соединения (обычно, в этой связи упоминается протокол Challenge Handshake Authentication Protocol (CHAP), который описывает процесс установления соединения между сервером и клиентской рабочей станцией с помощью случайным образом сгенерированного однократно используемого числового значения и ID, на основе которых по алгоритму MD5 вычисляется хэш-код, сравниваемый при установлении соединения сервером и клиентской рабочей станцией - прим. перев.) [24] и алгоритм slow start (алгоритм, используемый для управления скоростью передачи данных на стороне сервера при установлении TCP-соединения - скорость передачи данных сервером соотносится со скоростью поступления подтверждений клиентской рабочей станции о получении предыдущей порции данных, часто упоминается также в связи с термином sender-based flow control - прим. перев.) [16]. Если рассматривать производительность HTTP/1.0 в сети Интернет, то можно видеть, что при установлении соединения возможно избавиться по меньшей мере от четверти транзакции [17]. Протокол HTTP/1.1 имеет функцию поддержки установленного соединения, которая позволяет клиенту осуществлять несколько операций в рамках одного соединения [8].
  • Конвейеризация. В HTTP/1.1 появилась поддержка конвейеризации [8] - возможности отправки нескольких запросов в рамках одного соединения перед переходом в состояние ожидания отклика. Это позволяет более эффективно использовать соединение. В качестве альтернативы конвейеризации, в HTTP/1.0 существует возможность параллельного открытия, используя свойство многопоточности, нескольких соединений для осуществления в рамках каждого из них одной транзакции. В работе [19] было показано, что при использовании буферированной конвейеризации HTTP/1.1 необходимыми остаются менее 10% TCP-пакетов, используемых HTTP/1.0. При этом выполнение транзакции осуществляется за меньший интервал времени. Однако, использование HTTP/1.1 без конвейеризации при установлении множественных соединений влечет за собой увеличение времени осуществления транзакции. Это говорит о том, что применение свойства поддержки установленного соединения недостаточно для повышения быстродействия.
  • Нежелательные опции TCP. Работа [6] показала, что некоторые реализации SOAP обладают существенно меньшей производительностью в силу совместного действия алгоритма Нэгла (Nagle algorithm, алгоритм, применяемый для повышения эффективности передачи данных, заключающийся в автоматическом объединении небольших пакетов в блоки с их последующей передачей, что уменьшает общее число передаваемых пакетов - прим. перев.) и алгоритма запаздывающего подтверждения TCP операционной системы клиентской рабочей станции и сервера [24]. Понятно, что данная проблема не является характерной ни для SOAP ни для HTTP.

Привязка к сетевому протоколу

Протокол FIX определяет сессию как "двунаправленный упорядоченный поток сообщений между двумя сторонами" [10]. Данное определение, как видно, не предполагает использование терминологии "запрос-отклик". В то же время, когда мы рассматриваем возможность применения SOAP для построения торговой системы реального времени, мы можем предпочесть именно диалоговый стиль обмена сообщениями, а не RPC-стиль. Поскольку HTTP является протоколом, функционирование которого описывается в терминах "запрос-отклик" [8], с четко определенными ролями клиентской рабочей станции и сервера, он может оказаться неподходящим для использования в диалоговом обмене сообщениями.

К счастью, протокол SOAP не определяет какую-либо специальную сетевую привязку, поэтому повышению производительности может способствовать использование SOAP совместно с другим сетевым протоколом. И в этом случае мы с очевидностью видим, что недостатки, связанные с использованием HTTP, не являются характерными для SOAP.

Ограничения, характерные для SOAP

Открытые технологии метаданных, такие как XML, могут быть весьма выгодны благодаря удобству их использования, однако для успешного применения этих технологий также требуется, чтобы их использование необоснованно не снижало производительность [28].

XML крайне надежен по отношению к изменениям формата входящего сообщения [3]. Однако, использование XML может негативно влиять на производительность SOAP в следующих областях:

  • Скорость кодирования/декодирования. Перевод данных из двоичного формата в ASCII и обратно порождает наибольшие потери в производительности XML [3]. Это особенно касается числовых данных с плавающей запятой, которые вызывают наибольшие потери при кодировании/декодировании XML [4]. Использование текстового протокола также не позволяет проводить оптимизацию приложения в случае взаимодействия гомогенных систем, доступную при использовании двоичных протоколов [3].
  • Размер сообщения. Для XML увеличение размера сообщения в 6-8 раз по сравнению с аналогичным сообщением в двоичном формате не явлется чем-то необычным [3]. В работе [4] указывается на величину увеличения размера XML-сообщения в 4-10 раз, а работа [13] показала увеличение размера SOAP-сообщения до 10 раз по сравнению с эквивалентным сообщением в двоичном формате. Существенно больший размер сообщений может вызывать более высокие затраты на их передачу, а также увеличение времени, необходимого сообщению для покрытия пути от источника до приемника.
Одним из возможных путей преодоления этих недостатков производительности является использование двоичного представления XML [28, 11, 25, 18].

Модель эксперимента

Протокол FIX, как XML и SOAP, имеет текстовый формат представления [10]. Это означает, что FIX присущи те же недостатки при кодировании/декодировании числовых данных. Подобным же образом, FIX-сообщения могут быть больше их аналогов в двоичном представлении, хотя это увеличение и меньше чем для XML, поскольку FIX имеет компактный теговый формат.

Фокус нашего исследования направлен на освещение проблем производительности, характерных для форматов SOAP и FIX. Имея это ввиду, эксперименты были построены и выполнены так, чтобы исключить влияние на их результаты факторов, касающихся качества реализации системы, а также аспектов использования сетевого протокола. Это удалось сделать благодаря отправке сообщений в разных форматах через "голые" TCP-сокеты (raw TCP sockets) с использованием в каждом конкретном случае соответствующей сетевой программной модели. HTTP-привязка SOAP не использовалась. Более того, начало передачи данных было исключено из результатов с целью устранения влияния алгоритма slow start [16]. Для устранения влияния алгоритма Нэгла [24] эксперименты проводились с задействованным параметром TCP_NODELAY.

Чтобы было легче идентифицировать проблемы производительности, связанные с текстовым форматом представления данных, результаты сравнивались с аналогичными результатами для двоичного формата представления. Для этих целей была выбрана модель представления данных Common Data Representation (CDR) [20], являющаяся основной для CORBA.

Было проведено три типа экспериментов по измерению:

  • Размера сообщения. Сопоставление размеров сообщения при использовании трех различных форматов представления.
  • Времени, необходимого сообщению для покрытия пути от источника до приемника. Для определения времени, необходимого сообщениям различных форматов для покрытия пути от источника до приемника использовались тестовые программы. Для измерения времени, затраченного на кодирование/декодирование и передачу сообщения по сети использовались высокоточные таймеры.
  • Пропускной способности сети. Для измерения времени, необходимого для передачи больших массивов данных в одном направлении, также использовались тесты. Первый набор тестов измерял пропускную способность на обоих концах сообщения. Сравнение полученных результатов с пропускной способностью сети при передаче некодированных сообщений позволило определить являются ли кодирование/декодирование и сеть ограничивающими факторами.

Данные

msg.header.SenderCompID = "ABC"
msg.header.TargetCompID = "XYZ"
msg.header.SendingTime = "20021116-10:15:28"

msg.body.MarketDataInc.MDReqID = "MYREQ"

msg.body.MarketDataInc.MDEntry[0].MDUpdateAction = Change
msg.body.MarketDataInc.MDEntry[0].MDEntryID = "FOO.last"
msg.body.MarketDataInc.MDEntry[0].MDEntryPx = 13.42
msg.body.MarketDataInc.MDEntry[0].MDEntrySize = 1200

Рис. 3: Пример структуры данных сообщения, содержащего "очередное обновление данных рынка"

FIX-сообщение, содержащее "очередное обновление данных рынка", было выбрано для эксперимента в качестве примера бизнес-данных. Подобные сообщения используются для обновления данных рынка (например, значений котировок акций на протяжении торгового дня) и, как правило, бывают большого объема, а высокая скорость их поступления является критичной для рынка. В ходе экспериментов передавались случайным образом сгенерированные экземпляры сообщения, подобного изображенному на рис. 3. Количество записей MDEntry, с целью изменения размера сообщения, в каждом сообщении варьировалось от 1 до 10, что позволило оценить постоянные потери в производительности, а также потери в производительности, имеющие место при инкрементном увеличении размера сообщения.

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

Сообщения переводились в/из форматов передачи данных с использованием кодировщиков/декодировщиков, специально приспособленных для работы с определенными схемами (schema-specific encoders/decoders). ПО, использовавшееся для этих целей, было следующим:

  • SOAP-сообщения генерировались с помощью свободно распространяемого высокопроизводительного gSOAP [27]. Работы [27, 4] показали, что gSOAP имеет существенно более высокую производительность, чем многие из широко используемых SOAP-реализаций, хотя и не настолько высокой как другие реализации, созданные специально для исследовательских целей. XML-схема сообщения была основана на FIXML DTD [9], с кодировщиками/декодировщиками, написанными на C++.
  • Реализация подмножества протокола FIX была разработана специально для этого исследования. Структура приложения определялась посредством CORBA IDL, кодировщики/декодировщики были написаны на C++.
  • С целью генерации на C++ кодировщиков/декодировщиков для формата CDR, с помощью IDL-компилятора TAO CORBA ORB [22] была скомпилирована CORBA IDL-схема, аналогичная той, которая использовалась для FIX.

Среда передачи данных

Тесты по определению времени, необходимого сообщениям для покрытия пути от источника до приемника, и пропускной способности сети при передаче сообщений были выполнены для сетей Ethernet двух типов: 10-мегабитной (10 Mbps) и 100-мегабитной (100 Mbps). Взаимодействие торговых систем реального времени часто осуществляется по арендованными каналам либо по Интернет, поэтому 10-мегабитная сеть в данном случае является подходящим сравнением.

Клиентская рабочая станция представляла из себя однопроцессорную систему Pentium III 900 MHz c 256 Kb cache level 2 с RAM 256 Mb, работающую под управлением ОС Microsoft Windows 2000. Тестовое ПО для этой системы было скомпилировано с помощью компилятора Borland C++ 5.6.1.

Сервер представлял собой однопроцессорную систему Pentium III 500 MHz с 512 Kb cache level 2 с 256 Mb RAM, работающую под управлением RadHat Linux 7.3 с ядром 2.4.18-3. Тестовое ПО для этой системы было скомпилировано с помощью компилятора g++3.2.1.

Результаты экспериментов

Размер сообщения

Перед проведением экспериментов по определению времени, необходимого сообщению для покрытия пути от источника до приемника и пропускной способности сети при передаче сообщений, были проведены эксперименты по сравнению размеров сообщений в форматах SOAP, FIX и CDR.



Рис. 4: Размеры сообщений различных форматов

Таблица 1: Сводная таблица затрат на кодирование/декодирование сообщений различных размеров и форматов

  Затраты на обработку сообщения начального размера   Затраты на обработку каждой записи сообщения 
 FIX 130.0 байт55.05 байт
 CDR 129.2 байт93.28 байт
 SOAP 695.8 байт166.0 байт

Рис. 4 и таблица 1 показывают размеры кодированных сообщений для каждого формата представления данных. На рисунке видно, что SOAP-сообщения существенно больше, в 3,5-4,5 раза больше нежели эквивалентные FIX-сообщения, и в 2-4 раза больше нежели CDR-сообщения. Эти результаты сопоставимы с нижней границей оценок для SOAP и XML, приведенных в работах [3, 4, 13].

8=FIX.4.3 9=00000098 35=X 49=ABC 56=XYZ 34=1 52=20
021116-10:15:28 262=MYREQ 268=1 279=1278=FOO.last
270=13.42 271=1200 10=185

Рис. 5: FIX-представление 


<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <SOAP-ENV:Body
   SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <sendMessage>
      <FIXMLMessage>
        <Header>
          <Sender>ABC
          <Target>XYZ
          <SendingTime>2002-11-16T10:15:28.000
        </Header>
        <ApplicationMessage>
          <MarketDataInc>}}
            <MDReqID>MYREQ
            <MDIncList>
              <MDIncGroup>
                <MDUpdateAction>1
                <MDEntryID>FOO.last
                <MDEntryPx>13.42
                <MDEntrySize>1200
              </MDIncGroup>
            </MDIncList>
          </MarketDataInc>
        </ApplicationMessage>
      </FIXMLMessage>
    </sendMessage>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Рис. 6: SOAP-представление

Рис. 5 демонстрирует сообщение, приведенное на рис. 3, в формате FIX. Рис. 6 демонстрирует то же сообщение в формате SOAP. Можно видеть, что использование пространств имен XML, длинные наименования тегов и многословный синтаксис делают SOAP-сообщение существенно больше. 


union Optional_String switch(boolean) {
case TRUE:
  string value;
};

Рис. 7: Прием, используемый в сообщениях CORBA IDL для описания необязательных полей

Рис. 4 также показывает, что протокол FIX имеет более компактное представление данных, чем CDR. CDR примерно на 50% больше из-за отсутствия в CORBA IDL встроенной поддержки необязательных полей. По причине отсутствия поддержки необязательных полей, мы использовали общий прием определения необязательных полей в CORBA [15], как показано на рис. 7. Можно видеть, что для указание присутствия каждого необязательного поля использовался однобайтовый индикатор. Поскольку заголовок сообщения содержит около 20 необязательных полей, а каждая запись данных - более 40 необязательных полей, отсутствие большинства этих полей в сообщении тем не менее влечет за собой немалые затраты при обработке сообщения. При использовании двоичных форматов с реальной поддержкой необязательных полей, таких как ASN.1/BER, получаются существенно более компактные сообщения.

Время, необходимое сообщению для покрытия пути от источника до приемника



Рис. 8: Время, затраченное сообщением на путь "туда-обратно" по 10-мегабитной сети

Таблица 2: Сводная таблица затрат на путь сообщения "туда-обратно" по 10-мегабитной сети

  Затраты на обработку сообщения начального размера   Затраты на обработку каждой записи сообщения 
 FIX 1.103 мсек0.1130 мсек
 CDR 1.076 мсек0.1851 мсек
 SOAP 2.525 мсек0.3875 мсек

Рис. 8 и таблица 2 содержат результаты измерений времени, затраченного сообщением на путь "туда-обратно" по 10-мегабитной сети. Данные результаты показывают, что FIX-сообщению потребовалось наименьшее время, CDR-сообщению потребовалось время, несколько большее, SOAP-сообщению потребовалось наибольшее время в сравнении с двумя другими форматами.



Рис. 9: Детализация временных затрат, необходимых сообщениям с 10 записями данных, для совершения пути "туда-обратно"

Детализация затрат, приведенная на рис. 9, показывает, что для всех трех форматов передачи данных по 10-мегабитной сети наибольшие затраты приходятся на время, проведенное сообщением в сети. Это позволяет предположить, что в сетевой среде размер сообщения является наиболее существенным ограничивающим фактором. При передаче по сети с меньшей пропускной способностью, более компактное FIX-сообщение имеет меньшее время, необходимое для покрытия пути "туда-обратно" нежели CDR.



Рис. 10: Затраты сервера на кодирование сообщений

Таблица 3: Сводная таблица затрат сервера на кодирование сообщений различных форматов

  Затраты на обработку сообщения начального размера   Затраты на обработку каждой записи сообщения 
 FIX 0.0232 мсек0.0058 мсек
 CDR 0.0141 мсек0.0059 мсек
 SOAP 0.1012 мсек0.0599 мсек



Рис. 11: Затраты сервера на декодирование сообщений

Таблица 4: Сводная таблица затрат сервера на декодирование сообщений различных форматов

  Затраты на обработку сообщения начального размера   Затраты на обработку каждой записи сообщения 
 FIX 0.0358 мсек0.0057 мсек
 CDR 0.0358 мсек0.0112 мсек
 SOAP 0.1878 мсек0.0547 мсек

При передаче по 100-мегабитной сети, доля общего времени, необходимого для покрытия пути "туда-обратно", приходящаяся на пребывание сообщения в сети, менее значительна. Рис. 10 и таблица 3 показывают затраты на кодирование сообщений различных форматов, рис. 11 и таблица 4 - соответствующие затраты на декодирование.

Для 100-мегабитной сети Ethernet существенно большие затраты на кодирование/декодирование SOAP-сообщений вызваны, в основном, более низкой производительностью. При этом время, затраченное на путь "туда-обратно", для SOAP в 2-3 раза больше, чем для FIX и CDR.

Неожиданность результата, приведенного на рис. 11, состоит в том, что FIX, являющийся текстовым форматом, имеет меньшие затраты на декодирование, чем двоичный формат CDR. Подобный вывод тем более важен, учитывая большую сложность процесса декодирования FIX-сообщения, имеющего теги, нестрогий порядок следования полей, а также принимая во внимание тот факт, что многие поля в сообщении могут присутствовать, а могут и не присутствовать. С другой стороны, в случае CDR-сообщения, все поля должны быть декодированы именно в том порядке, в каком они определены описанием CORBA IDL. Данный результат дает основания для следующих двух предположений:

  • Реальные данные сообщений предствляют собой смесь строк, целых чисел и чисел с плавающей запятой. Затраты на конвертацию числовых данных из текстового формата в двоичный, в противовес ранее проведенным исследованиям, не играют существенной роли.
  • Затраты на обработку сложной структуры FIX-сообщений несущественны по сравнению с затратами на декодирование поля, и тем больше, чем меньшее количество полей, не представленных в сообщении, подлежит обработке. При кодировании сообщений кодировщики должны были проверять присутствие каждого поля для сообщений всех форматов, что приводило к потере преимуществ.

Пропускная способность сети при передаче сообщений



Рис. 12: Пропускная способность при передаче сообщений по 10-мегабитной сети

Рис. 12 демонстрирует результаты измерений пропускную способность при передаче сообщений, передаваемых по 10-мегабитной сети. В этом случае сеть сама была узким местом для сообщений всех трех форматов. Как и при измерении времени, необходимого сообщению для покрытия пути от источника до приемника, эти результаты свидетельствуют о том, что в сетевой среде, имеющей небольшую пропускную способность, размер сообщения является наиболее существенным фактором, влияющим на производительность. Это позволяет протоколу FIX с наиболее компактными сообщениями показывать наилучшие показатели пропускной способности.



Рис. 13: Пропускная способность при передаче сообщений по 100-мегабитной сети

Для 100-мегабитных сетей узким местом является сервер, имеющего наименьшую производительность центрального процессора. Результаты экспериментов, приведенные на рис. 13, показывают, что протокол FIX и для 100-мегабитных сетей имеет наибольшую пропускную способность, хотя CDR имеет меньшие затраты на кодирование. Это является результатом процесса декодирования, выполненного на наименее производительном сервере, который имеет меньшие затраты для FIX нежели для CDR, выполненного на компьютере с меньшим быстродействием. Именение ролей компьютеров влечет изменение относительной пропускной способности форматов передачи данных.

Интересно, что производительность SOAP при использовании 100-мегабитной сети оказывается хуже по сравнению с двумя другими форматами. Это объясняется тем, что отношение затрат на декодирование для SOAP к аналогичным затратам для FIX и CDR больше нежели соответствующие отношения размеров сообщений.

Сжатие SOAP-сообщений

При передаче сообщения по сети с небольшой пропускной способностью, ограничивающим фактором для производительности является размер сообщения. Как результат этого, представляется целесообразным производить сжатие SOAP-сообщения для улучшения ситуации. С этой целью были проведены дополнительные тесты по определению времени, необходимого сообщениям для покрытия пути от источника до приемника, когда SOAP-сообщения непосредственно перед передачей сжимались. Для сжатия сообщений использовался наиболее быстрый режим сжатия библиотеки zlib, позволяющий достигнуть отношения сжатия 50-70%.



Рис. 14: Время, затраченное сжатыми и несжатыми SOAP-сообщениями на путь "туда-обратно" по 10-мегабитной сети

Приведенные на рис. 14 результаты, свидетельствуют, что сжатие на самом деле лишь вредит, существенно увеличивая время, затраченное на прохождение пути "туда-обратно". Увеличение времени, необходимого центральному процессору для кодирования/декодирования сообщений, перевешивает любые преимущества. Таким образом, сжатие сообщений может быть полезно лишь для сетей с небольшой пропускной способностью.

Использование компактных XML-тегов



Рис. 15: Уменьшение размера сообщений при использовании компактных XML-тегов

Альтернативным методом, позволяющим уменьшить размер SOAP-сообщений, который рассматривался в данном исследовании, является применение XML-тегов с меньшей длиной наименований. Это можно сделать заменой FIXML-наименований тегов короткими (в 2-4 символа) строками, основанными на числовых FIX-тегах. Данная мера позволяет уменьшить размер SOAP-сообщения примерно на 25-35% как показано на рис. 15, однако при применении этого способа приходится приносить в жертву читабельность (вольный перевод англ. термина readability - прим. перев.) сообщения.



Рис. 16: Время, затраченное компактными SOAP-сообщениями на путь "туда-обратно" при передаче по 10-мегабитной сети



Рис. 17: Затраты сервера на декодирование компактных SOAP-сообщений

Обсуждение результатов

Более ранние исследования производительности SOAP и XML [3, 4] показали, что преобразования из текстового формата в двоичный и обратно влекут за собой наибольшие затраты, большая часть которых приходится на кодирование/декодирование чисел с плавающей точкой. Однако, эти исследования были ориентированы на приложения SOAP и XML в области научных вычислений с сообщениями, состоящими, в основном, из числовых данных.

В этой работе мы сделали попытку изучения производительности SOAP при его применении в сообщениях реального бизнес-приложения (торговой системы реального времени). Результаты сравнений производительности SOAP с производительностью двоичного формата CDR показали более низкую производительность SOAP. Однако, эта разница оказалась не столь велика как в экспериментах с числовыми данными, использованных в упомянутых выше более ранних работах. Учитывая, что общая производительность FIX, являющегося текстовым форматом, оказалась сравнимой с CDR, а также то, что FIX превосходит CDR при декодировании, становится ясно, что преобразование из текстового формата в двоичный и обратно в этом случае не является серьезным фактором, влияющим на производительность.

Данное исследование позволило сделать в отношении производительности два важных вывода:

  • В бизнес-приложениях возможно достижение производительности текстового формата сравнимой с двоичным форматом. Более низкая производительность SOAP по сравнению с другими форматами не может быть вполне объяснена тем фактом, что формат представления данных SOAP является текстовым.
  • Уменьшение размера кодированного SOAP-сообщения с помощью более коротких тегов не дает пропорционального увеличения скорости кодирования/декодирования.
Совокупность полученных результатов свидетельствует о том, что вероятной причиной более низкой производительности SOAP как формата передачи даных является сложность синтаксиса XML и структуры XML-сообщений. Описание SOAP-сообщения, которое использовалось в данном исследовании, было близко к FIXML [9], имело сложную структуру и высокую степень вложенности. В дальнейших исследованиях, вероятно, будет полезно измерить влияние на производительность иных представлений XML-сообщений. Результаты подобных исследований позволят разработчикам выбирать наиболее эффективную конструкцию SOAP-сообщений при создании высокопроизводительных приложений.

Результаты настоящего исследования также позволили выявить несколько факторов, учет которых разработчиками приложений, использующих SOAP, позволит добиться максимальной производительности приложений. Дальнейшее прояснение причин низкой производительности SOAP, а также выработка подходов, позволяющих ее увеличить - предмет дальнейших исследований.

Кроме того, в этом исследовании мы рассмотрели характеристики производительности, присущие сугубо SOAP. Другие требования, накладываемые на использование SOAP в финансовых системах, такие как безопасность и отказоустойчивость, могут оказывать дополнительное влияние на производительность SOAP.

И наконец, результаты исследования показали, что при рассмотрении вопросов, касающихся производительности SOAP, важно принимать во внимание среду передачи данных реализации приложения. Хотя для сетей с высокой пропускной способностью скорость кодирования/декодирования является доминирующим фактором, влияющим на производительность, для сетей с меньшей пропускной способностью доминирующим фактором является размер кодированного сообщения, который определяет и время, необходимое сообщению для покрытия пути от источника до приемника, и пропускную способность. Это важно при построении b2b-интеграционных решений, которые в финансовой области, также как и в других областях, часто используют WAN-сети.

Выводы

В этой работе мы представили результаты оценки производительности SOAP в случае его использования в бизнес-приложении. Данные результаты показали, что пока SOAP имеет производительность худшую нежели двоичный формат протокола CDR и устоявшийся индустриальный протокол FIX. При этом разница в производительности указанных форматов меньше, чем в случае их использования для осуществления научных вычислений. Более того, в реальных бизнес-средах текстовые форматы передачи данных могут иметь производительность, сравнимую с производительностью двоичных форматов. Это говорит о том, что текстовая природа XML сама по себе не является существенным ограничивающим фактором эффективности кодирования/декодирования SOAP. Следует предположить, что дальнейшие разработки, направленные на улучшение производительности кодировщиков/декодировщиков SOAP могут сделать этот протокол вполне жизнеспособным для использования в высокопроизводительных бизнес-приложениях. Несмотря на это, в случае проектирования чувствительных к производительности интеграционных систем, взаимодействующих по WAN-сетям, в общем случае, фактором, ограничивающим производительность, является пропускная способность сети. Поэтому при выборе наиболее подходящего формата передачи данных имеет следует руководствоваться оценкой размеров кодированных сообщений.

Ссылки

[1] Australian Stock Exchange. The SEATS computer system, 2000. http://www.asx.com.au/markets/l4/SEATS_AM4.shtm, accessed 1 June 2002.

[2] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext transfer protocol - HTTP/1.0, 1996. IETF RFC 1945, http://www.ietf.org/rfc/rfc1945.txt.

[3] F. E. Bustamante, G. Eisenhauer, K. Schwan, and P. Widener. Efficient wire formats for high performance computing. In Proceedings of the 2000 Conference on Supercomputing, 2000.

[4] K. Chiu, M. Govindaraju, and R. Bramley. Investigating the limits of SOAP performance for scientific computing. In Proceedings of the 11th IEEE International Symposium on High Performance Distributed Computing, pages 246-254, 2002.

[5] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, and S. Weerawarana. Unraveling the web services web: An introduction to SOAP, WSDL, UDDI. IEEE Internet Computing, 6(2):86-93, March-April 2002.

[6] D. Davis and M. Parashar. Latency performance of SOAP implementations. In Proceedings of the 2nd IEEE/ACM International Symposium on Cluster Computing and the Grid, pages 407-412, 2002.

[7] M. Fan, J. Stallaert, and A. B. Whinston. The internet and the future of financial markets. Communications of the ACM, 43(11):83-88, November 2000.

[8] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext transfer protocol - HTTP/1.1, 1999. IETF RFC 2616, http://www.ietf.org/rfc/rfc2616.txt.

[9] FIX Protocol Ltd. FIXML: A markup language for the FIX application message layer. http://www.fixprotocol.org/WORKGROUPS/928951581/wpaper.html, accessed 8 June 2002.

[10] FIX Protocol Ltd. The Financial Information Exchange Protocol (FIX), version 4.3, August 2001. http://www.fixprotocol.org/specification/fix-43-pdf.zip, accessed 8 June 2002.

[11] M. Girardot and N. Sundaresan. Millau: An encoding format for efficient representation and exchange of XML over the web. In Proceedings of the 9th International World Wide Web Conference, pages 747-765, 2000.

[12] J. Goeller. FIXML and STP related efforts, 2000. http://www.fixprotocol.org/WORKGROUPS/928951581/XML_STP_John6.ppt, powerpoint presentation, accessed 8 June 2002.

[13] M. Govindaraju, A. Slominski, V. Choppella, R. Bramley, and D. Gannon. Requirements for and evaluation of RMI protocols for scientific computing. In Proceedings of the 2000 Conference on Supercomputing, 2000.

[14] S. Graham, S. Simeonov, T. Boubez, D. Davis, G. Daniels, Y. Nakamura, and R. Neyama. Building Web Services with Java: Making Sense of XML, SOAP, WSDL, and UDDI. Sams Publishing, Indianapolis, 2002.

[15] M. Henning and S. Vinoski. Advanced CORBA Programming with C++. Addison-Wesley, Reading, Massachusetts, 1999.

[16] V. Jacobson. Congestion avoidance and control. In Symposium proceedings on Communications architectures and protocols, pages 314-329. ACM Press, 1988.

[17] B. Liu and E. A. Fox. Web traffic latency: Characteristics and implications. J.UCS: Journal of Universal Computer Science, 4(9):763-778, 1998.

[18] B. Martin and B. Jano. WAP binary XML content format, June 1999. http://www.w3.org/TR/wbxml/, accessed 1 June 2002.

[19] H. F. Nielsen, J. Gettys, A. Baird-Smith, E. Prud'hommeaux, H. W. Lie, and C. Lilley. Network performance effects of HTTP/1.1, CSS1, and PNG. In Proceedings of the ACM SIGCOMM '97 conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, pages 155-166, 1997.

[20] Object Management Group. The Common Object Request Broker Architecture: Core Specification, version 3.0, November 2002.

[21] F. A. Rabhi and B. Benatallah. An integrated service architecture for managing capital market systems. IEEE Network, 16(1):15-19, 2002.

[22] D. C. Schmidt, D. L. Levine, and S. Mungee. The design of the TAO real-time object request broker. Computer Communications, 21(4):294-324, April 1998.

[23] S. E. Spero. Analysis of HTTP performance problems, 1994. http://www.w3.org/Protocols/HTTP/1.0/HTTPPerformance.html, accessed 15 June 2002.

[24] W. R. Stevens. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley, Reading, Massachusetts, 1994.

[25] N. Sundaresan and R. Moussa. Algorithms and programming models for efficient representation of XML for internet applications. In Proceedings of the 10th International World Wide Web Conference, pages 366-375, 2001.

[26] SWIFT. About SWIFT - History. http://www.swift.com/, accessed 3 June 2002.

[27] R. A. van Engelen and K. A. Gallivan. The gSOAP toolkit for web services and peer-to-peer computing networks. In Proceedings of the 2nd IEEE/ACM International Symposium on Cluster Computing and the Grid, pages 128-135, 2002.

[28] P. Widener, G. Eisenhauer, and K. Schwan. Open metadata formats: Efficient XML-based communication for high performance computing. In Proceedings of the 10th IEEE International Symposium on High Performance Distributed Computing, pages 371-380, 2001.

Комментарии к статье принимаются по адресу info@ubs.ru.

Вопросы? Ответим в течение часа.

Написать