 |
|
|
|
| |
 к выбору публикации
|
|
|
|
С.С. Юдицкий |
 |
Как профессионально исследовать эффективность работы прикладного программного обеспечения в сети и выбрать сетевую аппаратуру, оптимально соответствующую его требованиям? Методика тестирования рассматривается на примере изучения работы прикладного пакета RS-Bank в локальных и глобальных сетевых конфигурациях.
Растет конкуренция на рынке прикладных программных продуктов. Особенно сильно она ощущается среди программного обеспечения для автоматизации банковской деятельности. Постепенно уходят в историю программы, написанные программистами одиночками на основе общедоступных баз данных (Fox, Clipper и т. п.). На смену им приходят продукты крупных фирм разработчиков - как российских, так и зарубежных, которые не только разрабатывают программное обеспечение, но и осуществляют его внедрение "под ключ" в сложных сетевых конфигурациях. Вопрос о принципиальной возможности работы таких продуктов в локальной сети уже в прошлом. Жизнь ставит перед нами новые вопросы. Насколько эффективно работает тот или иной програм-мный продукт в сети (и не только в локальной, но и в глобальной)? Как правильно выбрать технические средства: серверы, маршрутизаторы, каналы связи для глобальных конфигураций, - чтобы программный продукт работал эффективно? Какую архитектуру сети предпочесть, сколько рабочих станций установить на физическом сегменте сети, как настроить сетевую операционную систему, чтобы время реакции прикладного пакета было приемлемым? Другими словами, как выбрать оборудование и построить сеть "от задачи" и как убедиться в том, что конкретный программный продукт на построенной сети будет работать эффективно?
В недавнем прошлом вопрос эффективности работы в сети того или иного программного продукта не был актуальным. Сети были небольшими, и программные продук-ты стоили намного дешевле сетевой аппаратуры. Сегодня ситуация кардинальным образом меняется. Во-первых, число компьютеров в сетях быстро увеличивается и локальные сети расширяются до уровня корпоративных. Во-вторых, стоимость программных продуктов, в частности для автоматизации банковской деятельности, не только становится соизмеримой со стоимостью сетевой аппаратуры, но часто превосходит ее. Цена ошибки при выборе прикладного пакета по этой причине существенно возрастает. Разработчики программных продуктов "в пылу конкурентной борьбы" основное внимание уделяют функциональной стороне их работы. Вопросы же эффективности работы прикладных пакетов в сети часто либо вообще опускаются, либо сводятся к оценке только эффективности платформы (СУБД), на которой они разработаны. Для этого чаще всего используются отечественные методики, напоминающие тесты ТРС (Transaction Processing perfomance Council). He подвергая сомнению достоверность таких тестов, отметим, что разработанный на основе очень эффективной платформы программный пакет может работать в сети не столь эффективно.
Ситуация усугубляется еще и тем, что решения о закупке дорогостоящего прикладного программного обеспечения принимаются на достаточно "высоком уровне" людьми, часто далекими от технических вопросов. Вычислительная техника, как правило, ко времени принятия таких решений уже закуплена, сеть построена, средства, выделенные на автоматизацию, потрачены. Таким образом, вся тяжесть проблемы ложится на администратора сети, которому ничего не остается, кроме "латания дыр" в системе и ожидания лучших времен.
Целью настоящей статьи является ознакомление читателей с методикой и программным продуктом AutoUser Simulator, разработанными фирмой PROLAN (Москва). Они предназначены для тестирования прикладного программного обеспечения в сети, а также выбора типа аппаратных средств и архитектуры сети, оптимально удовлетворяющих требованиям прикладного пакета. Мы расскажем также о некоторых результатах, полученных при тестировании пакета RS-Bank фирмы R-Style. Тестирование проводилось фирмой PROLAN по заказу Мосбизнесбанка, который любезно дал разрешение на публикацию полученных результатов.
|
 |
