Отчет по лабораторной работе №2 Ревизия: 1 История изменений



Скачать 270.41 Kb.
Дата05.09.2014
Размер270.41 Kb.
ТипОтчет


Разработка многопроцессного приложения для анализа логов web-сервера Apache

Отчет по лабораторной работе №2

Ревизия: 0.1


История изменений


30.01.2011 – Версия 0.1. Первичный документ. Влад Ковтун

Содержание


История изменений 2

Содержание 3

Лабораторная работа 2. Разработка многопроцессного приложения для анализа логов web-сервера 5

Постановка задачи 5

Цель 5

Задачи 5


Вход 5

Пример 6


Вывод 6

Требования 6

Алгоритм 6

Управляющий процесс 9

Обзор 9

Интерфейс 9



Обработка 10

Процесс первичного анализа 12

Обзор 12

Интерфейс 12

Обработка 12

Процесс вторичного анализа 12

Обзор 12

Интерфейс 12

Обработка 13

Процесс формирования результата 13

Обзор 13

Интерфейс 13

Обработка 14

Хранилища данных 14

Обзор 14

Структура хранилища первичных данных 14

Структура хранилища вторичных данных 15

Обработка 15

Программная реализация 15

Обзор 15


Работа с БД 15

Доступ к данным 15

Работа с данными 15

Межпроцессное взаимодействие 15

Обзор 15

Тестирование 16

Эксперимент 16

Описание экспериментальной установки 16

Аппаратное обеспечение 16

Программное обеспечение 17

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

Выводы 18

Литература 19

Лабораторная работа 2. Разработка многопроцессного приложения для анализа логов web-сервера

Постановка задачи

Цель


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

Задачи


1. Ознакомиться с понятиями процессов и потоков в ОС.

2. Ознакомиться с понятиями межпроцессного и межпоточного взаимодействия.

3. Разработать консольное распределенное приложение для параллельного анализа нескольких файлов логов web-сервера Apache.

3.1. На основе файлов логов web-сервера, следует сформировать следующую статистику:



  • количество уникальных посетителей за каждый день.

  • наиболее популярные браузеры.

  • наиболее популярные ОС.

  • наиболее популярные страницы (ссылки).

  • наиболее активные пользователи (IP) за каждый день.

4. Разработать тестовое приложение, которое формирует все возможные тестовые комбинации ключей командной строки для приложения.

5. Провести исследование разработанного приложения.

5.1.

Оценить производительность приложения, при различном количестве процессов чтения и анализа. Количество процессов следует изменять от 1 до 8.

6. Оформить функциональную спецификацию на приложение. В функциональной спецификации обязательно указать, каким образом производится тестирование на корректность.

7. Оформить отчет к лабораторной работе.

Вход


В качестве входных данных предлагается использовать файлы логов web-сервера Apache, которые сжаты с помощью архиватора ZIP (GZIP). Эти файлы находятся на общедоступном сетевом хранилище, что позволяет получить к ним доступ любой рабочей станции данной корпоративной сети.

Для управления приложением предлагается использовать следующие ключи командной строки:



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

  • /if: - перечисление имен файлов логов через пробел, которые необходимо проанализировать. Файлы обязаны, находится в директории указанной с помощью ключа /id. Данный ключ позволяет осуществлять выборочный анализ файлов логов.

  • /o: – полный путь к файлу, либо имя файла, который будет хранить отчет. Если данный параметр не указывается, то вывод производится на экран.

  • /r: - перечисляются, через пробел, IP адреса компонентов (с указанием портов), которые будут производить чтение данных из файлов.

  • /a: - перечисляются, через пробел, IP адреса компонентов (с указанием портов), которые будут производить анализ данных из хранилища с результатами первичного анализа.

  • /g: - указывается IP адрес компонента (с указанием порта), который будут производить формирование финального отчета, на основе данных из хранилища результатов первичного анализа.

  • /s1: - указывается IP адрес (или имя сервера) компонента (с указанием порта), который является хранилищем данных – результатов первичного анализа. Кроме того, через пробел указывается имя пользователя и его пароль, под которым следует производить подключение. В случае отсутствия имени пользователя и пароля, подразумевается, что будет использоваться windows-аутентификация.

  • /s2: - указывается IP адрес (или имя сервера) компонента (с указанием порта), который является хранилищем данных – результатов вторичного анализа. Кроме того, через пробел указывается имя пользователя и его пароль, под которым следует производить подключение. В случае отсутствия имени пользователя и пароля, подразумевается, что будет использоваться windows-аутентификация.

  • /start: - указывается дата, с которой интересует информация в логах. Если дата не указана, то берется самая первая дата из записей логов.

  • /finish: - указывается дата, до которой интересует информация в логах. Если дата не указана, то берется самая последняя дата из записей логов.

  • /? - вывод информации о допустимых ключах командной строки.

