Моделирование сети с тремя подсетями в среде AnyLogic

Компьютерное моделирование является технологией предсказания того, как будет себя вести новая или изменённая система. Оно имеет более широкий спектр применения, нежели чисто математические методы, и на протяжении многих лет оно помогло своим пользователям сэкономить миллионы долларов. Даже наиболее сложные реально существующие системы могут быть смоделированы при помощи системы AnyLogic. Перечень возможностей использования компьютерного моделирования занимает много страниц и при этом постоянно увеличивается.
AnyLogic — программное обеспечение для имитационного моделирования, разработанное российской компанией The AnyLogic Company. Инструмент обладает современным графическим интерфейсом и позволяет использовать язык Java для разработки моделей.
В начале 1990-х в компьютерной науке наблюдался большой интерес к построению математически трактуемого описания взаимодействия параллельных процессов. Что сказалось на подходах к анализу корректности параллельных и распределённых программ. Группа учёных из Санкт-Петербургского Политехнического университета разработала программное обеспечение для анализа корректности системы; новый инструмент назвали COVERS. В 1998 г. успех этого исследования вдохновил лабораторию организовать коммерческую компанию с миссией создания нового программного обеспечения для имитационного моделирования. Акцент при разработке ставился на прикладные методы: моделирование стохастических систем, оптимизацию и визуализацию модели. Новое программное обеспечение, выпущенное в 2000 г., было основано на последних преимуществах информационных технологий: объектно-ориентированный подход, элементы стандарта UML, языка программирования Java.
Модели AnyLogic могут быть основаны на любой из основных парадигм имитационного моделирования: дискретно-событийное моделирование, системная динамика, и агентное моделирование.
Системная динамика и дискретно-событийное (процессное) моделирование, под которым мы понимаем любое развитие идей GPSS — это традиционные устоявшиеся подходы, агентное моделирование — относительно новый. Системная динамика оперирует в основном с непрерывными во времени процессами, тогда как дискретно-событийное и агентное моделирование — с дискретными.

1. Цель работы

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

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

Сервер обрабатывает запросы, поступающие с автоматизированных рабочих мест с интервалами, распределенными по по экспоненциальному закону (exponential( 1 )). Время обработки серверами одного запроса распределено по триангулярному закону (triangular( 0.5, 1, 1.5 )) с начальным значением вместимости 2. Очереди queue имеют входной буфер ёмкостью 100 запросов. Необходимо построить имитационную модель для определения оптимальной ёмкости объектов queue, способствующей работе сети без потери пакетов. Определить наиболее выгодные значения ёмкостей объектов queue, при увеличении количества одновременно обрабатываемых запросов главным сервером до 2. На Рисунке 2.1 приведены объекты «AnyLogic», которые будут использованы для создания схемы процесса.

Рисунок 2.1 Схема

Работа выполнена в версии продукта «AnyLogic Personal Learning Edition 7.1.2». Модель «AnyLogic» представляет собой файл с именем, заданным пользователем, и расширением «.alp».

3. Ход работы

3.1Создание блок-схемы

В блок-схеме присутствует 5 объектов "source". Объект Source (Сlient_n) генерирует заявки определенного типа. Обычно он используется в качестве начальной точки диаграммы процесса, формализующей поток заявок. В нашем примере заявками будут запросы на обработку главным сервером, а объекты Source будут моделировать их поступление через временной интервал, распределенный по экспоненциальному закону (exponential( 1 )) (Рисунок 3.1).

Рисунок 3.1 Свойства объектов Source

Следующий объект — queue, в модели присутствует 3 объекта. Он моделирует очередь заявок, ожидающих приема объектами, следующими заданным объектом в диаграмме процесса. В нашем случае он будет, как уже отмечалось, моделировать очередь запросов, ждущих освобождения серверов. Начальное значение вместимости очередей задано значением 100 (Рисунок 3.2).

Рисунок 3.2 Свойства объектов queue

