Модель обработки запросов сервером

Из рис. 1.4 видно, что отсутствующих факторов нет. Факторы А, В и С находятся в различных группах смешивания по два фактора в каждом. Невозможно будет судить об эффектах, т. е. о влиянии на отклик взаимодействий двух факторов. В некоторых случаях этого будет достаточно.

Нажмите кнопку Cancel (Отмена).

В диалоговом окне Screening Experiment Generator (Генератор отсеивающего эксперимента) в группе Fraction (Часть дробного эксперимента) установите Full (ПФЭ). Под Run Count появится число 8.

Обратите внимание, что кнопка Alias Groups (Группы смешивания) при установке полного факторного эксперимента Full (ПФЭ) не будет активной.

Теперь необходимо создать Plus - операторы и вставить их в нижнюю часть модели Прямая задача. Для этого нажмите кнопку Insert Experiment (Вставить эксперимент), расположенную в левой нижней части диалогового окна Screening Experiment Generator (Генератор отсеивающего эксперимента).

Так как была выбрана опция Generate Run Procedure, то создана стандартная процедура запуска с именем Dis_Server_Run. Появится ее диалоговое окно, дающее возможность пользователю изменить процедуру запуска согласно своим требованиям (Рис. 1.5).

Перейдите, пользуясь клавишами вверх-вниз, в конец процедуры запуска. Там в разделе Set up your own run conditions (Задайте свои условия наблюдения) имеются две команды START, между которыми находится команда RESET (Рис. 1.6).

Поясним назначение этих команд.

Первой командой START

DoCommand("START 100,NP");  /*Get past the Startup Period. */

определяется количество прогонов в неустоявшемся режиме.

Подразумевается, что если моделирование выполняется долго, то система приходит в стационарное состояние. Сколько времени следует вести моделирование, чтобы достичь стационарного состояния? Часто ответ на этот вопрос можно получить из опыта экспериментирования с моделью. Команда RESET служит для этого. Она сбрасывает в ноль накопленную на неустоявшемся режиме статистику без удаления транзактов из процесса моделирования.

Второй командой START

DoCommand("START 1000,NP");  /*Run the Simulation. */

определяется количество прогонов в наблюдении, т. е. количество прогонов, которое было определено ранее при тактическом планировании эксперимента: N = 9604. Измените 1000 на 9604 (Рис. 1.7).

Корректировка процедуры запуска возможна до и после того, как она будет добавлена к объекту "Модель".

После корректировки нажмите Ok.

Сгенерированный Plus - эксперимент представлен ниже. Изучите его. Это необходимо для создания собственных экспериментов, отличающихся от стандартных экспериментов GPSS World.

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

Plus - эксперимент содержит также вызов Plus - процедуры запуска. Процедура запуска осуществляет связь между генерируемым экспериментом и процессом моделирования. Она вызывается столько раз, сколько требуется сделать наблюдений. Так как процедура запуска вызывается Plus - экспериментом, ей разрешается вызывать библиотечную процедуру DoCommand и, следовательно, выполнять RMULT, CLEAR, RESET и многие другие команды GPSS. Поэтому все команды, необходимые для определения условий наблюдения, например, обнуление сохраняемых ячеек, следует помещать в процедуру запуска.

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

****************************************************
*                   Dis_Server                     *
*        Факторный отсеивающий эксперимент         *
****************************************************
Dis_Server_Results  MATRIX  ,2,2,2
  INITIAL Dis_Server_Results,UNSPECIFIED
Dis_Server_NextRunNumber EQU  0
EXPERIMENT Dis_Server() BEGIN

  /*  Наблюдение 1  */
  T1_ = 60;
  Koef = 0.5;
  Q_ = 300000;
  IF (StringCompare(DataType(Dis_Server_Results[1,1,1]),
      "UNSPECIFIED")'E'0)
  THEN BEGIN
/* Установить начальное значение переменной количества наблюдений */
  Dis_Server_NextRunNumber = 1;
/*  Записать данные наблюдения и запустить процесс моделирования*/
  Dis_Server_GetResult();
  Dis_Server_Results[1,1,1] = N$ObrZap/N$KolZap;
  END;
  /*  Наблюдение 2  */
  T1_ = 60;
  Koef = 0.5;
  Q_ = 700000;
  IF (StringCompare(DataType(Dis_Server_Results[1,1,2]),
      "UNSPECIFIED")'E'0)
  THEN BEGIN
/*  Записать данные наблюдения и запустить процесс моделирования */
  Dis_Server_GetResult();
  Dis_Server_Results[1,1,2] = N$ObrZap/N$KolZap;
  END;
  /*  Наблюдения 3 - 7 для краткости пропущены */
  /*  Наблюдение 8  */
  T1_ = 180;
  Koef = 1.5;
  Q_ = 700000;
  IF (StringCompare(DataType(Dis_Server_Results[2,2,2]),
      "UNSPECIFIED")'E'0)
  THEN BEGIN
/*  Записать данные наблюдения и запустить процесс моделирования */
  Dis_Server_GetResult();
  Dis_Server_Results[2,2,2] = N$ObrZap/N$KolZap;
  END;
/*  Эффекты смешивания в дробном факторном эксперименте */
  SE_Effects(Dis_Server_Results,"I");