Параметры – размеры буферов, настраиваются индивидуально для каждого компонента.

Пример


Анализ 9 файлов логов web-сервера Apache, которые находятся в публичном хранилище \\file-storage\logs\ результат анализа выводится в файл \\file-storage\reports\report.dat.

C:/>analyser.exe /id:”\\file-storage\logs\” /if:access-www.1.log access-www.2.log access-www.3.log access-www.4.log access-www.5.log access-www.6.log access-www.7.log access-www.8.log access-www.9.log /r:192.168.1.20 192.168.1.21 /a:192.168.1.20:8800 192.168.1.22 /g:192.168.1.22:8800 /s1:192.168.1.23 /s2:192.168.1.24 /o:”\\file-storage\reports\report.dat


Вывод


Во время работы приложения, рекомендуется выводить информацию о статусе приложения, а также о корректности его работы на консоль.

Другими словами, необходимо анализировать, сколько процентов из каждого файла – проанализировано.

Допускается перенаправление вывода консоли в текстовый файл, например:

C:/>analyser.exe /id:”\\file-storage\logs\” /if:access-www.1.log access-www.2.log access-www.3.log access-www.4.log access-www.5.log access-www.6.log access-www.7.log access-www.8.log access-www.9.log /r:192.168.1.20 192.168.1.21 /a:192.168.1.20:8800 192.168.1.22 /g:192.168.1.22:8800 /s1:192.168.1.23 /s2:192.168.1.24 /o:”\\file-storage\reports\report.dat >console.txt


Требования


  • Архитектура приложения строится по модульному принципу.

  • За основу принимается стандартная библиотека С++ (в случае разработки на C++).

  • Рекомендуется использовать защищенные ресурсы и указатели.

  • Обязательным является обработка исключений.

  • Во время работы приложения обязательным является отображение информации о статусе приложения, т.е. оно работает, обработано столько-то процентов текста.

  • Следует предусмотреть возможность работы приложения в отладочном режиме, когда вся информация заносится в лог приложения. Допускается ведение персонального лога для каждого из процессов (потоков).

  • Исходный код обязан быть комментирован. Для C# следует использовать нотацию Microsoft XML Documentation [1], для C++ следует использовать нотацию doxygen [2].

Алгоритм


Данное приложение предлагается строить как распределенное приложение, разнесенное на несколько различных рабочих станций (серверов).

Предполагается задачу анализа следует разделить на следующие подзадачи:



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

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

  • Открытие файла лога, разархивирование его «на лету» чтение строки. Результаты первичного анализа заносятся в хранилище. Как правило, данные накапливаются во внутреннем буфере процесса чтения и заносятся в хранилище порциями. Размер порции определяется пропускной способностью сетевого соединения и производительностью (загруженностью) хранилища данных. По завершению исходных данных (достигнут конец файла)

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

  • Хранение данных-результатов первичного анализа.

Т.к. результатами первичного анализа будет пользоваться множество рабочих станций вторичного анализа, то наиболее приемлемым вариантом хранилищем данных, является сервер БД, например Microsoft SQL Server. Данные следует хранить в единой таблице. Отметим, что данная таблица будет постоянно модифицироваться, в нее будут добавляться записи (после первичного анализа) и удаляться записи (после вторичного анализа). Тонкая настройка сервера БД для решения задачи активной модификации и активной выборки, выходит за рамки данной работы.

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

