CC BY
30
Математические структуры и моделирование 2003, вып. 11, с. 128-157
УДК 681.32
SIMCOSAR: ПРОГРАММНЫЙ КОМПЛЕКС МОДЕЛИРОВАНИЯ ПРОЦЕССА МОНИТОРИНГА СОСТОЯНИЯ ИНФОРМАЦИОННОГО ПОЛЯ
ИНТЕРНЕТ
И.А. Земсков
The article presents the description of simulation program package (named as SimCOSAR). Computer programs were realized on Python with SimPv package.
Введение
В предыдущей статье [1] были приведены модели двух концепций реализации системы мониторинга информационного поля Интернет. Также немного было сказано о разрабатываемом комплексе программ, который реализует описанные модели. В ходе пробных экспериментов в программный комплекс вносились некоторые исправления и дополнения, а также была выявлена и реализована оптимальная, на наш взгляд, архитектура построения программного комплекса. Поэтому целью данной статьи мы выбрали знакомство коллег е текущей версией программного комплекса моделирования. Но прежде чем приступить к его описанию, обозначим основные принципы и договорённости, которые были использованы при его проектировании и реализации:
• работу комплекса можно и нужно разбить на этапы. Например, в отдельный этап может быть вычленено создание рабочей среды (набора ресурсов) и карты (журнала) событий, происходящих в наблюдаемой среде;
• так как проведение экспериментов разделено на этапы, а каждый этап имеет свою «настроечную» информацию и результаты функционирования (минимум лог-файл функционирования соответствующего модуля), то логичным (но не сразу пришедшим) решением стало размещение всей информации, касающейся одного этапа в отдельной директории. Причём мы ввели правило именования директорий. Например, уже упомянутые этапы создания рабочей среды располагаются в директориях с именем «seriesN», где N - номер серии (серий может быть столько, сколько необходимо исследователю). Остальные имена директорий будут указаны далее по тексту;
© 2003 И.А. Земсков
E-mail: [email protected] Омский государственный университет
Математические структуры и моделирование. 2003. Вып. 11.
129
• в условиях применения языка Python было признано, что наиболее удобным способом организации хранения настроечной информации является использование ini-файлов, доступ к которым обеспечивает стандартный класс - ConfigParser, Все ini-файлы каждого этапа мы договорились хранить в специальной («ini») поддиректории директории этапа;
• для всех этапов должна быть выделена и помещена в доступное место (общий каталог «іпі») максимально единая настроечная информация (это необходимо во избежание бессмысленного дублирования информации и облегчения настройки программного комплекса);
• так как каждый этап может включать в себя несколько действий (например инициализация, работа, вывод накопленной статистики), принято решение объединять все однотипные действия в единые пакетные файлы (bat-файл). Пакетный файл помещается в корень директории этапа;
• было принято решение хранить самые последние версии модулей в едином каталоге («bin»), причём имена файлов в данном каталоге не должны содержать версию (на всех стадиях разработки любых модулей комплекса мы договорились вести учёт версий программного кода, как в заголовках, так и в названиях файлов модулей) модуля. Эта договорённость избавляет от необходимости лишний раз исправлять имена вызываемых в пакетных файлах модулей;
• реально происходящий процесс передачи информации с одного узла сети Интернет на другой узел имеет большое количество неподдающихея формализации нюансов. Все эти нюансы субъективно влияют на изучаемый процесс мониторинга, но их рассмотрение лишь засорит модели ненужными подробностями. Поэтому было принято решение, что каждый раз, когда необходимо определить время передачи некоторого объёма информации через сеть, мы будем использовать случайную величину, которая равномерно распределена на некотором интервале, В каждом конкретном случае мы будем давать свои оценки возможным значениям нижней и верхней границ интервала,
1. Состав программного комплекса
Реализация всех функций комплекса сгруппирована по нескольким модулям:
• SimPages.py - создание рабочей среды (набора ресурсов) и карты (журнала) событий, происходящих в наблюдаемой среде;
• SimRobRoute.py - создание «маршрутов» обследования набора ресурсов роботом или роботами;
• SimRobot.py - имитация работы системы мониторинга в случае использования концепции «роботов»;
• SimRobotM.py - имитация работы системы мониторинга в случае использования стратегии «модифицированных роботов»;
• SimSensor.py - имитация работы системы мониторинга в случае использования концепции «сенсоров»;
• SimReport.py - извлечение статистики, которая была накоплена в ре-
130 И.А. Земсков. SimCOSAR: программный комплекс моделирования...
зультате осуществления имитации;
• SimMergeReports.py - извлечение статистики, которая была накоплена в результате осуществления нескольких имитаций («прогонов»). Рассмотрение каждого из этих модулей начнём с общего для всех модулей элемента, а именно с общей настроечной информации.
2. Общая настроечная информация
Общие настройки могут быть распределены по нескольким іиі-файлам, которые помещаются в общую для всего комплекса ini-директорию. На данный момент мы имеем два файла настроек: common л пі и db.ini. Ссылки на эти файлы реализуются в каждом модуле программного комплекса в виде глобальных текстовых констант (comini, dbini). Впоследствии количество файлов и их содержание может (в силу возникающих потребностей разработки) измениться, а сейчас мы приведём таблицы, в которые собрали содержание названных файлов. Здесь и в аналогичных таблицах дальше в отдельном столбце таблицы мы будем приводить рекомендуемые значения параметров (часто предполагается невозможность их изменения без необходимости изменения программного кода). Ещё один столбец таблицы будет посвящён словесному описанию параметра.
Таблица 1. Файл common.ini.
Секция Параметр Рекомендуемое значение Описание
[Options] WorkDirectory Директория размещения программного комплекса
[report Options] ReportFileExtension • CSV Расширение файлов с отчётными данными
Report ValuesDelimiter Разделитель значений в файле отчёта
[measureOptions] PageSizeMeasure byte Единицы измерения объёмов информационных ресурсов. В модулях значение параметра нигде в явном виде не используется и носит характер справочной информации
TimeMeasure 10msec Единица измерения модельного времени. В модулях значение параметра нигде в явном виде не используется и носит характер справочной информации
Таблица 2. Файл db.ini.
Секция Параметр Рекомендуемое значение Описание
[dbOptions] Host IP адрес MySQL сервера
Login Имя учётной записи на сервере
Математические структуры и моделирование. 2003. Вып. 11.
131
Таблица 2. Файл бЬ.іпі(продолжение)
Секция Параметр Рекомендуемое значение Описание
[dbOptions] Password Пароль доступа к учётной записи
PagesTableName pages Имя таблицы, в которой будет храниться информация о моделируемых информационных ресурсах
PagesTableFieldsSQL pid int(ll) primary key, iter tinyint, lastch tinyint, size int(ll), changed tinyint, crawled tinyint, wtime int(ll) SQL описание полей таблицы PagesTableName, напрямую используется в программе
ChangesTableName events Имя таблицы, в которой будет храниться информация о происходящих изменениях моделируемых информационных ресурсов
ChangesTableFieldsSQL eid int(ll) auto increment primary key, iter tinyint, pid int(ll), etime int(ll), newch tinyint, prevch tinyint, dsize int(ll), index(etime) SQL описание полей таблицы ChangesTableName
QueriesTableName queries Имя таблицы, в которой будет храниться информация о поступивших запросах на моделируемые информационные ресурсы
QueriesTableFieldsSQL qid int(ll) auto increment primary key, iter tinyint, pid int(ll), qtime int(ll), index(qtime) SQL описание полей таблицы QueriesTableName
RobRouteTableName robroute Имя таблицы, в которой будет храниться информация о маршруте робота(-ов)
RobRouteTableFieldsS QL pid int(ll), rob int(ll) SQL описание полей таблицы RobRouteTableName
StatTableFieldsS QL sid int(ll) auto increment primary key, stime int(ll), varval double SQL описание полей таблиц, которые используются для сбора статистических данных
Пока данные таблицы приводятся без дополнительных пояснений, так как необходимые разъяснения будут даваться при дальнейшем описании модулей комплекса.
132 И.А. Земсков. SimCOSAR: программный комплекс моделирования...
3. Модуль SimPages.py
Основная задача данного модуля заключается в генерации серии «виртуальных» информационных ресурсов, а также истории их изменений и истории запросов на них. Данный модуль может быть отработан каждый раз, когда по плану экспериментов необходима новая (другая) серия информационных ресурсов. Под серией будем понимать один или несколько (они отличаются исходными значениями параметров моделирования) наборов информационных ресурсов. Таким образом, в одной серии должен присутствовать хотя бы один набор описаний информационных ресурсов, А всю информацию, которая касается определённой серии, мы решили хранить в папке с именем «seriesN» (где N необходимо заменить номером рассматриваемой серии).
Модулю для работы необходимо указать два параметра: во-первых, название директории («seriesN»), а во-вторых, имя файла с настройками текущего набора («serN-M.ini»), Таким образом, для генерации всей серии необходимо выполнить модуль SimPages.py ровно М раз, т,е, столько раз, сколько наборов в серии. Все эти вызовы модуля можно собрать в один пакетный файл (например, можно создать файл build.bat и поместить все команды в него, что, собственно, мы и сделали), В дальнейшем для создания всей серии необходимо вызвать на выполнение только этот пакетный файл.
Все файлы с настройками хранятся в поддиректории «ini». Каждая серия имеет общий файл настроек (хранимый, например, в файле с именем «serN.ini», где N - номер серии). Каждый набор также имеет свой персональный файл настроек (хранимый, например, в файле с именем «serN-M.ini», где N - номер серии, а М - номер набора). Приведём содержимое общего файла настройки серии и файла настройки набора.
Таблица 3. Файл serN.ini.
Секция Параметр Рекомендуемое значение Описание
[simOptions] ModelTime Моделируемое время, единиц (1ед=10мсек)
Iterations і Количество итераций (при наличии больших вычислительных мощностей и других ресурсов можно попробовать собрать обширную статистику), единиц
[pageOptions] MinPageSize 65 Минимальный размер информационного ресурса, байт
MaxPageSize 122880 Максимальный размер информационного ресурса, байт
MinPageLoadTime 1 Минимальное время, которое необходимо для «скачивания» информационного ресурса, единиц
Математические структуры и моделирование. 2003. Вып. 11.
133
Таблица 3. Файл 8егХлш(продолжение)
Секция Параметр Рекомендуемое значение Описание
MaxPageLoadTime 40 Максимальное время, которое необходимо для «скачивания» информационного ресурса, единиц
DefaultPageChange 6 Задаваемый изначально тип (номер) «последнего» изменения информационного ресурса. Тип 6 соответствует «Страница доступна (нет изменений)». Весь список типов доступен в [1]
DefaultPageChanged 0 Логический ключ (1 - True / 0 - False), который отвечает за исходное значение признака «Информационный ресурс изменился»
DefaultPageCrawled 1 Логический ключ (1 - True / 0 - False), который отвечает за исходное значение признака «Последнее изменение ресурса уже известно системе мониторинга»
[logOptions] LogDirectory logs\\ Директория для размещения соответствующих данному этапу журналов («логов»)
LogFileName serlog.txt Имя файла главного журнала событий
LogTraceToFile 1 Логический ключ (1 - True / 0 - False), который отвечает за включение протоколирования действий при выполнении данного модуля
Таблица 4. Файл serN-M.ini.
Секция Параметр Рекомендуемое значение Описание
[serOptions] Commonlni serN.ini Ссылка на файл общих настроек для текущей серии
[simOptions] RandomSeed Смещение генератора случайных чисел (integer)
[pageOptions] PageCount Количество моделируемых информационных ресурсов, единиц
FirstPageNum 1 Нумерация информационных ресурсов в наборе начинается с данного значения
[changeOptions] Changelntensity Интенсивность изменений любого информационного ресурса (float)
134 И.А. Земсков. SimCOSAR: программный комплекс моделирования...
Таблица 4. Файл 8ЄгІ4-М.іпі(продолжение)
Секция Параметр Рекомендуемое значение Описание
MinPagelncSize 0 Минимальный размер возможного положительного приращения информационного ресурса, байт
MinPageDecSize 0 Минимальный размер возможного отрицательного приращения информационного ресурса, байт
[request Options] Requestlntensity Интенсивность «внешних» запросов любого информационного ресурса (float)
[dbOptions] DBName serN_M Имя базы данных, в которой будет храниться текущий набор
TablesNeedCreate 1 Признак необходимости создания таблиц набора, (1 - True / 0 - False)
[logOptions] StepLogCreatingPages Задаёт шаг, с которым в журнал попадает сообщение о «созданных» на данный момент информационных ресурсах. Значение шага не может быть больше значения параметра PageCount
Как видно из таблицы 4, за каждым набором закрепляется своя база данных (ем, поле DBName), Для простоты создания и удаления всех необходимых баз данных одной серии мы описали два SQL-екрипта: create,sql и drop.sql, которые помещаем в специальную поддиректорию («sql») директории «seriesN», Каждая база данных набора состоит из трёх таблиц, структуру которых можно увидеть в соответствующих полях файла db.ini. Однако необходимо дать некоторые пояснения к используемым полям таблиц.
Таблица «pages» (имя таблицы описывается полем PagesTableName) - описывает информационные ресурсы и имеет следующие поля:
• pid - идентификационный номер ресурса;
• iter - порядковый номер итерации;
• lastch - номер (тип) последнего изменения;
• size - исходный размер информационного ресурса;
• changed - поле содержит признак изменения ресурса с момента последнего наблюдения за его состоянием системой мониторинга;
• crawled - поле содержит признак учёта системой мониторинга последних изменений, которые произошли с ресурсом;
• wtirrie - поле хранит время первого неучтённого изменения.
Таблица «events» (см, поле ChangesTableName) описывает изменения информационных ресурсов и имеет следующие поля:
• eid - идентификационный номер события изменения;
• iter - порядковый номер итерации;
Математические структуры и моделирование. 2003. Вып. 11.
135
• pid - идентификационный номер ресурса, для которого произошло текущее событие изменения;
• etime - время наступления события изменения;
• newch - новый номер (тип) изменения ресурса;
• prevch - предыдущий номер изменения ресурса (необходим для обнаружения ситуаций, когда «фактически» изменений в состоянии ресурса не произошло, например, когда новый номер изменения совпадает со старым и равен 2 - «Ошибка 404»);
• dsize - новый байтовый размер рассматриваемого ресурса.
Таблица «queries» (см, поле QueriesTableName) описывает запросы информационных ресурсов и имеет следующие поля:
• qid - идентификационный номер события запроса ресурса;
• iter - порядковый номер итерации;
• pid - идентификационный номер ресурса, который запрашивают;
• qtime - время поступления запроса на информационный ресурс,
В таблице 4 дополнительного пояснения требуют параметры «Changelntensity», «Requestlntensitv», Необходимо сказать, что на данный момент в рамках программного комплекса моделирование интервалов времени между последовательными событиями производится только с использованием экспоненциального распределения. Реализация процедуры генератора случайных величин, распределённых по экспоненциальному закону с математическим ожиданием в (в вычисляется как отношение общего времени моделирования к соответствующей интенсивности) позаимствована из [2]. Если в дальнейшем потребуется проведение экспериментов с другими законами распределения, то может потребоваться доработка данного модуля соответствующими процедурами и соответственно расширение файлов настроек необходимыми параметрами.
Основу модуля SimPages.pv составляют три класса (Page, Change, Query) и одна глобальная процедура (main), которая собственно и содержит главный цикл модуля. Обобщённый алгоритм функционирования модуля представлен блок-схемой на рисунке 1,
При каждом запуске модуля SimPages.pv в файл главного журнала («лог» выполнения модуля) попадает новая порция следующей информации:
• дата и время начала работы модуля;
• версия используемого модуля SimPages.pv;
• полный путь к файлу и само имя файла используемых настроек набора;
• счётчик итераций;
• используемое смещение генератора случайных чисел;
• количество созданных на данный момент (выводится реальное время) информационных ресурсов (для вывода используется шаг StepLogCreatingPages);
• суммарный «виртуальный» объём (в байтах) созданного набора ресурсов;
• дата и время завершения работы модуля.
136 И.А. Земсков. SimCOSAR: программный комплекс моделирования...
Рис. 1. Обобщённый алгоритм модуля SimPages.py.
Математические структуры и моделирование. 2003. Вып. 11.
137
4. Модуль SimRobRoute.py
В реальной жизни у роботов поисковых систем существует бесконечное множество всевозможных путей обхода информационных ресурсов. Вопросу о нахождении оптимального пути посвящено множество исследовательских работ, и, чтобы убедится в этом, достаточно посетить архивы последних конференций, которые освещают проблемы технологий поисковых систем Интернет [3]. Однако в рамках нашего исследования мы используем и рассматриваем самый простой в реализации - «последовательный маршрут». Данный маршрут характеризуется тем, что список ресурсов, которые известны системе мониторинга, последовательно обходит индексирующий робот. Если роботов несколько, список делится на примерно равные части и к каждой части «прикрепляют» одного из имеющихся роботов. После достижения последнего ресурса в списке робот должен продолжить обход, начиная с первого ресурса в списке,
В контексте всего вышесказанного можно сделать вы во. что модуль SimRobRoute.py занимается тем, что «привязывает» каждый конкретный ресурс в таблице pages к одному из роботов (их количество задаётся параметром RobotQuantity, см, таблицу 5 далее). Алгоритм «привязки» априори подразумевает наличие упорядоченной нумерации ресурсов в таблице pages. Поэтому для работы модулю достаточно знать только общее количество информационных ресурсов,
В зависимости от поставленных целей исследования могут понадобиться один или несколько маршрутов. Причём один и тот же маршрут может повторно использоваться по отношению к различным сериям информационных ресурсов. Единственным ограничением для такого использования является совпадение у маршрута и серии количества моделируемых ресурсов. Всю информацию, которая касается определённого маршрута, мы решили хранить в папке с именем «pathN» (где N необходимо заменить номером рассматриваемого маршрута) ,
Модулю для работы необходимо указать два параметра: во-первых, название директории («pathN»), а во-вторых, имя файла с настройками текущего маршрута («pathN.ini»), С целью облегчить работу с модулем мы создали пакетный файл, в котором указали необходимую строку вызова модуля с передачей требуемых параметров. Файлу присвоили имя build.bat. Файл с настройками хранится в поддиректории «іиі», В таблице 5 приведено содержимое файла настройки маршрута.
Таблица 5. Файл pathN.ini.
Секция Параметр Рекомендуемое значение Описание
[pageOptions] PageCount Общее количество информационных ресурсов, которые будут являться пунктами маршрутов, единиц
138 И.А. Земсков. SimCOSAR: программный комплекс моделирования...
Таблица 5. Файл pathN.іпі(продолжение)
Секция Параметр Рекомендуемое значение Описание
[robotOptions] RobotQuantity Количество роботов, участвующих в мониторинге информационных ресурсов, единиц
[dbOptions] DBName pathN Имя базы данных, в которой будет храниться текущий маршрут
[logOptions] LogDirectory logs\\ Директория для размещения соответствующих данному этапу журналов («логов»)
LogFileName routelog.txt Имя файла главного журнала событий
LogTraceToFile 1 Логический ключ (1 - True / 0 - False), который отвечает за включение протоколирования действий при выполнении данного модуля
Как видно из таблицы 5, за каждым маршрутом закрепляется своя база данных (ем, поле DBName), Для простоты создания и удаления баз данных маршрутов мы описали два SQL-екрипта: create,sql и drop.sql, которые поместили в поддиректорию («sql») директории «pathN», Каждая база данных маршрута состоит из одной таблицы, структуру которой можно увидеть в соответствующем поле (RobRouteTableFieldsSQL) файла db.ini.
При каждом запуске модуля SimRobRoute.py в файл главного журнала («лог» выполнения модуля) попадает новая порция следующей информации:
• дата и время начала работы модуля;
• версия используемого модуля SimRobRoute.py;
• полный путь к файлу и само имя файла используемых настроек набора;
• номер текущего робота;
• дата и время завершения работы модуля.
5. Модуль SimRobot.py
Данный модуль позволяет осуществлять имитацию функционирования системы мониторинга, которая построена с использованием концепции «роботов». Использование модуля основано на том соображении, что каждый раз, когда мы вызываем на исполнение данный модуль по отношению к наборам одной и той же серии, мы тем самым осуществляем «один» эксперимент. Конечно, можно называть экспериментом и обработку каждого набора по отдельности, но, на наш взгляд, для данного случая более уместен термин «прогон». Само собой разумеется, что один эксперимент может задействовать несколько модулей (вдобавок, например, SimReport.py или SimMergeReports.py), каждый из которых может требовать на вход свои файлы настроек, а на выходе создавать несколько файлов с результатами своей деятельности. Исходя из этих соображений, мы поместили всю информацию, которая касается одного эксперимента
Математические структуры и моделирование. 2003. Вып. 11.
139
в директорию е именем «testR», где R - номер эксперимента. Приведённые соображения действительны и для других модулей имитации: SimRobotM.py, SimSensor.py.
Модулю для работы необходимо указать два параметра: во-первых, название директории («testR»), а во-вторых, имя файла е настройками используемого набора ресурсов («serN-M.ini», имя файла совпадает е именем файла настроек наборов для модуля SimPages.py, но, как будет видно далее, содержимое этих файлов заметно отличается). Таким образом, для имитации системы на данных всей серии необходимо выполнить модуль SimRobot.py ровно М раз, т.е, столько раз, сколько наборов в серии. Все эти вызовы модуля мы собрали в один пакетный файл и назвали его run.bat.
Все файлы е настройками эксперимента хранятся в поддиректории «іпі». Каждый эксперимент имеет общий файл настроек (хранимый, например, в файле е именем «testR.ini», где R- номер эксперимента). Использование имён «serN-M.ini» для файлов настроек наборов обосновывается последующей (при увеличении числа экспериментов) легкостью контроля правильности выбора данных для проведения эксперимента. Приведём содержимое общего файла настройки эксперимента и файла настройки набора.
Таблица 6. Файл testR.ini для модуля SimRobot.py.
Секция Параметр Рекомендуемое значение Описание
[simOptions] ModelTime Моделируемое время, единиц
Iterations і Количество итераций, единиц
[pageOptions] PageCount Количество моделируемых информационных ресурсов, единиц
MinPageLoadTime і Минимально возможное время «скачивания» одного информационного ресурса
MaxPageLoadTime 40 Максимально возможное время «скачивания» одного информационного ресурса
[robot Options] RobotQuantity Количество роботов, участвующих в мониторинге информационных ресурсов, единиц
[logOptions] LogDirectory logs\\ Директория для размещения соответствующих данному этапу журналов («логов»)
LogFileName testlog.txt Имя файла главного журнала событий
LogTraceToFile 1 Логический ключ (1 - True / 0 - False), который отвечает за включение протоколирования действий при выполнении данного модуля
StepLogCycles 1 Шаг журнализации события завершения роботом цикла обхода «своих» ресурсов
140 II.Л. Земсков. SimCOSAR: программный комплекс моделирования...
Таблица 7. Файл serN-M.ini для модуля SimRobot.pv.
Секция Параметр Рекомендуемое значение Описание
[testOptions] Commonlni testR.ini Ссылка на файл общих настроек для текущего эксперимента
[simOptions] RandomSeed Смещение генератора случайных чисел (integer)
[dbOptions] MainDBName serN_M Имя базы данных, в которой хранится необходимый набор
StatDBName testR_M Имя базы данных, в которой будут сохраняться значения наблюдаемых вели-HHH(ReportStatVars)
RouteDBName pathL Имя базы данных, в которой хранится используемый в эксперименте маршрут робота(-ов)
[report Options] Report Directory M\\ Директория для размещения соответствующих данному набору статистических данных, которые будут собраны в ходе эксперимента. Буква М совпадает с номером обрабатываемого набора
Report StatVars needfresh, freshness, sumsize Имена переменных, для которых в процессе имитации идёт сбор общей «статистики». Значения данного параметра используются при создании соответствующих таблиц базы данных и файлов отчётов
OtherReportStatVars sumsizerob Дополнительные имена «статистических» переменных, которые имеют немного отличный алгоритм обработки и вывода. Значение параметра, в частности, используется для сбора статистики по каждому конкретному роботу в отдельности
Чтобы пояснить принципы использования некоторых параметров файлов настроек, рассмотрим блок-схемы (см, рисунок 2) обобщённых алгоритмов, используемых в модуле. Но сначала стоит упомянуть тот факт, что мы используем python-модуль SimPv [4,5], который является библиотекой классов для построения моделей, основанных на дискретных событиях, или на так называемом «событийном подходе» [6]. Применение данной библиотеки позволяет организовать квазипараллельное выполнение процессов. Таким образом, в модуле SimRobot.pv «одновременно» может выполняться несколько процессов, что мы попытались отразить на блок-схемах, закрасив фон некоторых блоков в серый цвет, В частности, в серый цвет выкрашены три блока схемы А: процесс «изменения» информационного ресурса, процесс «обхода» роботом информационных
Математические структуры и моделирование. 2003. Вып. 11.
141
ресурсов, процесс сбора статистической информации. Обобщённые алгоритмы трёх названных блоков представлены блок-схемами Б, В, Г соответственно, В этих блок-схемах также есть блоки, которые помечены серым цветом. Принцип функционирования этих блоков основан на резервировании необходимого события в определённый момент на отрезке времени моделирования, В тот момент, когда текущее модельное время совпадает со временем зарезервированного события, происходит передача управления из главного цикла модуля в программный код, следующий за кодом, который ранее выполнил резервирование данного «специального» события.
Дадим пояснения к некоторым блокам на схеме А (см, рисунок 2):
• Инициализация набора информационных ресурсов. Исходная информация о моделируемых ресурсах хранится в таблице pages. Для описания одного ресурса и удобной последующей работе с ним в рамках модуля представлен класс Page, Таким образом, описываемый блок создаёт в памяти массив объектов типа Page, причём сразу присваивает свойствам каждого объекта нужные значения, беря их из соответствующих полей таблицы pages,
• Инициализация набора «статистических» переменных, В модуле имеется ассоциативный массив simvarsdefault, в котором описаны исходные (чаще всего нулевые) значения статистических переменных. Однако в главном цикле модуля используется только двойник этого массива simvars (элементы этого массива и являются т.н. «статистическими переменными»), А при каждой новой итерации главного цикла необходимо «сбрасывать» в исходное состояние значения элементов массива simvars (что мы и делаем копированием simvarsdefault в simvars). Также для некоторых статистических переменных созданы специальные классы (Needfresh, Freshness, SumsizeRobs, Sumsize), которые реализуют логику сбора соответствующих данных. Каждый из этих классов является потомком класса Process python-модуля SimPv, что позволяет реализовать статистические измерения в любые задаваемые моменты модельного времени, В модуле мы реализовали замер переменных с определённым шагом времени, а каждая статистическая переменная может иметь свой шаг измерения, который должен храниться в специальном ассоциативном массиве statvarstime,
• Инициализация робота (-ов), В модуле описан класс Crawl (наследник класса Process python-модуля SimPv), который имитирует поведение единичного робота. Таким образом, в момент «инициализации роботов» осуществляется создание одного или нескольких (согласно параметру RobotQuantity) объёктов типа Crawl и «привязывание» каждому роботу своего маршрута согласно используемой (RouteDBName) таблице robroute,
• Процесс «изменения» информационных ресурсов, В модуле описан класс Changes (наследник класса Process python-модуля SimPv), который реализует наступление событий изменений для всех моделируемых ресурсов, Обобщённый алгоритм представлен схемой Б на рисунке 2,
• Процесс «обхода» роботом информационных ресурсов. Блок подразумевает функционирование объектов типа Crawl, обобщённый алго-
142 II.Л. Земсков. SimCOSAR: программный комплекс моделирования...
Рис. 2. Блок-схемы алгоритмов модуля SimRobot.py.
Математические структуры и моделирование. 2003. Вып. 11.
143
ритм которых представлен схемой В на рисунке 2,
• Процесс сбора статистической информации. Обобщённый алгоритм представлен схемой Г на рисунке 2, В рамках данного блока собирается статистика переменных, для которых сеть соответствующие классы (ем, блок инициализации статистических переменных),
• Протяжка текущего модельного времени до «ближайшей» группы событий. Осуществляется встроенной процедурой simulate python-модуля SimPv,
Теперь рассмотрим некоторые блоки на других оставшихся схемах рисунка 2, Начнём со схемы Б:
• Получить из таблицы events в ChTime время ближайшей группы событий изменений, В специальную переменную ChTime попадает результат SQL-запроеа, который берёт первую запись среди упорядоченных по полю etime записей,
• Обработка событий других процессов, В языке Python имеется оператор yield, который позволяет «заморозить» исполнение программного кода процедуры, которая его содержит. Приведём фрагмент стандартной документации языка Python:
When a yield statement is executed, the state of the generator is frozen and the value of expression_list is returned to nextQ’s caller.
By «frozen» we mean that all local state is retained, including the current bindings of local variables, the instruction pointer, and the internal evaluation stack: enough information is saved so that the next time nextQ is invoked, the function can proceed exactly as if the yield statement were just another external call.
При разработке всех классов, которые являются наследниками класса Process, нами использовался именно оператор yield, А все вызовы метода next () реализуются в рамках python-модуля SimPv,
• Получить из таблицы events ближайшую группу событий изменений, Выполняется SQL-запрос, на который возвращаются записи таблицы events с равными значениями поля etime и равными текущему модельному времени,
• Изменение свойств ресурса, для которого произошло текущее событие. Одна запись таблицы events описывает событие изменения одного информационного ресурса, В данном блоке происходит изменение свойств соответствующего объекта типа Page (который находится в памяти и доступен как элемент массива) на значения рассматриваемой записи из events.
Далее рассмотрим некоторые блоки схемы В:
• Определение времени скачивания роботом очередного ресурса (LdTime), Для выполнения данной операции мы используем генератор случайных чисел, равномерно распределённых в интервале [MinPageLoadTim,e, MaxPageLoadTime\. Полученный результат помещается в локальную переменную LdTime, Однако все эти действия вы-
144 И.А. Земсков. SimCOSAR: программный комплекс моделирования...
полняются только в том случае, когда ресурс доступен для скачивания. Иначе время скачивания равно О,
• Обработка событий других процессов в течение времени LdTime,
Принцип действия блока подробно описан ранее, здесь же нужно добавить, что оператору yield передаётся в качестве параметра значение LdTime, которое используется для вычисления момента возвращения управления в данное место,
• Изменение свойств ресурса, скачанного роботом. Если у ресурса имелись изменения, которые неизвестны поисковой системе, то необходимо изменить соответствующие (changed, crawled) свойства ресурса (объект типа Page), Тем самым мы обозначим новое состояние ресурса и наблюдаемой среды,
• Обновление значений соответствующих статистических переменных, В данный момент изменяется значение переменных, которые характеризуют процесс скачивания ресурсов (SumSizeRob, MinWaitCrawl, MaxWaitCrawl, AvrWaitCrawl, Cycles),
А закончим рассмотрение блоками схемы Г:
• Обработка событий других процессов в течение времени StepTime, В качестве длительности промежутка «бездействия» используется значение StepTime, которое берётся из statvarstime для каждой статистической переменной соответственно,
• Сохранение в базе данных текущего значения статистической переменной, Блок выполняет два действия. Во-первых, происходит замер текущего значения соответствующей переменной (для некоторых переменных необходимы специальные вычисления). Во-вторых, осуществляется специальный SQL-запрос вставки новой записи в таблицу, которая соответствует (ReportStatVars, OtherReportStatVars) измеряемой переменной.
Приведём полный список имеющихся в модуле статистических переменных, давая необходимые пояснения:
• SumSizeRob - в переменной суммируется текущая длина (в байтах) ресурсов, которые скачивает робот, У каждого робота имеется «своя» такая переменная, значение которой каждые 10000 единиц модельного времени помещается в таблицу sumsizerobJ базы testR_M (где J - номер робота),
• MinWaitCrawl - минимальное время, которое прошло с момента наступления события изменения ресурса до события завершения скачивания изменившегося ресурса роботом. Определяется на основе всего массива ресурсов посещаемых данным роботом,
• MaxWaitCrawl - максимальное время, которое прошло с момента наступления события изменения ресурса до события завершения скачивания изменившегося ресурса роботом. Определяется на основе всего массива ресурсов, посещаемых данным роботом,
• AvrWaitCrawl - время ожидания «обновления» суммируется для каждого посещённого ресурса и делится на количество посещённых за модельное время ресурсов, У каждого робота имеется «своя» такая переменная,
• Cycles считает сделанные каждым роботом циклы обхода отведённых ему
Математические структуры и моделирование. 2003. Вып. 11.
145
ресурсов,
• NeedFresh хранит количество ресурсов, которые изменили своё состояние (т.е. изменились) и которые необходимо посетить роботу, чтобы обновить имеющуюся информацию. Каждые 5000 единиц модельного времени значение переменной помещается в таблицу needfresh базы testR_M,
• Freshness вычисляет значение свежести индекса поисковой системы на основе значения переменной NeedFresh (см, формулу в [1]), Каждые 5000 единиц модельного времени значение переменной помещается в таблицу freshness базы testR_M,
• SumSize вычисляет общий объём скачанной всеми роботами информации. Каждые 10000 единиц модельного времени значение переменной помещается в таблицу sumsize базы testR_M,
При каждом запуске модуля SimRobot.py в файл главного журнала («лог» выполнения модуля) попадает новая порция следующей информации:
• дата и время начала работы модуля;
• версия используемого модуля SimRobot.py;
• полный путь к файлу и само имя файла используемых настроек набора;
• счётчик итераций;
• используемое смещение генератора случайных чисел;
• используемое количество роботов;
• сообщения о завершении цикла каждым роботом отдельно (с выводом текущего модельного времени);
• блок-статистки отдельно для каждого робота:
* Cycles;
* MinWaitCrawl;
* MaxWaitCrawl;
* AvrWaitCrawl;
* SumSizeRob;
• выводится общее для всех роботов значение SumSize;
• дата и время завершения работы модуля,
6. Модуль SimRobotM.py
Одним из направлений развития концепции «роботов» стала стратегия «модифицированных роботов» (устоявшегося названия нами не найдено, и, чтобы хоть как-то различать «роботов», вводим своё название), т.е, роботов, которые за счёт использования некоторых стандартных средств HTTP-протокола (запрос HEAD, поле If-Modified-Since) обходятся без периодического тотального скачивания всех ресурсов к себе и тем самым снижают свою нагрузку на наблюдаемую среду. Наше исследование было бы скудным без учёта этой, всеми признанной, стратегии (многие крупные поисковые системы, такие как Google, пользуются роботами именно этой модификации). Поэтому нами был разработан модуль моделирования работы системы в случае стратегии «мобильных роботов». За основу модуля SimRobotM.py был взят код модуля SimRobot.py, Изменения коснулись только класса Crawl, В силу этого мы не будем приво-
146 И.А. Земсков. SimCOSAR: программный комплекс моделирования...
дить подробное описание модуля SimRobotM.py, а ограничимся только лишь описанием сделанных изменений.
По традиции начнём описание модуля е его файлов настройки. Для модуля SimRobotM.py один из файлов настройки (testR.ini) приобрёл два новых параметра (ем, таблицу 8), всё остальное осталось без изменений.
Таблица 8. Файл testR.ini для модуля SimRobotM.py (сокращённая версия).
Секция Параметр Рекомендуемое значение Описание
[robotOptions] MinHEADTime і Минимально возможное время для обследования одного информационного ресурса с помощью «специального» запроса (сюда входит время посылки запроса и время получения ответа)
MaxHEADTime 3 Максимально возможное время для обследования одного информационного ресурса с помощью «специального» запроса (сюда входит время посылки запроса и время получения ответа)
Изменения, коснувшиеся класса Crawl, отображены на блок-схеме рисунка 3, Дадим пояснения к некоторым блокам:
• Определение времени (HEADTime) обследования роботом очередного ресурса. Для выполнения данной операции мы используем генератор случайных чисел, равномерно распределённых в интервале [MinHEADTime, Max HEADTime]. Полученный результат помещается в локальную переменную HEADTime,
• Обработка событий других процессов в течение времени HEADTime, Принцип действия подобных блоков подробно описан ранее, здесь же нужно добавить, что оператору yield передаётся в качестве параметра значение HEADTime, которое используется для вычисления момента возвращения управления в данное место,
• Изменение свойств ресурса, обследованного роботом. Каждый ресурс (объект типа Page) имеет логический ключ-свойство «crawled» («посещён»), вот его-то и нужно перевести в состояние True, Через это свойство в последствии вычисляется статистическая переменная NeedFresh,
Список статистических переменных и сообщений в главном журнале («логе») выполнения модуля SimRobotM.py абсолютно идентичен имеющимся в модуле SimRobot.pv, поэтому особо останавливаться на них мы не будем, а перейдём к рассмотрению следующего модуля.
Математические структуры и моделирование. 2003. Вып. 11.
147
Рис. 3. Блок-схема алгоритма метода life класса Crawl модуля SimRobotM.py.
148 II.Л. Земсков. SimCOSAR: программный комплекс моделирования...
7. Модуль SimSensor.py
Данный модуль позволяет осуществлять имитацию функционирования системы мониторинга, которая построена с использованием концепции «сенсоров». Использование модуля во многом похоже на использование ранее описанных модулей SimRobot.py и SimRobotM.py. Каждый вызов на исполнение данного модуля по отношению к наборам одной и той же серии осуществляет один эксперимент, а вея информация, которая касается одного эксперимента, помещается в директорию е именем «testR» (где R номер эксперимента). Также модулю для работы необходимо указать два параметра: во-первых, название директории («testR»), а во-вторых, имя файла е настройками используемого набора ресурсов («serN-M.ini»), Для имитации системы на всех наборах серии необходимо выполнить модуль SimSensor.py ровно М раз, т.е, столько раз, сколько наборов в серии. Вес вызовы модуля собраны в один пакетный файл (run.bat). Как и договорились ранее, вес файлы е настройками эксперимента хранятся в поддиректории «іиі». Каждый эксперимент имеет общий файл настроек (хранимый, например, в файле е именем «testR.ini», где R - номер эксперимента). Приведём содержимое общего файла настройки эксперимента и файла настройки набора, которые используются модулем SimSensor.py,
Таблица 9. Файл testR.ini для модуля SimSensor.py.
Секция Параметр Рекомендуемое значение Описание
[simOptions] ModelTime Моделируемое время, единиц
Iterations і Количество итераций, единиц
[pageOptions] PageCount Количество моделируемых информационных ресурсов, единиц
MinPageLoadTime і Минимально возможное время «скачивания» одного информационного ресурса
MaxPageLoadTime 40 Максимально возможное время «скачивания» одного информационного ресурса
[sensorOptions] MinSend Alert Time 1 Минимальная продолжительность времени между «отправкой» сенсором и получения системой мониторинга уведомления о найденном изменении в состоянии ресурса
MaxSendAlertTime 3 Максимальная продолжительность времени между «отправкой» сенсором и получения системой мониторинга уведомления о найденном изменении в состоянии ресурса
[logOptions] LogDirectory logs\\ Директория для размещения соответствующих данному этапу журналов («логов»)
Математические структуры и моделирование. 2003. Вып. 11.
149
Таблица 9. Файл testR.ini для модуля ЗітЗеп80г.ру(продолжение)
Секция Параметр Рекомендуемое значение Описание
LogFileName testlog.txt Имя файла главного журнала событий
LogTraceToFile 1 Логический ключ (1 - True / 0 - False), который отвечает за включение протоколирования действий при выполнении данного модуля
Таблица 10. Файл serN-M.ini для модуля SimSensor.pv.
Секция Параметр Рекомендуемое значение Описание
[testOptions] Commonlni testR.ini Ссылка на файл общих настроек для текущего эксперимента
[simOptions] RandomSeed Смещение генератора случайных чисел (integer)
[dbOptions] MainDBName serN_M Имя базы данных, в которой хранится необходимый набор
StatDBName testR_M Имя базы данных, в которой будут сохраняться значения наблюдаемых вели-4HH(ReportStatVars)
[reportOptions] Report Directory M\\ Директория для размещения соответствующих данному набору статистических данных, которые будут собраны в ходе эксперимента. Буква М совпадает с номером обрабатываемого набора
Report StatVars needfresh, freshness, sumsize, nowprocessing Имена переменных, для которых в процессе имитации идёт сбор общей «статистики». Значения данного параметра используются при создании соответствующих таблиц базы данных и файлов отчётов
Как можно заметить, различие файлов настроек для SimRobot.py и для SimSensor.pv минимально. Исчезли параметры, специфичные для концепции «роботов» (RobotQuantity, StepLogCycles, RouteDBName, OtherReportStatVars), и появились параметры, специфичные для концепции «сенсоров» (MinSendAlertTime, MaxSendAlertTime, ReportStatVars{«nowprocessing»}). Чтобы пояснить принципы использования новых параметров файлов настроек, рассмотрим блок-схемы (ем. рисунок
4) обобщённых алгоритмов, используемых в модуле SimSensor.pv. Заранее следует оговорить, что последующее упоминание термина «робот» связано с изменением его смысла. Далее нужно иметь в виду то, что в контексте
150 И.А. Земсков. SimCOSAR: программный комплекс моделирования...
Рис. 4. Блок-схемы алгоритмов модуля SimSensor.py.
концепции «сенсоров» робот сильно «видоизменился». Наиболее заметными изменениями являются потеря роботом функции циклического обхода ресурсов и приобретение функции «ожидания вызова».
Дадим пояснения к некоторым блокам на схеме А (см. рисунок 4), опуская описание блоков, которые повторяют блоки модуля SimRobot.py:
• Процесс поступления «запросов» на информационные ресурсы. В модуле описан класс Queries (наследник класса Process python-модуля SimPv), реализующий наступление событий, которые мы условно называем «запросами информационных ресурсов». Обобщённый алгоритм представлен схемой Б на рисунке 4.
• Процесс «скачивания» роботом изменившихся информационных ресурсов. Блок подразумевает функционирование объектов типа Crawl, обобщённый алгоритм которых представлен схемой В на рисунке 4. Стоит отметить, что объекты класса Crawl модуля SimSensor.py заметно отличаются от объектов класса Crawl модуля SimRobot.py. Например, объек-
Математические структуры и моделирование. 2003. Вып. 11.
151
ты класса Crawl теперь создаются только в процессе функционирования класса Queries (точнее, при обнаружении изменившегося ресурса), а уничтожаются сразу же после завершения «скачивания» ресурса,
• Процесс сбора статистической информации. Принципы функционирования данного блока подробно описаны для модуля SimRobot.py, а здесь следует добавить, что для данного модуля немного изменился список статистических переменных (мы приведём его позже).
Теперь рассмотрим некоторые блоки на других оставшихся схемах рисунка 4, Начнём со схемы Б:
• Получить из таблицы queries в QryTime время ближайшей группы событий запросов, В специальную переменную QryTime попадает результат SQL-запроса, который берёт первую запись среди упорядоченных по полю qtime записей,
• Получить из таблицы queries ближайшую группу событий запросов, Выполняется SQL-запрос, на который возвращаются записи таблицы queries с равными значениями поля qtime и равными текущему модельному времени,
• Создать процесс скачивания изменившегося ресурса. Создаётся объект типа Crawl, которому как параметр передаётся номер требуемого информационного ресурса. Далее вызывается процедура activate python-модуля SimPv, которая включает вновь созданный объект в главный цикл моделирования, а именно планирует все события, связанные с объектом. На этом шаге процесс поступления «запросов» продолжает функционировать дальше и запущенный процесс скачивания уже никоим образом с ним не взаимодействует.
Далее рассмотрим некоторые блоки схемы В:
• Определение времени уведомления робота об изменении ресурса (AlertTime), Для выполнения данной операции мы используем генератор случайных чисел, равномерно распределённых в интервале [Min Send AlertTime, Max Send AlertTime], Полученный результат помещается в локальную переменную AlertTime,
• Обработка событий других процессов в течение времени AlertTime, Ранее мы уже описывали аналогичные блоки, здесь же нужно добавить то, что оператору yield передаётся в качестве параметра значение AlertTime, которое используется для вычисления момента возвращения управления в данное место,
• Определение времени (LdTime) скачивания роботом изменившегося ресурса. Для выполнения данной операции мы используем генератор случайных чисел, равномерно распределённых в интервале [.MinPageLoadTirne, MaxPageLoadTirne]. Полученный результат помещается в локальную переменную LdTime, Однако все эти действия выполняются только в том случае, когда ресурс доступен для скачивания. Иначе время скачивания равно О,
• Обработка событий других процессов в течение времени LdTime,
Здесь оператору yield передаётся в качестве параметра значение LdTime,
152 II.Л. Земсков. SimCOSAR: программный комплекс моделирования...
которое используется для вычисления момента возвращения управления в данное место,
• Изменение свойств ресурса, скачанного роботом. Блок меняет значения соответствующих (changed, crawled) свойств ресурса (объект типа Page) с тем, чтобы обозначить новое состояние ресурса и наблюдаемой среды. Если за время скачивания произошло ещё одно изменение, то оно останется неизвестно системе вплоть до нового «внешнего» запроса. Однако, если изменение произошло в период передачи уведомления и до начала скачивания ресурса, то изменение станет известно,
• Обновление значений соответствующих статистических переменных, В данный момент изменяется значение переменных, которые характеризуют процесс скачивания ресурсов (SumSize, MinWaitCrawl, MaxWaitCrawl, AvrWaitCrawl, MaxProcessing, NowProcessing),
Приведём полный список имеющихся в модуле статистических переменных, давая необходимые пояснения:
• MinWaitCrawl - минимальное время, которое прошло с момента наступления события изменения ресурса до события завершения скачивания изменившегося ресурса роботом. Определяется на основе всего массива ресурсов, когда-либо скачанных роботом,
• MaxWaitCrawl - максимальное время, которое прошло с момента наступления события изменения ресурса до события завершения скачивания изменившегося ресурса роботом. Определяется на основе всего массива ресурсов, когда-либо скачанных роботом,
• AvrWaitCrawl суммирует время ожидания «обновления» для каждого скачанного ресурса и делится на общее количество скачанных за модельное время ресурсов;
• NowProcessing хранит количество закачиваемых роботом ресурсов в данный момент модельного времени. Является нашей попыткой оценить нагрузку на систему мониторинга в варианте концепции «сенсоров». Каждые 5000 единиц модельного времени значение переменной помещается в таблицу nowprocessing базы testR_M,
• MaxProcessing хранит максимальное количество ресурсов, одновременно закачиваемых роботом за всё время моделирования,
• NeedFresh хранит количество ресурсов, которые изменили своё состояние (т.е. изменились) и которые необходимо посетить роботу, чтобы обновить имеющуюся информацию. Каждые 5000 единиц модельного времени значение переменной помещается в таблицу needfresh базы testR_M,
• Freshness - вычисляется значение свежести индекса поисковой системы на основе значения переменной NeedFresh (см, формулу в [1]), Каждые 5000 единиц модельного времени значение переменной помещается в таблицу freshness базы testR_M.
• SumSize вычисляет общий объём скачанной роботом системы мониторинга информации. Каждые 10000 единиц модельного времени значение переменной помещается в таблицу sumsize базы testR_M,
При каждом запуске модуля SimSensor.py в файл главного журнала («лог»
Математические структуры и моделирование. 2003. Вып. 11.
153
выполнения модуля) попадает новая порция следующей информации:
• дата и время начала работы модуля;
• версия используемого модуля SimSensor.py;
• полный путь к файлу и само имя файла используемых настроек набора;
• счётчик итераций;
• используемое смещение генератора случайных чисел;
• блок статистки:
* NowProcessing содержит количество скачиваемых ресурсов на момент окончания цикла моделирования;
* MaxProeessing;
* MinWaitCrawl;
* MaxWaitCrawl;
* AvrWaitCrawl;
* SumSize;
• дата и время завершения работы модуля,
8. Модуль SimReport.py
Основная задача данного модуля заключается в извлечении статистики, которая была накоплена в результате функционирования модулей SimRobot.py, SimRobotM.py, SimSensor.py, Извлечение происходит для каждого набора информационных ресурсов отдельно, тж, модулю для работы необходимо указать два параметра: во-первых, название директории («testR»), а во-вторых, имя файла с настройками используемого набора ресурсов («serN-M.ini»), Поэтому для извлечения статистики для всей серии необходимо выполнить модуль SimReport.py ровно М раз, т.е, столько раз, сколько наборов в серии. Все эти вызовы модуля можно собрать в один пакетный файл (мы создали файл герои .bal и поместили все команды в него), В дальнейшем для извлечения всей статистики необходимо вызвать на выполнение только этот пакетный файл.
Файлы настроек «serN-M.ini» уже описаны ранее при описании модулей SimRobot.py и SimSensor.py, поэтому ограничимся только указанием используемых параметров. Во-первых, это параметр StatDBName секции [dbOptions]. Во-вторых, это параметры ReportDirectory, ReportStatVars, OtherReportStatVars секции [reportOptions]. Также в работе модуля используются два параметра файла eommon.ini, а именно ReportFileExtension и ReportValuesDelimiter.
Таким образом, основной цикл модуля осуществляется по значениям параметров ReportStatVars + OtherReportStatVars (если есть), и на каждом шаге цикла выполняется SQL-запрос (например, на первом шаге может быть запрос: «select * from needfreshl order by sid») к соответствующей текущему параметру таблице. Корень имени таблицы совпадает с именем параметра, а в окончании имени добавляется цифра, которая означает номер итерации. Результаты запроса построчно записываются в файл (именуемый как «имя параметра» + ReportFileExtension), причём значения разных столбцов (всего два столбца: время замера значения и само значение) в файле разделены значением параметра Report ValuesDelimiter, Для обработки каждого параметра создаётся объект
154 II.Л. Земсков. SimCOSAR: программный комплекс моделирования...
Таблица 11. Пример фрагмента таблицы с объединёнными данными для переменной
freshness.
0 100 100 100 100 100 100 100 100 100
5000 99,9 99,6 99,1 99,9 99,6 99,2 99,9 99,6 99,2
10000 99,8 99,2 98,3 99,8 99,1 98,3 99,8 99,1 98,3
15000 99,7 98,7 97,4 99,8 98,7 97,4 99,8 98,7 97,5
30000 99,7 98,3 96,6 99,7 98,3 96,6 99,7 98,3 96,6
класса Report. Класс Report описан в рассматриваемом модуле и предоставляет единообразный стиль работы с таблицами статистики и файлами отчётов.
При каждом запуске модуля SimReport.pv в файл главного журнала выполнения модуля попадает новая порция следующей информации:
• дата и время начала работы модуля;
• версия используемого модуля SimReport.pv;
• полный путь к файлу и само имя файла используемых настроек набора;
• количество созданных файлов отчётов;
• дата и время завершения работы модуля.
9. Модуль SimMergeReports.py
CSV-файлы, которые получаются в результате работы модуля SimReport.pv, удобно использовать, только когда необходимо проанализировать результаты одного прогона (имитация одной стратегии на одном наборе). Однако естественным желанием стало создание графиков, на которых можно было бы одновременно отображать результаты нескольких прогонов. Используемые нами программы, такие как Microsoft Excel, StatSoft STATISTICA, требуют дополнительных усилий по объединению данных (например, в рамках одной таблицы) с целью последующего удобного построения «Multiple» (термин взят из STATISTICA) графиков. Таким образом, в качестве результата объединения нам необходимо получить таблицу (файл формата esv), в которой первый столбец будет содержать время замера и который останется общим, а в остальные столбцы попадут результаты замеров. Пример необходимого результата можно увидеть в таблице 9.
Ручное объединение необходимых данных занимает много времени и сил, поэтому был разработан модуль SimMergeReports.py, который, получая на входе два параметра (имя директории и имя файла настройки), выдаёт в результате файл в формате esv, аналогичный по структуре таблице 9. Так как до сих пор нам было необходимо объединять результаты только в рамках одного эксперимента, то и файл настроек мы решили хранить в ini-директории эксперимента («testR»), Структура файла настройки представлена в таблице 12.
Математические структуры и моделирование. 2003. Вып. 11.
155
Таблица 12. Файл merge.ini (М - количество объединяемых наборов).
Секция Параметр Рекомендуемое значение Описание
[simOptions] Iterations і Количество итераций, единиц
[dbOptions] DBNamel testR 1 Имя базы данных, содержащей статистические результаты, полученные в эксперименте R по одному из наборов. Получает номер 1
DBNameM testR_M Имя базы данных, содержащей статистические результаты, полученные в эксперименте R по одному из наборов. Получает номер М
[logOptions] LogDirectory logs\\ Директория для размещения соответствующих данному этапу журналов («логов»)
LogFileName merge.txt Имя файла главного журнала событий
LogTraceToFile і Логический ключ (1 - True / 0 - False), который отвечает за включение протоколирования действий при выполнении данного модуля
[reportOptions] ReportsCount M Общее количество наборов, статистические результаты которых будут объединены в единые файлы
Report StatVars needfresh, freshness, sumsize Имена переменных, накопленные данные которых необходимо «объединить»
[out Options] outDirectory res\\ Директория, в которую будет осуществлён вывод файлов с объединёнными данными
outFileExtension • CSV Расширение файлов с объединёнными данными
outValuesDelimiter Разделитель значений в файле
Алгоритм работы модуля становится очевидным после изучения файла настроек. Остаётся пояснить несколько моментов:
• для объединения нескольких значений полей из разных таблиц использована sql-конструкция «LEFT JOIN»;
• директория «res\\» является поддиректорией директории эксперимента;
• в рамках одной статистической переменной объединяемые данные из разных наборов должны иметь одинаковые времена измерения;
• объединяемые таблицы могут принадлежать к различным экспериментам, но в нашей работе мы пока не пользовались данной возможностью;
• вся работа модуля осуществляется средствами объектов класса Report.
При каждом запуске модуля SimMergeReports.py в файл журнала выполне-
156 II.Л. Земсков. SimCOSAR: программный комплекс моделирования...
ния модуля попадает новая порция следующей информации:
• дата и время начала работы модуля;
• версия используемого модуля SimMergeReports.py;
• полный путь к файлу и само имя файла используемых настроек;
• количество созданных файлов отчётов;
• дата и время завершения работы модуля,
10. Замечания по использованию комплекса
Использование пакетных файлов в работе комплекса позволяет организовать непрерывный процесс вычислений и тем самым уменьшить простой вычислительной техники. Однако предварительные эксперименты показали, что использование одного компьютера, пусть даже очень мощного на данный момент (Pentium 4, 512Mb. 60Gb HDD), сильно затягивает во времени реализацию даже самого простого плана экспериментов, В связи с этим возникло желание воспользоваться мощностью вычислительного кластера. Однако задача адаптации нашего комплекса для использования в кластере видится как очень трудоемкая, так как требует пересмотра всех основных принципов функционирования уже созданного кода. Под адаптацией мы имеем в виду переход на использование специализированных библиотек, которые позволяют реализовать распределённые вычисления (например MPI), В силу многих объективных причин мы решили отложить работы по адаптации комплекса под кластер на будущее, но отказываться от идеи задействовать в вычислениях многим больше одного компьютера мы не решились. Летний период отпусков и студенческих каникул позволил нам надеяться на возможность использования обыкновенного учебного компьютерного класса.
Однако на этом пути встают некоторые ограничения:
• как правило, в классах используется не особо производительная вычислительная техника с ограниченными ресурсами;
• правила техники безопасности запрещают оставлять класс без присмотра. Это требование означает, что один исследователь должен присутствовать во время работы класса и вариант «оставить считать на ночь» исключён.
Первое ограничение особенно касается скорости взаимодействия с жёсткими дисками, так как основная работа комплекса заключается во взаимодействии (много запросов к базам данных) с устройствами этого вида. При разработке нашего комплекса мы учли этот нюанс и постарались минимизировать работу с дисками за счёт переноса некоторых данных в ОЗУ, Однако из-за большого объёма (сотни мегабайт) данных перенос не коснулся таблиц events и queries, В данной статье описан комплекс уже с учётом данных изменений.
Второе ограничение является более серьёзным, так как не позволяет осуществлять имитацию большого количества информационных ресурсов (например порядка нескольких десятков миллионов) и тем более осуществлять работу комплекса в автономном режиме. Для преодоления данного ограничения можно было бы воспользоваться методологией сериализации (serialize), которая позволила бы, во-первых, останавливать работу модулей с сохранением текущего со-
Математические структуры и моделирование. 2003. Вып. 11.
157
стояния всех переменных, а во-вторых, возобновлять работу с восстановлением ранее сохранённого состояния. Однако в используемой библиотеке SimPv стандартных средств осуществления сериализации состояния модельной среды нет, А самостоятельная разработка таких средств (ввиду их сложности) рассматривается нами только в перспективе проведения крупномасштабных исследований и поэтому на данном этапе нам не доступна.
Заключение
В статье представлены результаты очередного этапа работ по исследованию концепций мониторинга информационного поля Интернет, а точнее, описан программный комплекс имитационного моделирования SimCOSAR (SIMulation COncepts Sensors And Robots), В ходе пробных экспериментов были выявлены сложности в использовании комплекса (описаны в предыдущем параграфе), некоторую часть мы постарались учесть при разработке, а часть сложностей находят своё отражение в создаваемом плане проведения экспериментального исследования.
Литература
1. Земсков И.А. Имитационное исследование концепций сбора информации для индексов поисковых систем // Математические структуры и моделирование, 2002. Вып.10. С. 172-191
2. Р. Шеннон. Имитационное моделирование систем - искусство и наука. М.: Мир, 1978.
3. The Eleventh International World Wide Web Conference. - http://www2002.org/
4. SimPy: A Python-based simulation package.
- http://sourceforge.net/projects/simpy/
5. Python home page. - http://www.python.org/
6. Марков A.А. Моделирование информационно-вычислительных процессов. Издательство МГТУ им. Н.Э. Баумана, 1999.
