Наши партнеры

UnixForum

Библиотека сайта rus-linux.net

Применение принципов оптимизации к средствам компонентного развертывания и конфигурирования систем

Глава 6 из книги "Производительность приложений с открытым исходным кодом".
Оригинал: Applying Optimization Principle Patterns to Component Deployment and Configuration Tools,
Авторы: Doug C. Schmidt, William R. Otte, and Aniruddha Gokhal
Перевод: Н.Ромоданов

Применение принципов оптимизации к DAnCE

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

Обзор платформы SEAMONSTER

Примером системы DRE, в которой были выявлены значительные проблемы с производительностью при использовании движка DAnCE, была платформа South East Alaska MOnitoring Network for Science, Telecommunications, Education, and Research — SEAMONSTER (сеть мониторинга Юго-Восточной Аляски в науке, телекоммуникациях, образовании и исследованиях; SEAMONSTER переводится как «Морской монстр» — прим.пер.), работа на которой проходила в сотрудничестве с Университетом Аляски. SEAMONSTER представляет собой веб-сеть датчиков, расположенных на леднике с хостингом в Юго-восточном университете Аляски (UAS) [28]. Эта веб-сеть датчиков выполняет мониторинг и собирает данные о динамике ледников и балансе их масс, гидрологии водосборов, морской экологии прибрежной полосы и антропогенном воздействии / чрезвычайных ситуациях в районе водораздела реки Lemon Creek и ледника Lemon. Собранные данные используются для изучения корреляции между скоростью движения ледника, формированием ледниковых озер и дренажа, гидрологии в районе водосбора и изменения значений температуры.

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

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

Чтобы справиться с такими проблемами, мы предложили перенести задачи по сбору и обработки данных на платформу со средним слоем, созданном на поверх CIAO и DAnCE так, как это описано во введении и в разделе «Обзор реализации DAnCE» настоящей статьи, соответственно. Мы разработали планировщик времени выполнения [29], который анализирует физическое состояние узлов с датчиками. Используя эту информацию, а также исходя из оперативных задач сети, планировщик строит планы развертывания приложений, в которых описывается конфигурирование требуемого программного обеспечения.

Однако, применение подхода DAnCE к задаче изменения планов развертывания, создаваемых планировщиком времени выполнения, выявило ряд недостатков, касающихся производительности. Эти недостатки усугубились ограниченной производительностью оборудования, установленного в полевых условиях, сравнительно медленной скоростью работы сети, соединяющей узлы, и жесткими требованиями системы реального времени. Ниже описан каждый из этих недостатков.

Оптимизация фазы анализа плана развертывания приложений

Контекст

Согласно спецификации OMG D&C развертывание приложения, создаваемого из компонент, описывается с помощью структуры данных, в которой для каждого экземпляра компонент указываются все необходимые конфигурационные метаданные, отображения экземпляров компонентов на отдельные узлы, а также любая другая информация, необходимая для их подключения. Этот план развертывания записывается на диск в файл XML, структура которого описывается схемой XML, определяемой спецификацией D&C. Такой формат документа XML обладает существенными преимуществами благодаря тому, что для обмена файлами, содержащими планы развертывания, в средствах моделирования можно пользоваться простым форматом обмена [30].

Например, в примере с SEAMONSTER такой формат представляет собой удобный формат обмена данными между планируемым внешним интерфейсом платформы и инфраструктурой развертывания приложений. Также такой формат просто создавать и с ним просто работать в популярных языках программирования, в которых используются широко распространенные модули обработки языка XML. Кроме того, этот формат легко изменять и выбирать из него данные при помощи средств обработки текста, например, perl, grep, sed и awk.

Проблема

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

  • По мере того, как при развертывании увеличивается количество экземпляров компонентов и соединений, существенно растут размеры файлов XML, содержащих планы развертывания, что ведет к существенной перегрузке по вводу/выводу при загрузке плана в память и при проверке плана на соответствие схеме, позволяющей убедиться, что план сформирован корректно.
  • Документ в формате XML нельзя использовать непосредственно в инфраструктуре развертывания, поскольку инфраструктура является приложением CORBA, реализующим интерфейсы OMG Interface Definition Language (IDL). Поэтому документ XML сначала должен быть преобразован в формат IDL, который будет использоваться интерфейсами времени выполнения во фреймворке развертывания приложений.

В системах DRE не редкость, когда количество развертываемых компонентов исчисляется тысячами. Кроме того, экземпляры компонентов в таких доменах могут демонстрировать высокую степень связности. Оба эти фактора становятся причиной создания планов большого размера. Однако планы не должны быть большими с тем, чтобы не оказывать существенного влияния на работу системы. Хотя в случае SEAMONSTER, описанном выше, планы были существенно меньшими, крайне ограниченные вычислительные ресурсы означали, что на обработку даже маленьких планов развертывания, часто затрачивалось слишком много времени.

Принципы оптимизации, используемые при анализе конфигурационных метаданных

Есть два универсальных подхода к решению проблемы с разбором XML, описанной в разделе «Проблема».