Т.к. результатами вторичного анализа будет пользоваться несколько рабочих станций формирования результатов, то наиболее приемлемым вариантом хранилищем данных, является сервер БД, например Microsoft SQL Server. В него интегрирован сервис интеллектуального анализа данных. Отметим, что данная БД будет постоянно модифицироваться, в нее будут добавляться записи (после вторичного анализа). Тонкая настройка сервера БД для решения задачи активной модификации, выходит за рамки данной работы.

  • Формирование заданного результата по результатам вторичного анализа.

Что касается задачи получения заданного результата, то в зависимости от поставленной задачи, возможна:

  • постепенная работа с постоянно добавляющимися данными (результат формируется постепенно, по мере поступления данных);

  • работа уже с полностью добавленными данными (результат формируется лишь тогда, когда имеются все данные).

Становится понятно, что решение каждой задачи, можно поставить перед отдельной рабочей станцией (сервером), что позволит выполнять их параллельно. Кроме того, на одной рабочей станции, в зависимости от ее производительности, можно запустить несколько идентичных процессов (например, первичного анализа), так и различных процессов (например, первичного анализа и вторичного).

Остановимся на управляющем процессе. Задачи, которые решает управляющий процесс:



  • Взаимодействие с пользователями.

  • Общая координация (синхронизация), всех распределенных процессов.

  • Отслеживание статуса обработки первичных и вторичных данных, в процентах.

  • Подготовка хранилища первичного анализа данных. Например, произвести его полную очистку.

  • Подготовку хранилища вторичного анализа данных. Например, произвести его полную очистку.

  • Для приложения первичного анализа указывать:

  • Где находится файловое хранилище.

  • Какие файлы следует проанализировать.

  • Где находится хранилище промежуточных данных.

  • Для приложения вторичного анализа указывать:

  • Где находится хранилище промежуточных данных.

  • Где находится хранилище результирующих данных.

  • Для приложения формирования результатов:

  • Где находится хранилище результирующих данных.

  • Какие именно результаты интересны.

  • В каком виде их следует представить.

  • Куда положить необходимые результаты.

На рис. 1 представлена упрощенная UML диаграмма последовательностей, которая демонстрирует, на примере, параллельный анализ 3-х файлов логов.

Рис. 1. Диаграмма последовательностей

На рис. 2, приведем упрощенную UML диаграмму развертывания для случая:


  • управляющее приложение;

  • 2-х рабочих станций чтения и первичного анализа;

  • 2-х рабочих станций вторичного (окончательного) анализа;

  • хранилища данных-результатов первичного анализа;

  • хранилище данных-результатов вторичного анализа;

  • приложение формирование результатов.

Рис. 2. Диаграмма развертывания распределенного приложения

Далее, более детально, остановимся на алгоритме каждого приложения.

Управляющий процесс

Обзор


Управляющий процесс производит:

  • Взаимодействие с пользователями.

  • Общая координация (синхронизация), всех распределенных процессов.

  • Подготовка хранилища первичного анализа данных. Например, произвести его полную очистку.

  • Подготовку хранилища вторичного анализа данных. Например, произвести его полную очистку.

  • Для приложения первичного анализа указывать:

  • Где находится файловое хранилище.

  • Какие файлы следует проанализировать.

  • Где находится хранилище промежуточных данных.

  • Для приложения вторичного анализа указывать:

  • Где находится хранилище промежуточных данных.

  • Где находится хранилище результирующих данных.

  • Для приложения формирования результатов:

  • Где находится хранилище результирующих данных.

  • Какие именно результаты интересны.

  • В каком виде их следует представить.

  • Куда положить необходимые результаты.

Интерфейс