Следующим в нашей диаграмме процесса расположен объект delay. Он задерживает заявки на заданный период времени, представляя в нашей модели непосредственно серверы, на которых обрабатываются запросы. Время заданно триангулярным законом (triangular( 0.5, 1, 1.5). (Рисунок 3.3). Флажок «Включить» сбор статистики необходим, чтобы включить сбор статистики для этого объекта. В этом случае по ходу моделирования будет собираться статистика по количеству запросов, обрабатываемых сервером на момент завершения сбора статистики.

Рисунок 3.3 Свойства объекта Delay

Последним в диаграмме нашей дискретно-событийной модели находится объект sink(output). Этот объект уничтожает поступившие заявки. Обычно он используется в качестве конечной точки потока заявок (и диаграммы процесса соответственно). В нашем случае он выводит из модели обработанные сервером запросы.

В конечном итоге получаем следующую блок-схему (Рисунок 3.4), где объекты source представлены именами «Client_1 - Client_5», queue с именами «queue», «queue_1» и «queue_3», delay(server) именами «delay_1», «delay_2» и «delay», и где sink(output) с именами «sink_1», «sink_2» и «output» подсчитывают и уничтожают обслуженных и не обслуженных (не поместившихся в очереди или не дождавшихся по таймауту) клиентов.

Рисунок 3.4 Блок-схема

3.2 Сбор статистики

Проведём тестирование модели в режиме виртуального времени без ограничения времени. За 9999.51с виртуального времени получены следующие результаты (Рисунок 3.5):

Рисунок 3.5 Симуляция

На статистике очереди «queue_1» (Рисунок 3.6) можно увидеть, что на вход поступило 20028 агентов, на выход 5028 агентов. Не дождались своей очереди 99 агентов. Количество вытесненных агентов - 14901. Средняя длина – 99.352.

Рисунок 3.6 Статистика queue_1

На статистике очереди «queue_2» (Рисунок 3.7) можно увидеть, что на вход поступило 19940 агентов, на выход 5021 агент. Не дождались своей очереди 100 агентов. Количество вытесненных агентов - 14819. Средняя длина – 99.24.

Рисунок 3.7 Статистика queue_2

На статистике очереди «queue» (Рисунок 3.8) можно увидеть, что на вход поступило 20022 агентов, на выход 9999 агентов. Не дождались своей очереди 100 агентов. Количество вытесненных агентов - 9923. Средняя длина – 99.73.

Рисунок 3.8 Статистика queue

На статистике главного сервера delay (Рисунок 3.9) видно, что на вход ему поступило 9999 агент, на выход – 9998, 1 агент на момент завершения тестирования остался внутри объекта.

Рисунок 3.9 Статистика delay

3.3 Определение оптимальной ёмкости объектов queue

Важно не допустить переполнения очереди запросов в объекте queue, вследствие чего будет необратима потеря заявок в sink. В результате моделирования за время 9999.51с, общее количество необработанных заявок – 39643, а 299 ожидают своей очереди. Эксперимент показал, что вместимость объектов queue не оптимальна.

Определим оптимальную ёмкость объектов queue:

Увеличим вместимость очередей queue до 5000 (Рисунок 3.10):

Рисунок 3.10 Статистика queue - 5000

Увеличим вместимость очередей queue до 10000 (Рисунок 3.11):

Рисунок 3.10 Статистика queue - 10000

Увеличим вместимость очередей queue до 12000 (Рисунок 3.11):

Рисунок 3.11 Статистика queue - 12000

Статистика на Рисунке 3.11 показала, что количество не обслуженных агентов в подсетях сведено к минимуму. Таким образом, для дальнейшей оптимизации работы сети следует увеличить только вместимость очереди «queue».

Увеличим вместимость очереди queue до 20000 (Рисунок 3.12):

Рисунок 3.12 Статистика «queue» – 20000

В результате тестирования за время 9942.08 сек. полная оптимизация работы сети была достигнута: количество потерянных запросов 0, количество обработанных запросов 29929 (где количество запросов, обработанных главным сервером - 9980) при вместимости 12000, 12000, 20000 очередей queue_1, queue_2 и queue соответственно.

Рисунок 3.13 Диаграмма queue - outPreempted

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

3.4 Увеличение вместимости главного сервера.

Определим наиболее выгодные значения ёмкостей объектов queue, при увеличении количества одновременно обрабатываемых запросов главным сервером «delay» до 2 (Рисунок 3.14).

Рисунок 3.14 Свойства delay(server)

При вместимости 5000, 5000, 5000 очередей queue_1, queue_2 и queue соответственно и количестве одновременно обрабатываемых запросов главным сервером (delay) – 2 присутствуют необработанные заявки (Рисунок 3.15).

Рисунок 3.15 Статистика – 5000

Увеличим вместимость очередей queue_1, queue_2 и queue до 10000 (Рисунок 3.16):

Рисунок 3.16 Статистика – 10000

Тестирование (Рисунок 3.16) показало, что при увеличении вместимости очередей до 10000, количество необработанных заявок сведено к минимуму (124). Таким образом, определены наиболее выгодные значения ёмкостей queue, при вместимости главного сервера (delay) – 2. Исследование модели (увеличение вместимости главного сервера до 2) также показало, что зависимость минимального значения вместимости queue от количества одновременно обрабатываемых заявок главным сервером delay, без погрешностей прямо пропорциональна.

Выводы

В ходе выполнения курсовой работы были изучены возможности программы AnyLogic при построении, исследовании и оптимизации модели запросов к серверу простой системы, представленной сетью с тремя подсетями, которая определяет количество обработанных и потерянных заявок сервером. В процессе построения блок-схемы модели была изучена "Библиотека моделирования процессов" и использованы такие объекты из библиотеки, как source, queue, delay, sink и подробно описаны их функции в данной системе.

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

Список использованной литературы

1. Боев, В.Д. Компьютерное моделирование: Пособие для практических занятий, курсового и дипломного проектирования в AnyLogic7 [Текст] / В.Д.Боев — СПб.: ВАС, 2014. ? 432 с.

2. Киселева, М.В. Имитационное моделирование систем в среде AnyLogic: учебно-методическое пособие [Текст] / М. В. Киселёва — Екатеринбург: УГТУ - УПИ, 2009. — 88 с.

3. Концептуальное проектирование систем в AnyLogic [Электронный ресурс] // Интернет университет информационных технологий. ? URL: http://www.intuit.ru/studies/courses/4818/1066/info

4. AnyLogic [Электронный ресурс] // Википедия. ? URL: http://ru.wikipedia.org/wiki/AnyLogic

Моделирование сети с тремя подсетями в среде AnyLogic