УДК 681.326+658.52.011.56+681.324
БЫСТРОДЕЙСТВИЕ ПРОГРАММНЫХ КОМПОНЕНТОВ РАСПРЕДЕЛЕННЫХ СИСТЕМ СБОРА ИНФОРМАЦИИ РЕАЛЬНОГО ВРЕМЕНИ
К.И. Будников, К.В. Зезюля
Оценивается быстродействие ряда программных компонентов сбора и визуализации информации реального времени на основе 1п1хапе1;-технологий на платформе \Vm32.
ВВЕДЕНИЕ
Перспективность и актуальность внедрения Intranet-техноло-гий в системы мониторинга и промышленной автоматизации уже не вызывает сомнений [1]. С ростом пропускной способности каналов связи одной из наиболее важных характеристик подобных систем становится возможность передачи информации в реальном масштабе времени. Для систем же на основе Intranet-сетей, в которых информация передается по высокоскоростным коммуникациям, становится важной не только пропускная способность каналов связи, но и производительность узлов сети и программных компонентов, выбранных для построения всей системы.
Цель настоящей работы — сравнение быстродействия программных компонентов, используемых для построения системы сбора и визуализации информации реального времени (далее по тексту — СРВ) на основе Intranet-технологий, предоставляемых разработчику различными производителями программного обеспечения на платформе Win32. Работа выполнялась в рамках проекта создания автоматизированной системы технического обслуживания и управления (АСТОУ) Новосибирской ГЭС, которая имеет иерархическую четырехуровневую архитектуру
[2]. Верхний уровень АСТОУ — инженерный — построен как Intranet
[3] и решает задачи по архивированию и визуализации медленно меняющейся (каждые полчаса) информации. На нижележащем диспетчерском уровне АСТОУ, на котором сосредоточено управление ГЭС, информация обновляется ежесекундно; при этом передается ~1000 16-битовых параметров. Эти значения были взяты за основу для тестирования программных компонентов СРВ,
хотя количество параметров и период их обновления может быть другим. Полученные результаты позволяют сравнить различные программные компоненты между собой и дать представление об их быстродействии.
ПРОГРАММНЫЕ КОМПОНЕНТЫ СРВ
Поскольку СРВ имеют архитектуру "клиент — сервер", то и их программные компоненты подразделяются на компоненты клиентской и серверной сторон. Самый простой способ обновления информации на клиентской стороне — использование динамически обновляемых клиентом (client-pull) HTML-документов. Однако он имеет ряд недостатков, главные из которых — перегрузка каналов связи при передаче графической информации и невозможность обновления информации быстрее, чем 1 Гц. Рационально добавить программный компонент в HTML-документ, чтобы обновление касалось только данных и части отображаемого документа. В настоящий момент возможно применение одного из двух наиболее популярных решений, поддерживающих графическое отображение данных — вставить в HTM L-документ Java-ап-плет или ActiveX-объект.
Программными компонентами серверной стороны выступают Web-сервер и его расширения, СУБД, источники данных. Наиболее популярным Web-сервером на платформе Win32 является Internet Information Server (IIS) компании Microsoft. Он хорошо взаимодействует с операционной системой и отвечает необходимым требованиям по обеспечению безопасности. Для тестирования мы использовали версию 4.0. В качестве сервера базы данных для тестирования был выбран Microsoft
SQL Server7 Service Pack 1 — характерный представитель программных продуктов этого класса. Источники данных специфичны для каждой конкретной СРВ, однако данные могут накапливаться в буферном процессе-сервере для последующей передачи и обработки. Платформа Win32 предлагает ряд возможностей для создания подобных серверов. Критическими факторами в них являются время межпроцессного взаимодействия и удобство реализации сервера. Среди методов взаимодействия распределенных процессов можно выделить Pipes, RPC и Windows Sockets.
Все эти методы относятся к соединениям типа "точка — точка", поэтому для организации сервера на их основе требуется разработка дополнительного протокола обмена для выделения канала обмена процессу-клиенту процессом-сервером. В настоящее время компанией Microsoft и группой компаний OMG предлагаются две технологии (соответственно COM/DCOM и CORBA), позволяющие создавать серверные процессы и в которых проблемы, связанные с взаимодействием кли-ент^сервер, решаются автоматически [4]. Обе технологии поддерживают множественные соединения. Нами было отдано предпочтение "родной" для Win32 технологии COM/DCOM. При тестировании мы старались выяснить, какова плата, с точки зрения временных затрат, за обеспечение удобства в программировании.
ТЕСТИРОВАНИЕ ПРОГРАММНЫХ КОМПОНЕНТОВ СРВ
Приведенные далее тесты проводились на компьютерах, работающих под управлением ОС Windows NT 4.0 SP6 и соединенных локальной сетью Ethernet 10 Мбит. Одна
Схема СРВ с накоплением данных в СУБД
из возможных схем СРВ, базирующаяся на классической архитектуре Intranet, изображена на рисунке. В этой системе оперативные и архивные данные накапливаются в СУБД, а передача и визуализация информации происходит по запросам пользователей СРВ через один или несколько Web-серверов. Достоинство данной схемы — унификация интерфейсов между различными программными компонентами через СУБД. При этом СУБД оказывается под очень сильной нагрузкой.
Производительность сервера БД очень сильно зависит от аппаратной части. Однако целью тестов было сравнение различных программных компонентов в одинаковых условиях без дополнительной аппаратной поддержки. Поэтому для оценки СУБД был выбран серийный компьютер с процессором Intel Celeron, работающий на частоте 333 МГц, с ОЗУ 256 Мбайт. Для оценки производительности СУБД используется такая характеристика, как число транзакций в минуту, сделанных сервером БД при обработке типовых запросов клиента. Совет по производительности обработки транзакций (Transaction Processing Performance Council) организация, занимающаяся этими вопросами с 1988 г., предлагает ряд подобных тестов, которые можно найти на Web-ссрвсрс этой организации (www.tpc.org). В них моделирование транзакций ориентировано на применение СУБД для решения экономических задач.
Поэтому было решено смоделировать функционирование рассматриваемой системы с характерными для нее транзакциями СУБД. Было
сделано два теста, в которых один клиент записывал 1000 16-битовых чисел, а остальные клиенты делали выборку 1000 16-битовых чисел. Периодичность записи и выборки — 1 Гц. Клиентом была программа, написанная на языке С++. В первом тесте все клиенты располагались в четырех компьютерах в локальной сети, во втором тесте запись и выборка производилась локально на сервере БД. Результаты тестов представлены в табл. 1 и 2. Минимальное, максимальное и среднее времена выполнения транзакций указаны в миллисекундах. В графе "Клиенты" указано число клиентов, производящих выборку из СУБД, в графе
"CPU" указана загрузка процессора сервера в процентах, в графе "Память" указано количество памяти, занимаемой процессом СУБД, в мегабайтах.
В следующей группе тестов представлены результаты тестирования Web-cepeepa (компьютер Celeron 333 МГц/64 Мбайт) и клиента на основе Лауа-апплета, которому мы отдали предпочтение. Java-amuieT может взаимодействовать с различными расширениями Web-cepeepa, но мы выбрали CGI-скрипты как наиболее гибкие и устоявшиеся средства. Данные передавались пакетами по 10 значений двумя методами: непрерывным потоком (вынуждая Web-cepeep посылать данные клиенту не дожидаясь окончания работы скрипта, передающего данные) и непрерывным запуском CGI-скрипта, передающего 1 пакет. Тесты выполнялись в двух вариантах: без задержки посылки данных и с задержкой между посылками в 1 с. В первом методе CGI-скрипт был написан на языке PERL, во втором — на языках программирования PERL, С++ и АССЕМБЛЕР. Результаты представлены в табл. 3^5. Время указано в миллисекундах, загрузка процессора Web-cepeepa — в процентах.
В последней группе тестов представлены результаты тестирования COM/DCOM и Pipe серверов (компьютер Celeron 333 МГц/128 Мбайт). Некоторые оценки DCOM можно найти в работе [5]. Мы не
Таблица 1
Тест СУБД № 1: взаимодействие с клиентами в локальной сети
Клиен- Запись Выборка CPU Память
ты Т ■ 1 гшп ^mid Т 1 max Т ■ 1 mm ^mid Т 1 max
I 60 74 140 100 118 180 6 156,9
2 60 82 712 120 156 1332 12 159,7
10 по 242 451 ПО 361 1583 56 168
16 160 512 1332 190 771 2163 97 177,5
Таблица 2
Тест СУБД № 2: локальная запись и выборка
Клиен- Запись Выборка CPU Память
ты Т ■ 1 mm ^mid Т 1 max Т ■ 1 mm ^mid Т 1 max
1 40 43 132 50 6i 481 12 145,7
13 40 72 271 50 97 951 87 147,7
14 40 102 370 50 120 1242 97 149
16 190 542 1152 60 905 2133 100 152,2
6
Sensors & Systems • № 9.2001
Таблица 3
Тест Web-cepeepa: передача данных непрерывным потоком
Клиенты Без задержки С задержкой
^niid CPU ^niid CPU
1 12 6 1 0
3 16 14 2 0
5 36 18 2 0
10 56 20 2 0
Таблица 4
Тест Web-cepeepa: непрерывный запуск CGI-скрипта
Клиенты
3 5 10
PERL С++ АССЕМБЛЕР
^mid CPU ^mid CPU ^mid CPU
6i 62 41 35 38 31
89 100 47 69 46 68
136 100 82 81 76 80
270 100 182 88 155 86
Таблица 5
Тест Web-cepeepa: запуск CGI-скрипта с интервалами в 1 с
Клиенты
3 5 10
PERL С++ АССЕМБЛЕР
^mid CPU ^mid CPU ^mid CPU
47 3 38 2 38 2
47 7 44 5 42 4
47 12 51 7 44 6
266 17 51 14 44 12
Таблица 6
Тест COM/DCOM и Pipe серверов: непрерывные транзакции
Клиенты COM DCOM Pipe
локально без имени локально с именем удаленный
^mid CPU ^mid CPU ^niid ^niid ^niid
1 0,73 0 5,35 4 0,09 0,7 4,8
3 1,97 0 8,29 25 - - -
5 3,05 8 13,08 37 - - -
10 9,83 11 24,85 48 — — —
Таблица 7
Тест COM/DCOM и Pipe серверов: транзакции с интервалом в 1 с
Клиенты СОМ DCOM Pipe
локально без имени локально с именем удаленный
^mid CPU ^mid CPU ^niid ^niid ^mid
1 0,53 0 5,2 0 0,14 0,75 5,2
3 0,6 0 5,2 0 - - -
5 0,6 0 5,2 0 - - -
10 0,6 0 5,2 0 — — —
стали реализовывать Pipe-ссрвср с поддержкой множественных соединений из-за трудоемкости этого процесса и ограничились тестом соединения сервера с одним к
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.