В качестве входных данных поступает:

  • Адрес сетевого ресурса, где расположены файлы логов для последующего анализа. Например, «\\file-server\logs». В качестве развития данного подхода, возможно использование FTP сервера в качестве файлового хранилища.

  • Массив со списком имен файлов логов. Например, «access-www.1.log» или же сжатые «access-www.1.gz».

  • Массив со списком IP адресов процессов-читателей. Например, «192.1681.22» или же с указанием порта «192.168.1.22:8800».

  • Массив со списком IP адресов процессов-анализаторов. Например, «192.1681.22» или же с указанием порта «192.168.1.22:9000».

  • Строка подключения к серверу БД – хранилища первичного анализа.

  • Строка подключения к серверу БД – хранилища вторичного анализа.

  • Начальная и конечная дата, за которые интересны результаты анализа.

Для проверки состояния выполняющейся задачи, предполагается возможность проверки текущего статуса:

  • Ожидание задания.

  • Выполняется анализ.

  • Завершено выполнение задания.

  • Инициализируется задание.

  • Кроме того, на данный сервис можно возложить задачу инициализации БД.

Обработка


Опишем алгоритм функционирования управляющего процесса в виде блок-схемы на рис. 4.

Рис. 3. Блок-схема алгоритма управляющего процесса

Подпрограмма проверки параметров командной строки проверяет:


  • Корректность указанных параметров.

  • Существование указанных файлов.

  • Доступность выбранных хранилищ данных для результатов первичного и вторичного анализа.

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

Подпрограмма очистки (инициализации) БД для результатов первичного анализа, ровно как и вторичного анализа, занимается подготовкой БД к занесению в них результатов анализа.

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



Следует обратить внимание, что процессы вторичного анализа запускаются лишь после того, как будет прочитано и обработано (например, для самого простого случая) 100% хотя бы одного файла-лога.

Процесс первичного анализа

Обзор


Данный процесс производит чтение строки из файла-лога. Отметим, что задача может усложниться, если данному процессу потребуется читать содержимое сжатого текстового лог-файла с помощью архиватора ZIP (GZIP). Прочитанная строка заносится во внутренний буфер и по достижению граничного числа записей, например 256 строк, происходит их занесение в БД первичного анализа.

Интерфейс


В качестве входных данных поступает:

  • Адрес сетевого ресурса, где расположены файлы логов для последующего анализа. Например, «\\file-server\logs». В качестве развития данного подхода, возможно использование FTP сервера в качестве файлового хранилища.

  • Массив со списком имен файлов логов. Например, «access-www.1.log» или же сжатые «access-www.1.gz».

  • Строка подключения к серверу БД – хранилища первичного анализа.

Для проверки состояния выполняющейся задачи, предполагается возможность проверки текущего статуса:

  • Ожидание задания.

  • Выполняется анализ.

  • Завершено выполнение задания.

  • Инициализируется задание.

  • Кроме того, на данный сервис можно возложить задачу инициализации БД.

Обработка


Во время первичного анализа предполагается:

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

  • Каждую прочитанную строку сохраняют во временном хранилище (очереди или массиве).

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

  • Отметим, что задача синхронизации множественного доступа к хранилищу, возлагается непосредственно на сам сервер БД.

  • Здесь же, следует описать алгоритмы (блок-схемы) программы в целом и всех подпрограмм.

Процесс вторичного анализа

Обзор


Данный процесс производит чтение данных из хранилища результатов первичного анализа. Отметим, что предполагается чтение сразу до 256 записей (строки из файла-лога) за один раз, что позволит сэкономить время на блокировках БД в результате множественного доступа. Прочитанный результат первичного анализа разбирается построчно (разбивается на составляющие подстроки, согласно описания формата записи лог-файла). Результаты разбора строк, также заносятся во временный буфер, и по достижении 256 записей в буфере, заносятся в БД вторичного анализа.

Интерфейс


В качестве входных данных поступает:

  • Строка подключения к серверу БД – хранилища результатов первичного анализа.

  • Строка подключения к серверу БД – хранилища результатов вторичного анализа. Кстати, в зависимости от производительности сервера БД, возможно совмещение хранилища первичного и вторичного на одном сервере БД.

Для проверки состояния выполняющейся задачи, предполагается возможность проверки текущего статуса:

  • Ожидание задания.

  • Выполняется анализ.

  • Завершено выполнение задания.

  • Инициализируется задание.

  • Кроме того, на данный сервис можно возложить задачу инициализации БД вторичного анализа.