END;
*******************************************************
*         Процедура запуска наблюдения                *
*******************************************************
PROCEDURE Dis_Server_GetResult() BEGIN
/* Выполнить указанное число прогонов и записать результаты. */
/*  Факторы для этого наблюдения уже были определены.  */
TEMPORARY CurrentYield,ShowString,CommandString;
/*  Вызов процедуры запуска  */
    Dis_Server_Run(Dis_Server_NextRunNumber);
    CurrentYield = N$ObrZap/N$KolZap;
    ShowString = PolyCatenate("Run ",String(Dis_Server_NextRunNumber),". ", "" ); 
    ShowString = PolyCatenate(ShowString,"  Yield=",String(CurrentYield),". "); 
    ShowString = PolyCatenate(ShowString," T1_=",String(T1_), ";" ); 
    ShowString = PolyCatenate(ShowString," Koef=",String(Koef), ";" ); 
    ShowString = PolyCatenate(ShowString," Q_=",String(Q_), ";" ); 
    CommandString = PolyCatenate("SHOW """,ShowString,"""", "" ); 
    DoCommand(CommandString);
    Dis_Server_NextRunNumber = Dis_Server_NextRunNumber + 1;
    RETURN CurrentYield;
END;
*******************************************************
*                 Процедура запуска                   *
*******************************************************
PROCEDURE Dis_Server_Run(Run_Number) BEGIN
    DoCommand("CLEAR OFF");      /* Использовать OFF для сохранения результата. */
/* Увеличьте число команд RMULT, если у вас большее число ГСЧ. */
/* Задать новые случайные числа всем потокам случайных чисел. */
    TEMPORARY CommandString;
/* Вычислить, прежде чем перейти к DoCommand. */
    CommandString = Catenate("RMULT ",Run_Number#111);
/* DoCommand контролирует строку в глобальном контексте. */ 
    DoCommand(CommandString); 
/* Установить собственные условия наблюдения. */
    DoCommand("START 100,NP");     /* Пройти неустоявшийся режим. */
    DoCommand("RESET");                  /* Начать период измерений. */
    DoCommand("START 9604,NP");  /* Провести моделирование. */
END;

Проведем эксперимент. Для вызова эксперимента предназначена команда CONDUCT. Однако за функциональной клавишей [F11] была закреплена соответствующая команда CONDUCT (Edit / Settings / Function Keys (Правка / Настройки / Функциональные клавиши)).

Проведите трансляцию, т. е. создайте объект "Процесс моделирования", для чего нажмите [Ctrl]+[Alt]+[S] или выполните команду Command / Create Simulation (Команда / Создать процесс моделирования).

При отсутствии ошибок в сгенерированном эксперименте в окне Journal (Журнал) появится сообщение (Рис. 1.8), свидетельствующее об отсутствии ошибок. Нажмите функциональную клавишу [F11]. Эксперимент начинает работать.

В ходе выполнения сгенерированного эксперимента автоматически создается отчет, который по готовности записывается в окно Journal (Журнал) объекта "Процесс моделирования". Фрагмент отчета для четырех наблюдений (Run1 … Run4) показан на рис. 1.9. В отчете содержатся Yield - целевая функция и значения факторов, при которых получение значение целевой функции.

Так как эксперимент включает 8 наблюдений по 9604 прогонов в каждом из них, то будет выдано 8 отчетов (на рис. 1.9 в целях сокращения показаны только первые четыре отчета). Окончательные результаты моделирования после статистической обработки будут выведены в виде таблицы Anova (Рис. 1.10).

В таблице каждый фактор и взаимодействие факторов представлены отдельной строкой. В каждой строке для всех эффектов указаны коэффициенты, с которыми они входят в целевую функцию (столбец Effect), а для главных эффектов (А, В, С) - суммы квадратов отклонений - столбец Sum of Squares.

В столбце Degrees of Freedom приведены степени свободы соответствующих измерений.

В столбце F-for Only Main Effects - вычисленные значения F-статистик для главных эффектов, а в столбце Critical Value of F (p=0,5) - соответствующие критические значения F-распределения для уровня значимости 50%.

В строке Error показаны остаточная составляющая дисперсии и соответствующая степень свободы.

В строке Total - общая сумма квадратов ошибок по всему эксперименту.

В строке Greand - среднее значение результата исследования (в примере - вероятности) по данным всего эксперимента.

Чем больше значение F-статистики (F-for Only Main Effects), тем сильнее эффект. Эффект, а, следовательно, и фактор, считается значимым, если превышает критическое значение (Critical Value of F (p=0,5)).

В данном примере факторы А и В являются значимыми, так как их F-статистики больше критического значения, равного 7,71. Обратите внимание, что эффекты факторов А и В противоположны.

Таким образом, по результатам моделирования можно сделать вывод, что при данном потоке и характеристиках сервера вероятность обработки запросов в среднем составляет 0,731, т. е. вероятность потерь запросов составляет 0,269. Для уменьшения потерь запросов нужно продолжить исследование каждого значимого фактора А и В.

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

Для этого удалите сгенерированный эксперимент из программы модели. Затем выберите Edit / Insert Experiment / Screening … (Правка / Вставить эксперимент / Отсеивающий …). Всё, что вы ранее вводили (см. рис. 1.3), останется неизменным. Вам нужно будет только заменить в поле Expression (Выражение) группы Result (Результат) выражение, по которому вычисляется вероятность обработки запросов, выражением для расчёта количества обработанных запросов: N$ObrZap/X$Prog.

После замены вставьте эксперимент и выполните его. Вы получите, что среднее количество обработанных запросов составит 25,889, а все факторы будут несущественными.

Решение обратной задачи

Для решения обратной задачи возьмем количество запросов, ожидаемое время обработки которых нужно определить, N = 29 - результат решения прямой задачи.

Программа модели приведена ниже.

; Обработка запросов сервером. Обратная задача
; Задание исходных данных
T1_  EQU  120    ; Средний интервал поступления запросов, с
S1_  EQU  60000000  ; Среднее значение вычислительной сложности запросов, оп
S2_  EQU  200000  ; Стандартное отклонение вычислительной сложности запросов, оп
Q_  EQU  600000  ; Средняя производительность сервера, оп/c
Emk  EQU  5    ; Ёмкость входного буфера
Koef  EQU  1    ; Коэффициент изменения характеристик нормального распределения
Koef1  EQU  1    ; Коэффициент учета дробной части
N_  EQU  29    ; Количество запросов
; Сегмент имитации обработки запросов
  GENERATE  (Exponential(1,0,T1_))  ; Источник запросов
KolZap  TEST L  Q$Server,Emk,PotZap   ; Занят ли буфер?   QUEUE  Server  ; Встать в очередь к серверу
  SEIZE    Server  ; Занять сервер
  DEPART  Server  ; Покинуть очередь к серверу
  ADVANCE  ((Normal(2,(S1_#Koef),(S2_#Koef)))/Q_) ; Имитация обработки запроса
  RELEASE  Server  ; Освободить сервер
  TRANSFER  ,ObrZap  ; Запрос отправляется в сегмент завершения моделирования
PotZap  TERMINATE    ; Потерянные запросы
; Сегмент организации завершения моделирования и расчета результатов
ObrZap  TEST L  X$Prog,TG1,Met1  ; Если X$Prog < TG1,
  SAVEVALUE  Prog,TG1  ; то X$Prog = TG1
  SAVEVALUE  NZap,0  ; Обнуление счетчика обработанных запросов
Met1  SAVEVALUE  NZap+,1  ; Счет количества обработанных запросов
  TEST E    X$NZap,N_,Ter1  ; Если X$NZap = N_, то
  TEST E    TG1,1,Met2  ; если TG1 = 1, то
  SAVEVALUE  VerObr,(N$ObrZap/N$KolZap)   ; расчет и сохранение в ячейке VerObr вероятности обработки запросов
  SAVEVALUE  TimeNZap,((AC1-X$AC2)/(X$Prog#Koef1))
;расчет и сохранение в ячейке TimeNZap времени обработки запросов
  SAVEVALUE  AC2,AC1  ; Запомнить абсолютное модельное время в ячейке АС2
Met2  SAVEVALUE  NZap,0  ; Обнуление счетчика обработанных запросов
  TERMINATE  1
Ter1  TERMINATE
  START  1000,NP  ; Прогоны до установившегося режима
  RESET      ; Сброс накопленной статистики
  START  9604    ; Количество прогонов модели

При решении обратной задачи один прогон определяется заданным количеством запросов N_, которые нужно обработать сервером, а не временем моделирования. Для этого организован счетчик обработанных запросов в виде сохраняемой ячейки X$NZap. Как только содержимое X$NZap = N_, из счетчика завершений вычитается единица. Таким образом, фиксируется один прогон модели. После этого ячейка X$NZap обнуляется и начинается очередной прогон.

Для расчета времени обработки заданного количества запросов используется арифметическое выражение (AC1-X$AC2)/X$Prog. В состав этого выражения входят абсолютное модельное время АС1 и опять количество прогонов. Запоминается количество прогонов также как и при решении прямой задачи.

Кроме этого, в арифметическом выражении есть сохраняемая ячейка X$AC2. Дело в том, что команда RESET не влияет на абсолютное модельное время АС1. Время же выполнения 1000 прогонов до установившегося режима не должно участвовать в расчёте. Поэтому оно запоминается, а затем вычитается из абсолютного модельного времени выполнения 1000 + 9604 = 10604 прогонов. Количество прогонов до установившегося режима может быть и другим.

В результате моделирования получим среднее время обработки 29 запросов 3579,401 с.

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

SAVEVALUE               RETRY       VALUE
 PROG                     0       9604.000
 NZAP                     0              0
 VEROBR                   0          0.971
 TIMENZAP                 0       3579.401

А почему не 3600 сек? Ведь это же время моделирования было задано при решении прямой задачи? Потому что мы отбросили дробную часть, т. е. взяли 29, а не 29,161. Как же поступить, чтобы учесть и отброшенную дробную часть? Ведь в счётчике фиксируются обработанные запросы только целыми числами, а не дробными?

Для учёта десятых долей дробной части зададим N_ = 291, т. е. увеличим в 10 раз. Это нужно учесть и в арифметическом выражении: ((AC1-X$AC2)/(X$Prog#Koef1)). Переменной пользователя Koef1 задается значение 10. По завершении моделирования получим 3594,826 с. Этот результат уже ближе к 3600.

Для учёта сотых долей дробной части установим N_ = 2916, а Koef1 = 100. Получим 3602,099.

Вероятность обработки запросов в обоих случаях практически одна и та же, т. е. 0,971. Однако время моделирования существенно возрастает: 2 с, 21 с и 3 мин 34 c соответственно, т. е. более чем в 10 и 100 раз.

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

Например (см. сегмент организации завершения моделирования и расчета результатов):

ADVANCE  ((Normal(2,(S1_#Koef),(S2_#Koef)))/Q_)       ;  Розыгрыш времени обработки запроса
SAVEVALUE  VerObr,(N$ObrZap/N$KolZap))     ; Расчет вероятности обработки запросов
SAVEVALUE  TimeNZap,((AC1-X$AC2)/(X$Prog#Koef1)) ; Расчет среднего времени обработки запросов

Модель в AnyLogic

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

Сервер обрабатывает запросы, поступающие с автоматизированных рабочих мест с интервалами, распределенными по показательному закону со средним значением 2 мин. Время обработки сервером одного запроса распределено по экспоненциальному закону со средним значением 3 мин. Сервер имеет входной буфер емкостью 5 запросов.

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

Как уже отмечалось, сервер представляет собой однофазную систему массового обслуживания разомкнутого типа с ограниченной входной емкостью. Версия 6 AnyLogic при создании подобных простейших моделей предоставляет возможность использования шаблонов моделей. То есть выполнение первых одних и тех же шагов можно перепоручить Мастеру создания модели. Все, что нужно пользователю, это указать, какой метод моделирования будете применять, и выбрать те опции, которые нужны в модели. После этого Мастер автоматически создаст простейшую модель. Далее можно продолжить ее разработку, изменяя свойства объектов модели и добавляя при необходимости другие объекты.

Поскольку мы только приступаем к разработке моделей в AnyLogic, то воспользуемся шаблоном. В дальнейшем, при изменении и дополнении модели согласно постановке задачи, вам станет понятно, как начинать разработку не только простейшей, но и более сложной модели "с нуля".

Создание диаграммы процесса

Выполните на панели инструментов. Появится диалоговое окно Новая модель (Рис. 1.11).

Задайте имя новой модели. В поле Имя модели введите Server.

Выберите каталог, в котором будут сохранены файлы модели. Если хотите сменить предложенный по умолчанию каталог на какой-то другой, то можете ввести путь к нему в поле Местоположение или выбрать этот каталог с помощью диалога навигации по файловой системе, открывающегося нажатием кнопки Выбрать. (рис 1.11) Диалоговое окно Новая модель

Щелкните кнопку Далее. Откроется вторая страница Мастера создания модели (Рис. 1.12).

Здесь будет предложено выбрать шаблон, на базе которого будете разрабатывать модель. Поскольку мы хотим создать новую дискретно-событийную модель не "с нуля", установите флажок Использовать шаблон модели и выберите Дискретно-событийное моделирование в расположенном ниже списке.

Щелкните кнопку Далее. На следующей странице Мастера будет предложено выбрать: хотите ли вы сразу же добавить в создаваемую модель ресурсы, график, отображающий длину очереди к сервису, анимацию обслуживающихся и ожидающих обслуживания заявок или гистограмму, отображающую распределение времени пребывания заявок в моделируемой системе. Поскольку мы хотим лишь создать с помощью Мастера простейшую диаграмму процесса, а остальные шаги выполнять совместно по шагам, чтобы вы знали, как добавлять ресурсы, создавать анимацию модели и собирать статистику и могли в дальнейшем делать это самостоятельно, то не выбирайте никаких опций модели, оставьте Анимация Нет и закончите создание модели, щелкнув мышью кнопку Готово. (рис 1.12) Вторая страница диалогового окна Новая модель

Вы создали новую модель. Далее познакомимся с пользовательским интерфейсом AnyLogic (Рис. 1.13).

В левой части рабочей области находится панель Проект. Панель Проект обеспечивает навигацию по элементам моделей, открытых в текущий момент времени. Поскольку модель организована иерархически, то она отображается в виде дерева. Сама модель образует верхний уровень дерева. Эксперименты, классы активных объектов и Java классы образуют следующий уровень. Элементы, входящие в состав активных объектов, вложены в соответствующую подветвь дерева класса активного объекта и т. д. (рис 1.13) Интерфейс AnyLogic

В правой рабочей области будет отображаться панель Палитра, а внизу в средней части интерфейса - панель Свойства. Панель Палитра содержит разделенные по категориям элементы, которые могут быть добавлены на диаграмму класса активного объекта или эксперимента. Панель Свойства используется для просмотра и изменения свойств выбранного в данный момент элемента (или элементов) модели.

В центре рабочей области AnyLogic находится графический редактор диаграммы класса активного объекта Main.

В левой нижней части расположена панель Ошибки. Она отображает ошибки в модели и помогает их локализовать.

Изменение свойств блоков модели, её настройка и запуск

Помним, что мы хотим сначала создать простейшую модель, в которой будем рассматривать только обработку запросов сервером.

В основе каждой дискретно-событийной модели лежит диаграмма процесса - последовательность соединенных между собой блоков (в AnyLogic это блоки библиотеки Enterprise Library), задающих последовательность операций, которые будут производиться над проходящими по диаграмме процесса заявками.

Обратите внимание на диаграмму класса Main. Вы увидите, что диаграмма нашего простейшего процесса (Рис. 1.14) была автоматически создана Мастером создания модели, поскольку такая модель является ничем иным, как простейшей системой массового обслуживания, наиболее часто используемой в качестве отправной точки создания дискретно-событийных моделей. Поэтому она и выбрана в качестве базового шаблона при разработке дискретно-событийных моделей.

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

Всё, что нам нужно, чтобы сделать созданный шаблон модели адекватным постановке задачи - это изменить некоторые свойства объектов.

Изменение свойств блоков диаграммы процесса

Свойства объекта (как и любого другого элемента AnyLogic) можно изменить в панели Свойства.

Обратите внимание, что панель Свойства является контекстно-зависимой. Она отображает свойства выделенного в текущий момент элемента. Поэтому для изменения свойств элемента нужно будет предварительно щелчком мыши выделить его в графическом редакторе или в панели Проекты.

Чтобы всегда была уверенность в том, что в текущий момент в рабочем пространстве выбран именно нужный элемент, и именно его свойства вы редактируете в панели Свойства, обращайте внимание на первую строку, показываемую в панели Свойства - в ней отображается имя выбранного в текущий момент времени элемента и его тип.

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

Первым объектом в диаграмме процесса является объект класса Source. Объект source генерирует заявки определенного типа. Заявки представляют собой объекты, которые производятся, обрабатываются, обслуживаются, или еще каким-нибудь образом подвергаются действию моделируемого процесса: это могут быть клиенты в системе обслуживания, детали в модели производства, транспортные средства в модели перевозок, документы в модели документооборота, сообщения в моделях систем связи и т.д. В нашем примере заявками будут запросы на обработку данных, а объект source будет моделировать поступление запросов на сервер.

В нашем случае объект (элемент) создает заявки через временной интервал, распределенный по показательному (экспоненциальному) закону со средним значением 2 мин.

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

Выделите объект source. В выпадающем списке Заявки прибывают согласно укажите, что запросы поступают согласно Времени между прибытиями (Рис. 1.15). В поле Время между прибытиями появится запись exponential(1). Установите согласно постановке задачи среднее значение интервалов времени поступления запросов на сервер, изменив свойства объекта source. Для этого вместо характеристики распределения 1 введите 1/120.0.

В языке программирования Java символ / означает целочисленное деление, т.е. если оба числа целые, то и результат будет целым. В нашем случае отношение 1/120 было бы равно нулю. Для получения вещественного результата, необходимо, чтобы хотя бы одно из чисел было вещественным (double). Поэтому в качестве характеристики экспоненциального распределения (интенсивности поступления запросов) необходимо указать 1/120.0 или 1.0/120.

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

Измените свойства объекта queue (Рис. 1.16).

Следующим в нашей диаграмме процесса расположен объект delay. Он задерживает заявки на заданный период времени, представляя в нашей модели непосредственно сервер, на котором обрабатываются запросы.

Измените свойства объекта delay (Рис. 1.17).

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

Настройка запуска модели

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

В панели Проект эксперименты отображаются в нижней части дерева модели. Один эксперимент, названный Simulation, создается по умолчанию. Это простой эксперимент, позволяющий запускать модель с заданными значениями параметров, поддерживающий режимы виртуального и реального времени, анимацию и отладку модели.

Если вы хотите наблюдать поведение модели в течение длительного периода (до того момента, пока вы сами не остановите выполнение модели), то по умолчанию времени остановки нет. Обработку запросов сервером мы планируем исследовать в течение одного часа, т.е. 3600 с. Тем не менее, оставьте время остановки модели не заданным.

В панели Проект выделите эксперимент Simulation:Main.

На странице Основные панели Свойства выберите опцию Фиксированное начальное число (воспроизводимые прогоны).

В поле Начальное число: установите 9 (такое же, как и в GPSS-программе).

На странице Модельное время панели Свойства оставьте всё по умолчанию. (рис 1.18) Страница Основные панели Свойства (рис 1.19) Установка единиц модельного времени

В панели Проект, выделите Server (Рис. 1.19).

На странице Основные панели Свойства из выпадающего списка Единицы модельного времени: выберите секунды.

Запуск модели

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

После исправления ошибок и построения модели, запустите её:

Щелкните мышью кнопку панели инструментов Запустить (или нажмите F5) и выберите из открывшегося списка эксперимент, который вы хотите запустить. Эксперимент этой модели будет называться Server/Simulation (Рис. 1.20).

В дальнейшем нажатием кнопки Запустить (или кнопки F5) будет запускаться тот эксперимент, который запускался вами в последний раз. Чтобы выбрать другой эксперимент, вам будет нужно щелкнуть мышью по стрелке, находящейся в правой части кнопки Запустить, и выбрать нужный вам эксперимент из открывшегося списка (или щелкнуть правой кнопкой мыши по этому эксперименту в панели Проект и выбрать Запустить из контекстного меню). (рис 1.20) Выбор эксперимента

После запуска модели вы увидите окно презентации этой модели (Рис. 1.21). В нем будет отображена презентация запущенного эксперимента. AnyLogic автоматически помещает на презентацию каждого простого эксперимента заголовок и кнопку, позволяющую запустить модель и перейти на презентацию, нарисованную вами для главного класса активного объекта этого эксперимента (Main).

Щелкните данную кнопку. Этим щелчком вы запустите модель и перейдете к презентации корневого класса активного объекта запущенного эксперимента. Для каждой модели, созданной в Enterprise Library, автоматически создается блок-схема с наглядной визуализацией процесса, с помощью которой вы можете изучать текущее состояние модели, например, длину очереди, количество обработанных запросов и так далее (Рис. 1.22). (рис 1.21) Окно презентации модели (рис 1.22) Моделирование остановилось с ошибкой

Для каждого объекта определены правила, при каких условиях принимать заявки. Некоторые объекты задерживают заявки внутри себя, некоторые - нет. Для объектов также определены правила: может ли заявка, которая должна покинуть объект, ожидать на выходе, если следующий объект не готов её принять. Если заявка должна покинуть объект, а следующий объект не готов её принять, и заявка не может ждать, то модель останавливается с ошибкой (Рис. 1.22). Ошибка означает, что запрос не может войти в блок queue, так как его ёмкость, равная 5, заполнена.

Нажмите OK. Далее измените свойства объекта queue, т. е. увеличьте длину очереди (см. Рис. 1.16). Для этого введите в поле Вместимость 15. Можете убедиться, что при увеличении ёмкости в пределах 6 … 14 модель по-прежнему останавливается с этой же ошибкой. Момент появления ошибки зависит от длительности времени моделирования. Снова запустите модель.

Вы можете изменить скорость выполнения модели с помощью кнопок Замедлить и Ускорить панели инструментов.

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

В окне инспекта будет отображена базовая информация по выделенному объекту: например, для объекта queue будут отображены вместимость очереди, количество заявок, прошедшее через каждый порт объекта, средняя длина очереди и т. д. Такая же информация содержится в инспекте и для объекта delay (Рис. 1.23).

Когда вы захотите остановить выполнение модели, щелкните мышью кнопку панели управления окна презентации.

Для предотвращения остановок модели по ранее указанной ошибке - недостаточной ёмкости объекта queue - мы увеличили ёмкость объекта queue. Однако можно было бы изменять среднее время имитации поступления запросов объектом source и среднее время обработки запросов сервером, т. е. среднее время задержки объекта delay, оставляя неизменной длину очереди и добиваясь безошибочной работы модели. Конечно, при изменении свойств объектов модели нужно обязательно исходить из целей её построения. Мы же не выполнили условий, указанных в постановке задачи, поэтому к выполнению их вернемся позже.

Создание анимации модели

Можно было наблюдать, анализировать и интерпретировать работу запущенной модели с помощью визуализированной диаграммы процесса (см. Рис. 1.22, Рис. 1.23). Однако удобнее иметь более наглядную визуализацию с помощью анимации. В этом примере мы хотим создать визуализированный процесс поступления запросов на сервер и обработки запросов сервером.

Так как в данном случае нас не интересует конкретное расположение объектов в пространстве, то мы можем просто добавить схематическую анимацию интересующих нас объектов - сервер и очередь запросов к нему.

Анимация модели рисуется в той же диаграмме (в графическом редакторе), в которой задается и диаграмма моделируемого процесса.

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

Вначале откройте закладку Презентация панели Палитра (Рис. 1.24). Чтобы открыть какую-либо закладку панели Палитра (в дальнейшем палитра), нужно щелкнуть мышью по заголовку этой палитры. Замечание. Можно открыть сразу все палитры, щелкнув мышью кнопку Развернуть все палитры.

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

Выделите щелчком мыши элемент Прямоугольник на палитре Презентация и перетащите его на диаграмму класса активного объекта. Поместите элемент Прямоугольник так, как показано на Рис. 1.26.

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

Для этого выделите нарисованную нами фигуру на диаграмме и перейдите на страницу Динамические панели свойств (Рис. 1.27). Здесь вы увидите список полей, в которых задаются значения динамических свойств фигуры. (рис 1.24) Панель Палитра (рис 1.25) Палитра Презентация (рис 1.26) Элемент Прямоугольник на диаграмме

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

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

delay.size()>0?red:white

(рис 1.27) Страница Динамические панели свойств

Здесь delay - это имя нашего объекта delay. Функция size() возвращает число запросов, обслуживаемых в данный момент времени. Если сервер занят, то цвет кружка будет красным, в противном случае - зеленым.

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

Очень важно, какую точку ломаной вы создаете первой. Заявки будут располагаться вдоль нарисованной вами ломаной в направлении от конечной точки к начальной точке. Поэтому начните рисование ломаной слева и поместите рядом с сервером конечную точку ломаной, которая будет соответствовать в этом случае началу очереди.

Теперь мы должны задать созданные анимационные объекты в качестве анимационных фигур блоков диаграммы нашего процесса. Задайте ломаную линию в качестве фигуры анимации очереди. На странице свойств объекта queue, введите polyline в поле Фигура анимации (Рис. 1.29). (рис 1.28) Ломаная

Задайте прямоугольник в качестве фигуры анимации сервера. Введите в поле Фигура анимации имя нашего прямоугольника: rectangle (Рис. 1.30). Выберите из выпадающего списка Тип анимации Одиночная. Большинство объектов Enterprise Library поддерживает несколько анимационных стилей. Например, очередь может отображаться в виде линии, упорядоченного или неупорядоченного набора элементов. В нашем случае, если сервер будет занят, то мы будем показывать в фигуре сервера обрабатываемого в нем запроса, а поскольку единовременно наш сервер не обрабатывает больше одного запроса, то мы и выбираем тип анимации Одиночная.

Теперь вы можете запустить модель. Для ускорения работы модели переключитесь в режим виртуального времени, щелкнув мышью кнопку Реальное/виртуальное время панели инструментов. В режиме виртуального времени модель будет выполняться быстро, без привязки модельного времени к реальному времени.

(рис 1.29) Задание ломаной в качестве фигуры анимации очереди (рис 1.30) Задание прямоугольника в качестве фигуры анимации сервера

Запустите модель. Вы увидите, что у модели теперь есть простейшая анимация - сервер и очередь запросов к нему (Рис. 1.31). Цвет фигуры сервера будет меняться в зависимости от того, обрабатывается ли запрос в данный момент времени или нет. (рис 1.31) Анимация модели

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

AnyLogic предоставляет пользователю удобные средства для сбора статистики по работе блоков диаграммы процесса. Объекты Enterprise Library самостоятельно производят сбор основной статистики. Все, что вам нужно сделать - это включить сбор статистики для объекта.

Поскольку мы уже сделали это для объектов delay и queue, то теперь мы можем, например, просмотреть интересующую нас статистику (скажем, статистику занятости сервера и длины очереди) с помощью диаграмм.

Добавьте диаграмму для отображения среднего коэффициента использования сервера:

Откройте палитру Статистика. Эта палитра содержит элементы сбора данных и статистики, а также диаграммы для визуализации данных и результатов моделирования.

Перетащите элемент Столбиковая диаграмма из палитры Статистика на диаграмму класса и измените ее размер, как показано на Рис. 1.32.

Перейдите на страницу Основные панели Свойства. Щелкните мышью кнопку Добавить элемент данных. После щелчка появится секция свойств того элемента данных (chart - Столбиковая диаграмма), который будет отображаться на этой диаграмме (Рис. 1.33). (рис 1.32) Элемент Столбиковая диаграмма на диаграмме класса (рис 1.33) Страница Основные панели Свойства

Измените Заголовок на SERVER utilization.

Введите delay.statsUtilization.mean() в поле Значение. Здесь delay - это имя нашего объекта delay. У каждого объекта delay есть встроенный набор данных statsUtilization, занимающийся сбором статистики использования этого объекта. Функция mean() возвращает среднее из всех измеренных этим набором данных значений. Вы можете использовать и другие методы сбора статистики, такие, как min() или max(). Полный список методов можно найти на странице документации этого класса набора данных: StatisticsContinuous (на английском языке).

Перейдите на страницу Внешний вид (Рис. 1.34). (рис 1.34) Страница Внешний вид панели Свойства (рис 1.35) Изменённый вид столбиковой диаграммы

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

Аналогичным образом добавьте еще одну столбиковую диаграмму для отображения средней длины очереди. Заголовок и Значение измените так, как показано на Рис. 1.36. (рис 1.36) Страница Основные панели Свойства (рис 1.37) Страница Внешний вид панели Свойства

Здесь queue - это имя нашего объекта queue. У каждого объекта queue, как и объекта delay, также есть встроенный набор данных statsSize, занимающийся сбором статистики использования этого объекта. Функция mean() также возвращает среднее из всех измеренных этим набором данных значений.

Перейдите на страницу Внешний вид панели Свойства и выберите в секции свойств Направление первую опцию (Рис. 1.37), чтобы столбцы во второй столбиковой диаграмме, расположенной горизонтально, росли влево (Рис. 1.38). (рис 1.38) Добавлена вторая столбиковая диаграмма (рис 1.39) Наблюдение за моделью с двумя столбиковыми диаграммами

Запустите модель с двумя столбиковыми диаграммами и понаблюдайте за ее работой (Рис. 1.39).

Уточнение модели согласно ёмкости входного буфера

На Рис. 1.39 (снимок сделан, в случайный момент времени, равный 2409,65 единицам) видно, что длина очереди равна 8 запросам при установленной максимальной длине 12. Но ведь в постановке задачи ёмкость буфера была определена в 5 запросов. Нам не удалось до этого построить модель с такой ёмкостью из-за ошибки (см. рис. 1.22) - невозможности очередного запроса покинуть блок source, так как длина очереди уже была равна 5 запросам. Нам пришлось во избежание этой ошибки увеличить ёмкость буфера до 15 запросов.

А возможно ли выполнить данное условие постановки задачи средствами AnyLogic? Оказывается, что можно. Причем, различными способами. Уточним модель согласно постановке задачи одним из этих способов.

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

Заявка может покинуть объект queue различными способами:

В первом случае объект queue покидает заявка, находящаяся в самом начале очереди (в нулевой позиции). Если заявка направлена в порт outTimeout или outPreempted, то она должна покинуть объект мгновенно. Если включена опция вытеснения, то объект queue всегда готов принять новую заявку, в противном случае при заполненной очереди заявка принята не будет.

Поступающие заявки помещаются в очередь в определенном порядке: либо согласно правилу FIFO (в порядке поступления в очередь), либо согласно приоритетам заявок. Приоритет может быть либо явно храниться в заявке, либо вычисляться согласно свойствам заявки и каким-то внешним условиям. Очередь с приоритетами всегда примет новую входящую заявку, вычислит её приоритет, и поместит в очередь в позицию, соответствующую её приоритету. Если очередь будет заполнена, то приход новой заявки вынудит последнюю хранящуюся в очереди заявку покинуть объект через порт outPreempted. Но если приоритет новой заявки не будет превышать приоритет последней заявки, то тогда вместо неё будет вытеснена именно эта новая заявка.

Для выполнения условия постановки задачи воспользуемся последним способом вытеснения. Все запросы, вырабатываемые объектом source, имеют один и тот же приоритет. Поэтому при полном заполнении накопителя (5 запросов) теряться будет последний запрос. Уточните модель.

Выделите объект queue. На странице Основные панели Свойства измените Вместимость с 15 на 5 запросов.

На этой же странице установите Разрешить вытеснение.

Для уничтожения потерянных запросов вследствие полного заполнения накопителя необходимо добавить второй объект sink. Откройте в Палитре библиотеку Enterprise Library и перетащите блок sink на диаграмму (Рис. 1.40). (рис 1.40) Уточненная модель

Соедините порт outPreempted объекта queue с входным портом InPort блока sink1. Чтобы соединить порты, сделайте двойной щелчок мышью по одному порту, например, outPreempted, затем последовательно щелкните в тех местах диаграммы, где вы хотите поместить точки изгиба соединителя. Завершите процесс соединения двойным щелчком мыши по второму порту.

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

Запустите уточненную модель и понаблюдайте за ее работой. Сравните Рис. 1.41 с Рис. 1.22. На Рис. 1.41 видно, что запросы при длине очереди в 5 запросов теряются, и ошибки при этом не возникает. Модель по ограничению ёмкости входного буфера и значениям других параметров соответствует постановке задачи.

Однако согласно постановке задачи требуется определить математическое ожидание времени обработки одного запроса и математическое ожидание вероятности обработки запросов.

Приступим к реализации этих требований. Но предварительно сохраним модель с именами Сервер Прямая задача и Сервер Обратная задача. К последней мы вернёмся в главе 10.

Сбор статистики по показателям обработки запросов

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

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

Математическое ожидание или среднее время обработки одного запроса определяется как отношение суммарного времени обработки n запросов к их количеству, т. е. к n. Для определения суммарного времени нужно знать время обработки i-го запроса. Для этого введем дополнительные поля: time_vxod - время входа запроса в буфер сервера, time_vixod - время выхода запроса с сервера (входа в блок sink). Тогда

time_obrabotki=time_vixod-time_vxod

Вероятность обработки запросов сервером определяется как отношение количества обработанных запросов к количеству всех поступивших запросов. Значит, нужно вести счет запросов на выходе источника запросов и на выходе с сервера (входе в блок sink). Для этого также введем дополнительные поля: col_vxod - количество поступивших всего запросов, col_vixod - количество обработанных сервером запросов. Тогда

ver_obrabotki=col_vixod/col_vxod

Создание нестандартного класса заявок

Для ввода в запросы дополнительных полей необходимо создать нестандартный класс заявки.

Создайте класс заявок Inquiry.

В панели Проект щелкните правой кнопкой мыши элемент модели верхнего уровня дерева и выберите Создать/Java класс из контекстного меню.

Появится диалоговое окно Новый Java класс (Рис. 1.42). В поле Имя: введите имя нового класса: Inquiry.

В поле Базовый класс: выберите из выпадающего списка Entity в качестве базового класса. Щелкните кнопку Далее. (рис 1.42) Диалоговое окно Мастера создания Новый Java класс (рис 1.43) Вторая страница Мастера создания Новый Java класс

Появится вторая страница Мастера создания Java класса (Рис. 1.43). Добавьте поля Java класса: time_vxod типа double, time_vixod типа double, col_vxod типа float, col_vixod типа float. Типы полей выбираются из выпадающего списка. Начальные значения всех параметров, поскольку не указаны, по умолчанию будут установлены равными нулю.

Оставьте выбранными флажки Создать конструктор и Создать метод toString (). Тогда у класса будут созданы сразу два конструктора: один, по умолчанию, без параметров, и второй, с параметрами, инициализирующими поля класса. Эти конструкторы используются объектами, создающими новые заявки, такие, как Source.

Щелкните кнопку Готово. Вы увидите редактор кода, в котором будет показан автоматически созданный код вашего Java класса (Рис. 1.44). Изучите этот код и выясните, как можно самостоятельно добавлять в класс заявки новые поля и методы. Закройте редактор, щелкнув крестик в закладке рядом с его названием. (рис 1.44) Окно редактора кода созданного нестандартного класса

Добавление элементов статистики

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

Добавьте еще элемент сбора статистики для определения вероятности обработанных запросов.

Изменение свойств объектов диаграммы

Чтобы создавать заявки нестандартного типа, как в нашем случае Inquiry, вам нужно поместить вызов конструктора этого типа в поле Новая заявка объекта source. Но, несмотря на то, что заявки в потоке теперь и будут типа Inquiry, остальные объекты диаграммы будут продолжать их считать заявками типа Entity.

Поэтому они не позволят явно обращаться к дополнительным полям класса Inquiry. Чтобы разрешить доступ к полям вашего нестандартного класса заявки в коде динамических параметров объектов потоковой диаграммы, вам нужно указать имя нестандартного класса заявки в качестве Класса заявки этого объекта. В нашей потоковой диаграмме с учетом блока source всего пять объектов. Измените их свойства.

введите Inquiry в поле Класс заявки:. (рис 1.48) Объект source с измененными свойствами

time_obrabotki.add(time()-entity.time_vxod);

Этот код добавляет время обработки одного запроса в объект сбора данных гистограммы time_obrabotki. Данное время определяется как разность между текущим модельным временем time() и временем входа запроса в модель. add - встроенная функция добавления элемента в массив.

entity.col_vixod=sink.count();

entity.col_vxod=source.count();

Эти коды заносят количество запросов, вошедших в блок sink и вышедших из блока source соответственно. count() - встроенная функция этих блоков, возвращает количество вошедших в блок sink и количество вышедших из блока source заявок.

ver_obrabotki.add(entity.col_vixod/entity.col_vxod);

Этот код добавляет относительную долю обработанных запросов в объект сбора данных гистограммы ver_obrabotki при поступлении каждого обработанного запроса в блок sink. На основе множества таких относительных долей определяется математическое ожидание вероятности обработки запросов сервером.

Удаление и добавление новых полей класса заявок

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

Удалите поле time_vixod.

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

Итак, все условия постановки задачи выполнены. Запустите модель. Выберите виртуальное время. Наблюдайте за работой модели (Рис. 1.51).

Добавление параметров и элементов управления

Активный объект может иметь параметры. Параметры обычно используются для задания статических характеристик объекта. Но значения параметров при необходимости можно изменять во время работы модели. Для этого нужно написать код обработчика события, то есть действий, которые должны выполняться при изменении значения параметра.

Создайте параметр time_mean объекта delay.

В Палитре выделите Основная.

Перетащите элемент Параметр на диаграмму класса Main и разместите сверху объекта delay, чтобы было видно, к какому объекту относится параметр.

Перейдите на страницу Основные панели Свойства (Рис. 1.52). (рис 1.52) Окно установки свойств элемента Параметр

В поле Имя введите имя параметра time_mean (среднее время). По этому имени параметр будет доступен из кода.

Задайте тип параметра double.

В поле Значение по умолчанию установите 180. Если значение не будет задано явно, то по правилам Java оно будет равно нулю.

Выделите объект delay.

На странице Основные панели Свойства в поле Время задержки вместо выражения exponential(1/180.0) введите exponential(1/time_mean).

Пусть вы хотите изменять среднее время обработки запросов time_mean в ходе моделирования. Используйте для этого элемент управления - бегунок.

Откройте палитру Элементы управления и перетащите элемент Бегунок из палитры на диаграмму класса Main (Рис. 1.54).

Поместите бегунок под параметром time_mean, чтобы было понятно, что с помощью этого бегунка будет меняться среднее время обработки запросов объектом delay.

Пусть вы хотите варьировать среднее время от 1 до 300. Поэтому введите 1 в поле Минимальное значение, а 300 - в поле Максимальное значение (Рис. 1.53).

Установите флажок Связать с: и в активизированное поле введите time_mean. (рис 1.53) Окно установки свойств элемента управления Бегунок

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

Откройте палитру Элементы управления и перетащите элемент Бегунок из палитры на диаграмму класса Main (Рис. 1.54). (рис 1.54) На диаграмму добавлены Параметр и элементы управления

Поместите бегунок над объектом queue, чтобы было понятно, что с помощью этого бегунка будет меняться вместимость данного объекта, имитирующего входной буфер.

Пусть вы хотите варьировать ёмкость буфера от 0 до 15 запросов. Поэтому введите 15 в поле Максимальное значение.

Установите флажок Связать с: и в активизированное поле введите queue.capacity.

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

Остановите модель и перейдите на диаграмму класса Main.

Мы научились добавлять элементы Параметр и Бегунок. Но согласитесь, что какие параметры модели нужно будет менять, и в каких интервалах, заранее определить затруднительно. Также при использовании элемента Бегунок существуют трудности точного установления значения характеристики, так как невозможно предусмотреть нужный масштаб или цену деления Бегунка.

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

Изменение значения в окне инспекта поддерживается для следующих элементов:

простая переменная;

параметр;

накопитель.

И для следующих типов:

Введите новое значение: 240.0. (рис 1.55) Ввод нового значения параметра в окно инспекта

Добавление гистограмм

Теперь добавим на диаграмму нашего потока гистограмму, которая будет отображать собранную временную статистику.

Изменение времени обработки запросов сервером

Построенная модель соответствует постановке задачи (п. 1.2.1). В ней, с целью упрощения процесса построения первой модели, время обработки запросов сервером было принято распределённым по показательному (экспоненциальному) закону со средним значением T2 = 3 мин.

Однако в модели, реализованной средствами GPSS World (п. 1.1), время обработки поступающих запросов зависит от производительности сервера $$Q = 6\cdot10^5\text{ оп/с}$$ и вычислительной сложности запросов, распределенной по нормальному закону с математическим ожиданием $$S1=6\cdot10^7\text{ оп}$$ и среднеквадратическим отклонением $$S2=2\cdot10^5\text{ оп}$$

VrObr  VARIABLE  (Normal(2,(S1_#Koef),(S2_#Koef)))/Q

Кроме того, в этой модели определяется среднее количество запросов, обработанных за время моделирования 3600 с.

Внесите в модель изменения для аналогичного расчёта времени обработки запросов.

KolZap=sink.in.count()/9604.0;

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

Интерпретация результатов решения прямой задачи

Для проведения исследований на модели сделайте ещё несколько дополнений и изменений.

KolZap=round(sink.in.count()/kolProg);

Проведём несколько экспериментов в AnyLogic и GPSS World.

Будем изменять среднее время поступления запросов timeMean в предположении, что с течением времени количество источников запросов будет расти, то есть timeMean будет уменьшаться. В сторону увеличения будем изменять ёмкость входного буфера emkBuf и производительность Q_ сервера.

Результаты экспериментов - решения прямой задачи в GPSS World и AnyLogic приведены в Табл. 1.2. Из сравнительного анализа полученных результатов следует, что они или равны, или отличаются незначительно.

Разница между количеством обработанных сервером запросов составляет $$\triangle_1=|29,161-29,142|=0,019$$ в первом эксперименте, во втором и пятом $$\triangle_2=1$$ (после округления до целого), а среднее время обработки одного запроса - $$\triangle_3=0,190 … 0,556$$. Вероятности обработки запросов отличаются на $$\triangle_4=0,001$$ в трёх экспериментах, а в трёх равны. Коэффициенты использования (загрузки) серверов или равны или отличаются на $$\triangle_5=0,001 … 0,002$$.

Машинное время выполнения модели в GPSS World составляет около 30 с, а в AnyLogic примерно 120 с.