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

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

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

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

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

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

• обычным способом через порт out, когда объект, следующий в блок-схеме за этим объектом, готов принять заявку;
• через порт outTimeout, если заявка проведет в очереди заданное количество времени (если включен режим таймаута);
• через порт outPreempted, будучи вытесненной другой поступившей заявкой при заполненной очереди (если включен режим вытеснения);
• "вручную", путем вызова функции remove() или removeFirst().

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

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

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

1. Выделите объект queue. На странице Основные панели Свойства измените Вместимость с 15 на 5 запросов.
2. На этой же странице установите Разрешить вытеснение.
3. Для уничтожения потерянных запросов вследствие полного заполнения накопителя необходимо добавить второй объект sink. Откройте в Палитре библиотеку Enterprise Library и перетащите блок sink на диаграмму (Рис. 1.40).
   

   
   Рис. 1.40. Уточненная модель
4. Соедините порт outPreempted объекта queue с входным портом InPort блока sink1. Чтобы соединить порты, сделайте двойной щелчок мышью по одному порту, например, outPreempted, затем последовательно щелкните в тех местах диаграммы, где вы хотите поместить точки изгиба соединителя. Завершите процесс соединения двойным щелчком мыши по второму порту.
5. После двойного щелчка по второму порту вы увидите, что появится соединитель. Если выделить его мышью, то при правильном соединении портов конечные точки соединителя должны подсветиться зелеными точками. Если нет, то точки не были помещены точно внутрь портов, и их нужно будет туда передвинуть.
6. Запустите уточненную модель и понаблюдайте за ее работой. Сравните Рис. 1.41 с Рис. 1.22. На Рис. 1.41 видно, что запросы при длине очереди в 5 запросов теряются, и ошибки при этом не возникает. Модель по ограничению ёмкости входного буфера и значениям других параметров соответствует постановке задачи.

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

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

Рис. 1.41. Работа модели согласно ёмкости входного буфера

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

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.

1. В панели Проект щелкните правой кнопкой мыши элемент модели верхнего уровня дерева и выберите Создать/Java класс из контекстного меню.
2. Появится диалоговое окно Новый Java класс (Рис. 1.42). В поле Имя: введите имя нового класса: Inquiry.
3. В поле Базовый класс: выберите из выпадающего списка Entity в качестве базового класса. Щелкните кнопку Далее.
   

   
   Рис. 1.42. Диалоговое окно Мастера создания Новый Java класс
   

   
   Рис. 1.43. Вторая страница Мастера создания Новый Java класс
4. Появится вторая страница Мастера создания Java класса (Рис. 1.43). Добавьте поля Java класса: time_vxod типа double, time_vixod типа double, col_vxod типа float, col_vixod типа float. Типы полей выбираются из выпадающего списка. Начальные значения всех параметров, поскольку не указаны, по умолчанию будут установлены равными нулю.
5. Оставьте выбранными флажки Создать конструктор и Создать метод toString (). Тогда у класса будут созданы сразу два конструктора: один, по умолчанию, без параметров, и второй, с параметрами, инициализирующими поля класса. Эти конструкторы используются объектами, создающими новые заявки, такие, как Source.
6. Щелкните кнопку Готово. Вы увидите редактор кода, в котором будет показан автоматически созданный код вашего Java класса (Рис. 1.44). Изучите этот код и выясните, как можно самостоятельно добавлять в класс заявки новые поля и методы. Закройте редактор, щелкнув крестик в закладке рядом с его названием.
   

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