Обработка


Во время вторичного анализа предполагается:

  • Для всех выбранных записей их первичного хранилища данных, необходимо выполнить их полное разбиение на составные части, согласно описания лог-записи.

  • Результаты разбора следует занести во временный структурированный массив. По достижении массивом заданного граничного размера, например 256, следует произвести перенос его содержимого в БД вторичного анализа.

  • Разобранные записи следует удалить из БД первичного анализа (Опционально, зависит от объема данных, которые следует хранить на данном сервере. Отметим, что производительность сервера БД резко падает в случае большого количества запросов на создание и удаление записей. Допускается хранение данных первичного анализа до окончания анализа всех файлов-логов в рамках задания).

  • Отметим, что задача синхронизации множественного доступа к хранилищам (первичному и вторичному), возлагается непосредственно на сам сервер БД.

  • Здесь же, следует описать алгоритмы (блок-схемы) программы в целом и всех подпрограмм.

Процесс формирования результата

Обзор


Данный процесс формирует запросы к серверу БД содержащему результаты вторичного анализа, по его окончанию, что бы:

  • Определить количество уникальных посетителей за каждый день. Уникальность посетителей определяется по уникальности их IP. Другими словами посчитать количество различных IP адресов.

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

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

  • Отранжировать все ссылки, которые встречались в файлах-логов, по убыванию количества их посетителей. С целью оптимизации нагрузки на сервер БД, предполагается возле каждой строки – адреса хранить ее целочисленный образ (хеш-образ). Дальнейшее ранжирование допускается выполнять непосредственно по образу строки. С другой стороны, имеет смысл показывать лишь первых 100 записей, что также позволит снизить нагрузку на сервер БД.

  • Отранжировать все IP, которые встречались в файлах-логов, по убыванию количества их появления. С другой стороны, имеет смысл показывать лишь первых 100 записей, что также позволит снизить нагрузку на сервер БД.

Интерфейс


В качестве входных данных выступает:

  • Строка подключения к серверу БД – хранилища результатов вторичного анализа.

  • Запрос на количество уникальных посетителей. Указывается, за какой период времени следует формировать результат.

  • Запрос на дату и время первой и последней записей во всех анализируемых записях лог-файлов.

  • Наиболее популярные браузеры на заданный промежуток времени.

  • Наиболее популярные ОС на заданный промежуток времени.

  • Наиболее популярные страницы (ссылки) на заданный промежуток времени.

  • Наиболее активные пользователи (IP) на заданный промежуток времени.

В качестве выходных данных выступает:

  • Количество уникальных посетителей на заданный промежуток времени.

  • Наиболее популярные браузеры на заданный промежуток времени.

  • Наиболее популярные ОС на заданный промежуток времени.

  • Наиболее популярные страницы (ссылки) на заданный промежуток времени.

  • Наиболее активные пользователи (IP) на заданный промежуток времени.

Для проверки состояния выполняющейся задачи, предполагается возможность проверки текущего статуса:

  • Ожидание задания.

  • Выполняется анализ.

  • Завершено выполнение задания.

  • Инициализируется задание.

Кроме того, на данный сервис можно возложить задачу инициализации БД.

Обработка


  • Здесь же, следует описать алгоритмы (блок-схемы) программы в целом и всех подпрограмм.

Хранилища данных

Обзор


В качестве хранилища данных предполагается использовать сервис, который реализует:

  • Транзакционность работы с данными.

  • Целостность данных.

  • Синхронизацию множественных подключений при работе с общими данными.

  • Поддерживает большие объемы хранимых данных.

Как правило, такие задачи эффективно могут решаться серверами (системами управления) БД.

Структура хранилища первичных данных


На рис. 4 приведена ER-диаграмма первичного хранилища данных.

Рис. 4. ER-диаграмма БД первичного хранилища

В таблице 1 представлено описание таблицы LogsTbl, в которой перечисляются имена всех файлов-логов, которые были прочитаны и проанализированы.

Таблица 1. Описание полей таблицы LogsTbl



Поле

Тип

Описание

Id