1. Оптимизация преобразований из XML в IDL. В DAnCE используется специальная привязка данных XML, использующая специальный словарь и называющаяся компилятором схем XML (XML Schema Compiler - XSC) [31]. Компилятор XSC читает схемы D&C на языке XML и создает интерфейс на языке С++ для доступа к документам XML; интерфейс создается на основе API, позволяющим программным образом получать доступ к объектной модели документов Document Object Model (DOM), записанной на языке XML. DOM это подход с интенсивными затратами времени/места, поскольку прежде, чем будет инициирован процесс перевода из XML в IDL, сначала нужно обработать весь документ для того, чтобы на основе информации о документе сконструировать дерево документа. Поскольку в структурах данных, имеющихся в плане развертывания, присутствует большое количество внутренних перекрестных ссылок, подходы, альтернативные использованию DOM, в том числе событийные механизмы обработки планов развертывания, например, Simple API for XML (SAX), не дадут какой-либо существенной выгоды.

Когда с помощью XSC генерируется привязка данных на языке C++, то создается ряд классов (на основе содержимого схемы XML), с помощью которых обеспечивается строго типизированный объектно-ориентированный доступ к данным в документе XML. Кроме того, этот интерфейс использует особенности библиотеки C++ STL, помогающие программистам писать компактный и эффективный код для взаимодействия со своими собственными данными. Общий процесс формирования таких оберток состоит из 1) анализа документа на языке XML при помощи парсера DOM XML, а также 2) анализа дерева DOM при заполнении сгенерированной иерархии классов. В целях повышения совместимости с алгоритмами и функторами библиотеки STL, XSC хранит свои внутренние данные в контейнерных классах STL.

Первоначальные версии привязки данных XSC были крайне неэффективными. Даже относительно скромные случаи развертывания с количеством компонентов всего лишь от нескольких сотен до тысячи могли обрабатываться почти полчаса. После того, как был выполнен анализ этого процесса с использованием таких инструментов, как Rational Quantify, была выявлена очень простая проблема: код, генерируемый XSC, вставлял элементы в свои внутренние структуры данных (в данном случае, std::vector) по отдельности самым незамысловатым образом. В результате, для каждого дополнительного вставляемого элемента тратилось чрезмерное количество времени на перераспределение памяти и копирование данных внутри этих контейнеров.

Ниже мы приводим конкретные указания, на что должны обращать внимание разработчики:

  • Будьте в курсе стоимости ваших абстракций. Абстракции высокого уровня, такие как контейнерные классы, которые доступны в библиотеке C++ STL, могут значительно упростить программы за счет снижения необходимости воспроизводить сложный и подверженный ошибкам код низкого уровня (в основном, шаблоны). Важно описать и задокументировать (при написании абстракций), а также понимать (при их использовании), какие могут возникнуть скрытые расходы при использовании операций высокого уровня, предлагаемых в вашей абстракции.
  • Используйте абстракции, подходящие для вашей конкретной ситуации. Часто можно выбирать абстракции, предлагающие аналогичные функции. Примером может быть выбор между вариантами std::vector и std::list, причем в каждом из них есть свои преимущества. В XSC первоначально использовался вариант std::vector, поскольку мы хотели иметь произвольный доступ к элементам в привязке данных; в результате из-за плохой производительности при вставке элементов была получена чрезвычайно низкая производительность при разборе документа XML. Однако, в нашем случае требуется только последовательный доступ, поэтому в конце концов, гораздо более желательным оказался вариант std::list, имеющий гораздо более высокую производительность.

Благодаря тому, что было понимание специфических требований конкретного варианта использования наших генерируемых XML-привязок данных - в частности, того, что большинство узлов посещается один раз и их можно посещать в некотором порядке, мы смогли применить принцип Expected Use Case (Предполагаемый вариант использования), использовав для этого два других принципа оптимизации. В данном случае речь идет о принципе Avoiding Generality (Избегайте обобщений), поскольку мы сознательно избегаем пользоваться более общим случаем, поскольку создаем привязку данных без использования контейнеров с произвольным доступом. А после этого мы решили пользоваться более эффективной структурой данных (принцип Efficient Data Structures - Эффективные структуры данных) с тем, чтобы компенсировать отсутствие обобщенного подхода.

2. Предварительная обработка файлов XML для случаев развертывания, критичных к задержкам. Хотя оптимизация процесса преобразования из XML в IDL позволила получить время, достаточное для преобразований, этот шаг в процессе развертывания все еще занимал большую часть общего времени, необходимого для развертывания. Этих все еще достаточно больших накладных расходов можно было бы избежать, если применить другой принцип оптимизации:

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

В этом оптимизационном подходе применяется принцип оптимизации Shifting in Time (Сдвиг операций по времени), в соответствие с которым дорогостоящее преобразование плана развертывания было преобразовано в более эффективный двоичный формат вне пределов критического пути развертывания приложений. Когда применяется этот принцип, мы сначала преобразуем план развертывания в его представлении на языке IDL времени выполнения. Затем мы записываем результат на диск в двоичном формате Common Data Representation (CDR) [32], определенным в спецификации CORBA. Онлайновый планировщик, имеющийся в SEAMONSTER, может быть в выигрыше от такой оптимизации, поскольку использование подобных планов в двоичном формате вместо планов на языке XML существенно снижает задержку, связанную с обработкой.

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

Продолжение статьи: Оптимизация анализа плана развертывания.