МЕТОДИКА ТЕСТИРОВАНИЯ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Методика тестирования основана на моделировании работы большого числа пользователей, одновременно взаимодействующих с исследуемым прикладным программным продуктом в локальной и(или) глобальной сети. Работа пользователей моделируется на основе автоматической отработки так называемых сценариев. Сценарий представляет из себя текстовый файл, в котором на простом и понятном языке описываются содержание экранов прикладного пакета и клавиатурный ввод, обычно выполняемый пользователем как реакция на конкретное содержание экрана. В сценарии могут быть описаны циклы и ветвления по определенным условиям. Порядок всех записей сценария должен соответствовать последовательности действий пользователя при работе с прикладным программным пакетом. В сценарии описываются также "нештатные" ситуации, например сообщения о сетевой ошибке или выходе из строя сервера. Сценарии бывают индивидуальными для каждого пользователя сети или общими для всех. В ходе эксперимента определяется интенсивность работы пользователей с прикладным пакетом, которая задается, в частности, параметром скорости ввода символов с клавиатуры. В качестве примера сценария можно назвать последовательность действий операциониста банка при вводе платежных поручений.
Все сценарии отрабатываются автоматически под управлением программы AutoUser Simulator. Таким образом моделируется одновременная работа заданного числа станций в сети. При этом измеряется время выполнения циклических операций, описанных в сценарии, а также исследуется поведение сети и сервера. Программа AutoUser Simulator позволяет тестировать прикладные пакеты, работающие в среде NetWare, при условии, что рабочие станции работают под управлением DOS.
Пакет AutoUser Simulator состоит из трех программ: SCEPRO.EXE, AUSER. ЕХЕ, AUMON.EXE и модуля AUSMON.NLM. Программа SCEPRO транслирует сценарий, описанный в текстовом файле, в специальный формат. AUSER является резидентной программой, которая загружается в каждый ком-пьютер сети и отрабатывает сценарий поведения пользователя. Программа AUMON - это специальная оболочка, загружаемая на управляющем компьютере сети (мониторе). Она синхронно запускает все резидентные части программы AUSER и управляет их работой. Кроме того, программа AUMON собирает информацию о времени отработки каждой операции программой AUSER, ведет сетевую статистику (число таймаутов в сети, перегрузок сервера и т. п.), а также позволяет наблюдать и контролировать в реальном времени ход эксперимента. На сервере NetWare может быть загружен модуль AUSMON.NLM, определяющий утилизацию процессора сервера при работе исследуемого прикладного пакета. По окончании работы программа AUMON формирует отчет, который может рассматриваться как паспорт прикладной системы. Отчет представляет из себя текстовый файл, который может быть экспортирован в электронную таблицу для дальнейшей обработки.
При исследовании прикладного пакета наряду с программой AutoUser Simulator желательно применить какоелибо средство, позволяющее оценить трафик непосредственно в канале связи сети. Мы используем для этих целей программу LANalazer for Windows фирмы Novell.
Предлагаемая методика позволяет измерить, в частности, следующие характеристики работы прикладного пакета.
1. Время выполнения операций прикладным пакетом (время реакции системы). Определяется как чистое время без учета задержек между эмулированием нажатия клавиш на клавиатуре, так и полное время выполнения операций. Под операцией мы понимаем любую логически законченную последовательность действий, которая обычно выполняется оператором. Операцией может быть формирование отчета, закрытие баланса, ввод платежного поручения и т. п. Транзакция - это частный случай операции. Если время выполнения транзакции характеризует эффективность работы СУБД, то чистое время выполнения операций, по нашему мнению, характеризует эффективность работы именно прикладного пакета.
2. Текущий, максимальный и средний уровни утилизации процессора сервера при работе заданного числа рабочих станций с исследуемым прикладным пакетом.
3. Значение сетевого трафика в канале связи, возникающего при одновременной работе заданного числа рабочих станций с исследуемым прикладным пакетом.
4. Число таймаутов на рабочих станциях и число перегрузок сервера, возникающих при одновременной работе определенного числа рабочих станций.
Увеличивая интенсивность работы прикладного пакета, можно всего на нескольких станциях сети смоделировать нагрузку в сети и загрузку сервера, которые будут возникать при работе большего числа рабочих станций. Таким образом можно прогнозировать последствия увеличения числа рабочих станций в сети.
Анализируя полученные значения сетевого трафика, время реакции системы (время выполнения операций), число таймаутов на рабочих станциях и загрузку сервера, можно не только сделать выводы о качестве прикладного пакета, но и подобрать архитектуру сети и производительность аппаратных средств, при которых прикладной пакет будет работать с наибольшей эффективностью. Таким образом, пакет AutoUser Simulator позволяет, с одной стороны, проверить, как работает конкретное сетевое прикладное ПО на конкретной сетевой конфигурации в "худших" для себя условиях (при одновременной работе многих пользователей), и, с другой стороны, определить, как будет работать сеть при использовании конкретного прикладного программного продукта.
|
|
|
10 НЕКОТОРЫХ РЕЗУЛЬТАТАХ ТЕСТИРОВАНИЯ ПРИКЛАДНОГО ПАКЕТА RS-BANK
С целью демонстрации описанной выше методики тестирования рассмотрим некоторые результаты исследования прикладного пакета RS-Bank, разработанного фирмой R-Style. Данный пакет предназначен для автоматизации банковской деятельности и реализован на платформе Btrieve. Сетевые конфигурации, в которых проводилось исследование пакета, условно можно разделить на две категории: локальные и глобальные. Локальные конфигурации строились на базе сети Ethernet. Для построения глобальных сетевых конфигураций были использованы два сетевых маршрутизатора NetBuilder II фирмы 3Com, работающих друг с другом по протоколу РРР (Point to Point Protocol) на выделенной двухпроводной линии с модемами Zyxel 1496Eplus. В рамках данной статьи ограничимся рассмотрением части результатов, полученных при работе пакета RS-Bank в режиме ввода и проводки платежных поручений.
|
|
|
Исследуемые сетевые конфигурации
На рис. 1-3 приведены схемы сетевых конфигураций, на которых проходило тестирование. Как в локальной, так и в глобальной конфигурации возможна организация работы прикладного пакета двумя различными способами.
SERVER - файловый сервер: Compaq PROLIANT 1000 ( Pentium-60, RAM - 16 Мбайт, НЖМД -1050 Мбайт Fast SCSI-2, NetFlex-2). Использовался для хранения и обеспечения доступа к файлам программного комплекса RS-Bank. WS - рабочие станции: Compaq Presario-425 ( 486SX-33, RAM - 4 Мбайт, 3COM Etherlink III). Использовались как рабочие станции операционистов банка. HUB-1, HUB-2 - концентраторы 10BASET: LinkBuilder 10bti. Использовались как концентраторы локальной сети Ethernet. LANalyzer - ПК со встроенными средствами анализа сетевого трафика.
Важно отметить, что мы смогли сделать такие выводы только после того, как импортировали все данные из лог файла программы MS Performance monitor в базу данных Trend Analyst, и проанализировали их с помощью встроенной функции корреляционного анализа. (Сделать это "вручную" было бы не реально, т.к. лог файл программы MS Performance содержит более 100 параметров.)
NetBuilder II- сетевые маршрутизаторы NetBullder-ll и модемы: Zyxel U-1496EPIus. Использовались для создания глобальных конфигураций. LANalyzer - ПК со встроенными средствами анализа сетевого трафика.
WinView - сервер приложений: Compaq SystemPro/XL (486DX-50, RAM - 16 Мбайт, НЖМД - 1500 Мбайт Fast SCSI-2, NetFlex-2) или Compaq Presario-425 (486SX-25, RAM - 12 Мбайт, НЖМД - 105 Мбайт IDE, 3COM Etherlink III). Использовался для обеспечения многотерминального доступа к файловому серверу в глобальных конфигурациях. Используемое программное обеспечение: MS-DOS 6.2 - была установлена на рабочих станциях сети;
Windows 3.1 - на управляющей рабочей станции; NetWare 3.12 - на файловом сервере; Citrix Win-View 2.2 - на серверах приложений; LANalyzer for Windows 2.0, Novell, Inc. - был установлен на управляющей рабочей станции; AutoUser Simulation Program 1.0 фирмы PROLAN (AUMON - на управляющей рабочей станции, AUSER загружается на каждой рабочей станции сети); RS-Bank, R-Style - устанавливался на файловом сервере и рабочих станциях сети.
При первом способе организации работы системы клиентская часть пакета RS-Bank загружается в ОЗУ рабочих станций и рабочие станции работают с общими данными, расположенными на сервере NetWare, посылая запросы к находящейся там же СУБД. Мы будем называть такой способ архитектурой "клиент-сервер". (Данный способ организации работы системы не следует путать с принципом работы СУБД, который также называется "клиент-сервер". Мы будем пользоваться термином "клиент-сервер" исключительно для того, чтобы отличать данный способ организации работы от описанного ниже.)
При втором способе клиентская часть пакета RS-Bank загружается в ОЗУ сервера приложений (и работает на нем). Между рабочими станциями и сервером приложений идет обмен только кодами клавиш и обновленными фрагментами изображения на экране. Основной сетевой трафик проходит между сервером приложений и сервером NetWare, на котором располагаются СУБД и общие данные. Мы будем называть такой способ работы архитектурой "терминал-сервер".
На рис. 1 показана локальная сетевая конфигурация, имитирующая локальную сеть банка. На рис. 2 - глобальная сетевая конфигурация, моделирующая связь двух удаленных локальных сетей (LAN-to-LAN) без использования сервера приложений. На рис. 3 можно видеть сетевую конфигурацию, имитирующую связь двух удаленных сетей с использованием сервера приложений.
Во всех сетевых конфигурациях использовался пакет LANalyzer for Windows фирмы Novell, который измерял трафик, создаваемый рабочими станциями в канале связи.
|
|
|
Исследование работы пакета RS-Bank в архитектуре "клиент-сервер"
При исследовании пакета RS-Bank в архитектуре "клиент-сервер" нас интересовали, в частности, следующие вопросы:
- |
какой трафик создает пакет RS-Bank в сети и какова зависимость времени реакции системы от числа одновременно работающих пользователей?
|
- |
возможно ли в принципе использование пакета RS-Bank в глобальных конфигурациях без сервера приложения и если да, то при скольких одновременно работающих удаленных станциях?
|
Для ответа на первый вопрос нами была создана сетевая конфигурация (см. рис. 1), максимально приближенная к реальным конфигурациям в отделениях банка. Мы исследовали работу пакета при одновременном включении от 2 до 12 станций. Учитывая тот факт, что нагрузка на сеть и сервер при одновременной работе 12 пользователей соответствует нагрузке, создаваемой в сети при "нормальной" работе как минимум 30 пользователей (в реальных условиях все операционисты одновременно не работают), можно предположить, что данная сетевая конфигурация моделировала фрагмент локальной сети операционного отдела большого банка.
Прежде чем рассмотреть полученные результаты, отметим некоторую особенность исследованного пакета, выявленную при тестировании. Выполняя операцию проводки банковского поручения, пакет RS-Bank осуществляет поиск отделений банков в файле-справочнике, который находится на сервере. Выяснилось, что при одновременной работе нескольких станций возникает ситуация, когда при попытке одной из станций прочесть данный файл он оказывается захваченным другой станцией. В этом случае пакет RS-Bank выдает сообщение о невозможности доступа к общему файлу, после чего необходимо повторить операцию. Если в локальной конфигурации такая ситуация складывалась относительно редко, то в глобальной конфигурации это бывало достаточно часто. (После тестирования этот недостаток был устранен).
На рис. 4 представлены полученные результаты работы пакета RS-Bank.
График в сегменте сети выражен в килобайтах в секунду и отражает среднюю скорость передаваемой по сети информации всеми станциями. Время цикла выражено в секундах и является средним временем выполнения одной операции проводки банковского поручения каждой рабочей станцией сети (время реакции системы). Число глобальных реакции на цикл отражает среднее количество сообщений о захвате файла-справочника. СКО числа циклов (среднеквадратичное отклонение числа циклов от среднего) показывает, насколько ровно работали все станции в ходе эксперимента.
Видно, что трафик в локальной конфигурации очень незначителен и время реакции системы практически не зависит от числа одновременно работающих пользователей. С увеличением числа пользователей трафик в сегменте растет плавно, но его уровень существенно ниже потенциальной пропускной способности канала связи. Все станции работают ровно, и число глобальных реакций незначительно растет с увеличением количества одновременно работающих пользователей. Утилизация сегмента сети Ethernet (процент используемой пропускной способности сети) при одновременной работе 12 станций не превышала 5%.
На основании полученных результатов можно сделать следующие выводы:
во-первых, пакет RS-Bank загружает сеть очень незначительно; во-вторых, если в сетевых конфигурациях пропускная способность канала связи выше, чем тот трафик, который потенциально могут создать пользователи, то влияние захвата общего ресурса (в данном случае файла-справочника) на комфортность работы пользователей незначительно. Маловероятно, чтобы именно пропускная способность канала связи была "узким местом" локальной сети, где эксплуатируется пакет RS-Bank, поэтому основное внимание следует уделять производительности сервера.
Повторив эксперимент при большем количестве рабочих станций, можно было бы установить число рабочих станций в сети, при котором факт захвата общего ресурса начинает влиять на время реакции системы и/или время реакции начинает существенно увеличиваться из-за ограничения производительности сервера либо его дисковой подсистемы. Таким образом можно проектировать архитектуру сетей и подбирать оборудование с учетом требований прикладного программного обеспечения.
Для ответа на вопрос о возможности использования пакета RS-Bank в глобальной конфигурации без сервера приложений была создана сетевая конфигурация, представленная на рис. 2. Канал связи в этой конфигурации формировался с помощью маршрутизаторов NetBuilder II, работающих по протоколу РРР, и модемов Zyxel 1496EPlus, обеспечивающих канальную скорость передачи данных до 19 200 Бод. В качестве канала связи использовалась выделенная двухпроводная линия. NetBuilder II переводился в оптимальный с точки зрения пропускной способности режим (при используемых модемах): прозрачный мост (transparent bridge), скорость канала связи 19 200 Бод, включена компрессия Link Level. Оптимальность данного режима была определена в результате предварительного исследования маршрутизаторов NetBuilder II. (Следует иметь в виду,что подобная глобальная сетевая конфигурация является не вполне реальной. С одной стороны, при использовании реального "зашумленного" канала связи время реакции системы может быть гораздо больше. С другой стороны, используемые модемы существенно ограничивают потенциальную производительность работы маршрутизаторов NetBuilder II.)
Из анализа результатов тестирования пакета RS-Bank в глобальной конфигурации (рис. 4) видно, что при увеличении числа рабочих станций трафик плавно растет и при восьми станциях выходит на постоянный уровень. Максимальная пропускная способность канала связи составила 8 Кбайт/с. Число глобальных реакций намного больше, чем в локальной конфигурации, но когда стащий меньше восьми, это не оказывает существенного влияния на время реакции системы (на среднее время цикла). Станции работают неровно.
Таким образом, когда в сетевой конфигурации работает медленный канал связи и при этом станции имеют некоторый общий ресурс на сервере, приемлемое время реакции может быть достигнуто только в том случае, если пропускная способность канала связи будет тем не менее выше, чем трафик, который потенциально могут создать рабочие станции сети. При медленном канале связи каждая рабочая станция вынуждена проводить частый опрос "захваченного" файла; тем самым она требует большей пропускной способности канала связи и еще больше его загружает. При этом время реакции системы существенно увеличивается и при определенном числе рабочих станций (в данном случае больше восьми) "нормальная" работа становится невозможной.
Мы подробно остановились на этой особенности, так как считаем, что данный результат можно применить к любому прикладному программному обеспечению, работающему в глобальной конфигурации в архитектуре "клиент-сервер", если при его работе осуществляется удаленный доступ к общим файлам или записям с их захватом и не принято специальных мер для решения этой проблемы. Одним из возможных подходов к ее решению является организация работы прикладного пакета в архитектуре "терминал-сервер".
|
|
|
Исследование работы пакета RS-Bank в архитектуре "терминал-сервер"
При тестировании пакета RS-Bank в архитектуре "терминал-сервер" нас интересовали такие вопросы:
- |
насколько комфортными будут условия работы пользователя с пакетом RS-Bank в глобальной конфигурации при использовании сервера приложений?
|
- |
как влияет производительность и объем оперативной памяти сервера приложений на время реакции системы ?
|
Сервером приложений в экспериментах служил компьютер Compaq SystemPro/XL с установленной на нем системой Citrix WinView 2.2, расчитанной на 10 пользователей. Объем установленной на нем оперативной памяти (16 Мбайт) позволял создать только семь рабочих сеансов без использования виртуальной памяти. Таким образом, мы смогли определить, как влияет виртуальная память на эффективность работы прикладного пакета. (Виртуальной называется память, которая физически расположена на жестком диске, но используется сервером приложений как оперативная.)
На рис. 5 приведена зависимость времени реакции системы от числа одновременно работающих пользователей в глобальной конфигурации в архитектуре "терминал-сервер" и в локальной конфигурации в архитектуре "клиент-сервер".
Из сравнения полученных результатов видно, что время реакции системы в глобальной конфигурации при десяти одновременно работающих пользователях менее чем на 20% превосходит время реакции системы в локальной конфигурации. Это объясняется тем, что при работе с сервером приложений трафик, создаваемый пользователями, оказывается ниже, чем потенциальная пропускная способность канала связи. Именно по этой причине низкая потенциальная пропускная способность канала связи не оказала существенного влияния на время реакции системы.
Из полученных результатов следует, что при использовании сервера приложений в глобальной конфигурации время реакции прикладной системы становится близким к времени реакции, характерному для локальной конфигурации.
Была протестирована работа системы в архитектуре "терминал-сервер" при шести рабочих станциях (виртуаль-ная память не использовалась) и при десяти рабочих станциях (с использо-ванием виртуальной памяти). Выявлено, что виртуальная память на сервере приложений увеличивает время реакции системы менее чем на 10%.
Чтобы выяснить, каким образом производительность сервера приложений влияет на время реакции системы, измеряли время реакции, используя в качестве серверов приложений два типа компьютеров: Compaq SystemPro/XL и Compaq Presario. При измерениях количество одновременно работающих пользователей не превышало пяти.
Время реакции системы (рис. 6), при использовании более мощного компьютера (Compaq SystemPro) оказалось на 20% лучше, чем в случае менее мощного компьютера (Compaq Presario).
На основании полученных результатов мы пришли к выводу, что эффективным способом повышения производительности работы прикладного пакета в глобальных конфигурациях в архитектуре "терминал-сервер" является повышение производительности компьютеров, используемых в качестве серверов приложений. Думаю, что это будет справедливо для любого прикладного пакета, реализованного на основе Btrieve.
|
|
|
ЗАКЛЮЧЕНИЕ
В этой статье не преследовалась цель рекламы или антирекламы пакета RS-Bank. Мы исследуем прикладные пакеты только с точки зрения эффективности их работы в различных сетях. Функциональная сторона вопроса лежит вне нашей компетенции. Хочется думать, что описанная методика и полученные результаты могут быть интересны не только пользователям пакета RS-Bank, но и широкому кругу системных интеграторов, внедряющих различные прикладные пакеты в сложных сетевых конфигурациях. К ней может возникнуть интерес и у фирм, разрабатывающих прикладные пакеты, так как она позволяет тестировать их на ранних стадиях разработки. Подобные исследования прикладных пакетов позволяют не только проектировать сети и приобретать оборудование в соответствии с требованиями прикладного программного обеспечения, но и выявлять разного рода ошибки. Имея набор стандартных сценариев для конкретного прикладного пакета, можно формализовать приемку прикладного пакета или сети у исполнителя перед их внедрением в промышленную эксплуатацию. Это экономически более выгодно, чем исправлять разного рода ошибки в процессе промышленной эксплуатации системы.
|
 |
наверх
|
|