int

Уникальный, автоинкрементный, идентификатор данной записи.

Name

String(256)

Имя файла лога

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

Таблица 2. Описание полей таблицы LinesTbl



Поле

Тип

Описание

Id

int

Уникальный, автоинкрементный, идентификатор данной записи.

TblId

int

Идентификатор файла-лога, из какого прочитана строка.

Line

String(4096)

Строка из файла-лога.

Структура хранилища вторичных данных


Аналогичным образом следует описать структуру хранилища вторичных данных.

Обработка


Здесь же, можно описать логику (алгоритмы) всех хранимых процедур, если уже принято решение об их применении.

Программная реализация

Обзор


При разработке приложения, предполагается использовать среду разработки Microsoft Visual Studio 2005, а также язык программирования высокого уровня Microsoft C#/C++. За основу следует взять Microsoft .Net Framework 2.0. В качестве сервера БД предполагается использовать Microsoft SQL Server 2005.

Кроме того, за основу реализации распределенных вычислений предлагается взять вызовы RPC реализованные посредством:



  • Microsoft Web Service [5].

  • gSOAP [4].

  • И т.д.

  • Другими словами, все приложения первичного, вторичного анализа и формирования результатов, будут представлять собой web service, доступный в рамках локальной сети (отметим, что данное распределенное приложение может быть эффективно реализовано и в рамках сети Internet).

Работа с БД

Доступ к данным


Доступ к данным предполагается производить посредством Microsoft ADO.NET, а точнее через Microsoft .Net Framework Provider, что позволит легко реализовать быстрый доступ к данным и обеспечить целостность.

За основу будет взята надстройка над ADO.NET, которая позволит использовать классы Connection для подключения к источнику данных и Command для работы с данными (добавление, удаление и модификация).

Отметим, что взаимодействие с сервером БД следует производить через сетевой протокол TCP/IP, в качестве исключения можно использовать именованные каналы.

Работа с данными


Для поддержания целостности БД, следует воспользоваться транзакциями при добавлении/удалении/модификации данных из нескольких таблиц. Наиболее приемлемым способом поддержки транзакций, является использование хранимых процедур.

Межпроцессное взаимодействие

Обзор


За основу межпроцессного взаимодействия следует взять сетевое взаимодействие по протоколу TCP/IP через протокол HTTP посредством технологии Web-сервисов. Данный подход позволит достаточно гибко добавлять рабочие станции первичного, вторичного и конечного анализа (формирования результатов), в случае увеличения объемов данные (файлов логов), а также усложнения процедур анализа и формирования результатов.

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


Тестирование


Тестирование приложения осуществляется в несколько этапов:

  • Разработка Unit Test (NUnit Test) в рамках каждого проекта (приложения). Данный подход позволит проверить корректность реализации алгоритмов.

  • Проведение функционального тестирования.

  • Проведение системного тестирования, что позволит проверить корректность функционирования всей системы в целом.

  • Проведение нагрузочного тестирования, что позволит проверить: какие нагрузки (мощность процессора, объем оперативной памяти, объем постоянной памяти, пропускная способность сетевых соединений) способны выдерживать узлы системы. Что в свою очередь позволит четко сформировать требования к аппаратному обеспечению реальной системы, а также выявить узкие места и более точно построить диаграмму развертывания.

Эксперимент

Описание экспериментальной установки

Аппаратное обеспечение


Компьютер

Описание

Управляющий компьютер

CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz

RAM: DDR2 2Gb

HDD: Seagate 500 Gb SATA II ST9500420AS

LAN: Gigabit Ethernet Marvell Yukon 88E8055



Сервер БД (первичные результаты)

CPU:

RAM:


HDD:

LAN:


Сервер БД (вторичные результаты)

CPU:

RAM:


HDD:

LAN:


Сервер первичного анализа

CPU:

RAM:


HDD:

LAN:


Сервер вторичного анализа

CPU:

RAM:


HDD:

LAN:


Сервер формирования результатов

Является Управляющий компьютер

Коммутатор

Gigabit Ethernet D-Link 000

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


Компьютер

Описание

Управляющий компьютер

OS: Microsoft Windows XP Professional Server Service Pack 3

Platforms/Frameworks: .NET Framework v2.0

Components: Microsoft Information Server v6.0


Сервер БД (первичные результаты)

OS: Microsoft Windows 2003 Server Service Pack 3

Platforms/Frameworks: .NET Framework v2.0

Components: Microsoft SQL Server 2005 Standard Edition


Сервер БД (вторичные результаты)

OS: Microsoft Windows 2003 Server Service Pack 3

Platforms/Frameworks: .NET Framework v2.0

Components: Microsoft SQL Server 2005 Standard Edition


Сервер первичного анализа

OS: Microsoft Windows 2003 Server Service Pack 3

Platforms/Frameworks: .NET Framework v2.0

Components: Microsoft Information Server v6.0


Сервер вторичного анализа

OS: Microsoft Windows 2003 Server Service Pack 3

Platforms/Frameworks: .NET Framework v2.0

Components: Microsoft Information Server v6.0


Сервер формирования результатов

Является Управляющий компьютер

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


Для проведения эксперимента была развернута Gigabit Ethernet сеть на базе компьютеров с описанной конфигурацией и программным обеспечением.

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



  • Количество процессов.

  • Количество потоков.

  • % загрузки каждого процессора.

  • % загрузки оперативной памяти.

  • Общая нагрузка на компьютер.

  • Активность дисковой подсистемы.

Кроме того, при разработке приложений была заложена возможность отслеживания:

  • Времени выполнения каждого задания.

  • Времени выполнения задания в целом.

  • В таблице 3 приведены результаты эксперимента для конфигурации: управляющий компьютер(1)-читатель(2)[2]-хранилище1(1)-анализатор(2)[4]-хранилище2(1), где читатель(2)[2] – используется 2 компьютера, на каждом из которых запущено 2 процесса для чтения данных из лог-файлов; анализатор(2)[4] – используется 2 компьютера, на каждом из которых запущено по 4 процесса для анализа данных из хранилища1.

Таблица 3. Время выполнения задания для конфигурации управляющий компьютер(1)-читатель(2)[2]-хранилище1(1)-анализатор(2)[4]-хранилище2(1)



Параметры

Управляющий

Читатель

Храни-лище1

Анализатор

Храни-лище2

Всего

Ws1

Ws2

Ws3

Ws4

1

Время, с





































2

Память, Мб





































Изменим конфигурацию приложения – увеличим (уменьшим) число параллельных процессов для компонента читатель и анализатор, результаты приведем в таблице 4.

Таблица 4. Время выполнения задания для различных конфигураций управляющий компьютер(1)-читатель(2)[M]-хранилище1(1)-анализатор(2)[N]-хранилище2(1)



Время, с

M

N




1

2

3

4

5

6

7

8

1

























2

























3

























4

























5

























6

























7

























8

























Из таблицы 4 видно, что наибольшая производительность распределенного приложения достигается при: необходимо указать значения M и N. Дальнейшее увеличение числа процессов чтения и анализа не приводит к росту производительности приложения в целом, потому что здесь следует указать почему (например, пропускная способность сети не позволяет оперировать объемами данных, недостаточное количество памяти на рабочих станциях … таких-то компонентов, недостаточная производительность хранилищ данных, и т.д.)

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

Выводы


В результате выполнения лабораторной работы можно сделать следующие выводы:

1. Предложена архитектура распределенного приложения для анализа лог-файлов Apache в виде web-сервисов: управляющий компьютер(1)-читатель(2)[2]-хранилище1(1)-анализатор(2)[4]-хранилище2(1). Для компонентов чтения и первичного анализа, а также приложения вторичного анализа распределенного приложения, предложена архитектура распараллеливания посредством многопроцессного выполнения заданий.

2. Разработаны архитектуры для:


  • Управляющее приложение и формирующее финальный отчет.

  • Приложение чтения и первичного анализа.

  • Приложение вторичного анализа.

  • В каждом из указанных приложений, используются буферы для хранения:

  • Результатов чтения из файла.

  • Промежуточных результатов первичного анализа перед занесением в БД.

  • Результатов выборки из БД хранилища первичных результатов.

  • Промежуточных результатов вторичного анализа перед занесением в БД.

3. Предложена ER-модель обеих хранилищ промежуточных данных, а также разработаны хранимые процедуры для работы с данными. При добавлении и модификации данных используется транзакционная модель, что позволило обеспечить целостность хранилища.

4. Исследована производительность распределенного приложения и его компонентов для конфигурации: управляющий компьютер(1)-читатель(2)[M]-хранилище1(1)-анализатор(2)[N]-хранилище2(1). Оптимальным, по производительности, является такое соотношение M и N. Отметим, что данное значение подбиралось эмпирически, для выбранных конфигураций рабочих станций и сетевого оборудования.

5. Изменение объемов буферов для хранения промежуточных данных, позволил добиться оптимальной производительности распределенного приложения при следующих значениях буферов:


  • Процесс чтения и первичного анализа. Размер буфера для хранения прочитанных строк из файла.

  • Процесс чтения и первичного анализа. Количество записей, готовых к занесению в БД (хранилище первичных результатов анализа).

  • Процесс вторичного анализа. Число записей, считываемых из БД (хранилище первичных результатов анализа).

  • Процесс вторичного анализа. Число записей, заносимых в БД (хранилище вторичных результатов анализа).

6. и т.д.

Литература


1. Microsoft Developer Network. URL: http://www.msdn.com

2. Формирование документации к исходному коду с помощью средства doxygen. URL: www.nrjetix.com/r-and-d/lectures

3. Описание формата лога web-сервера URL: http://www.oglib.ru/apman/logs.html

4. gSOAP. URL: http://gsoap2.sourceforge.net/

5. Your furst C# Web Service. URL: http://www.codeproject.com/KB/webservices/myservice.aspx

6. Другие источники литературы …



Последняя модификация: Vlad Kovtun

Дата последней модификации: 14.2.2011 09:55:00 AM



© NRJETIX 2000 - 2008



Похожие:

Отчет по лабораторной работе №2 Ревизия: 1 История изменений iconОтчет по лабораторной работе №2 по дисциплине «Цифровая обработка сигналов»
Ознакомиться с теоретическим введением и дополнительными материалами к лабораторной работе
Отчет по лабораторной работе №2 Ревизия: 1 История изменений iconОтчет по лабораторной работе. Отчет по работе включает
Цель работы: изучить тип указатель; получить навыки в организации и обработке однонаправленных списков
Отчет по лабораторной работе №2 Ревизия: 1 История изменений iconОтчет по лабораторной работе № Выполнил

Отчет по лабораторной работе №2 Ревизия: 1 История изменений iconОтчет по лабораторной работе по дисциплине: " Зашита Информации"

Отчет по лабораторной работе №2 Ревизия: 1 История изменений iconОтчет по лабораторной работе №1 «Утилиты тср/ip и анализ сетевого трафика»

Отчет по лабораторной работе №2 Ревизия: 1 История изменений iconОтчет по лабораторной работе №2 по дисциплине: «Сети ЭВМ и средства телекоммуникаций»

Отчет по лабораторной работе №2 Ревизия: 1 История изменений iconОтчет по лабораторной работе №15 по дисциплине "Программирование на языке высокого уровня"

Отчет по лабораторной работе №2 Ревизия: 1 История изменений iconОтчет по лабораторной работе №4 исследование рупорных и линзовых антенн подпись Дата Ф. И. О

Отчет по лабораторной работе №2 Ревизия: 1 История изменений iconОтчет по лабораторной работе № "Исследование уязвимостей при помощи сканера x-spider"

Отчет по лабораторной работе №2 Ревизия: 1 История изменений iconЛабораторная работа по теме «Приближенные методы вычисления корней уравнений»
Заполните электронный отчет файл «Отчет по лабораторной работе Приближенные вычисления»!
Разместите кнопку на своём сайте:
ru.convdocs.org


База данных защищена авторским правом ©ru.convdocs.org 2016
обратиться к администрации
ru.convdocs.org