-
Практический раздел
-
Постановка задачи
-
В системах массового обслуживания каждая заявка(транзакт) проходит несколько этапов:
-
появление заявки на входе в систему;
-
ожидание в очереди;
-
процесс обслуживания, после которого заявка покидает систему.
Первый и третий этап характеризуются случайными величинами.
Задача формулируется с учетом темы ВКРБ «Разработка автоматизированной информационной системы сбора и мониторинга данных с электронно-вычислительных устройств и датчиков».
Смоделируем выделенный технологический процесс (преобразование электронного xml запроса отправленного с клиентского узла связи, в транзакцию в виде SQL запроса в базу данных на сервер) преобразование исходных данных поступающих в систему с клиентского устройства на удаленный сервер, по средствам соединения TCP/IP. Каждый пользователь регистрируется на сервере, и получает в распоряжение пользовательскую БД, с системными таблицами и таблицами которые он сам настраивает пользователем. Следующим этапом является регистрация и соединение с пользовательским устройством который является своего рода буфером. На устройство отправляются данные с сенсоров и датчиков, где формируется XML файл со значениями показаний датчиков. Далее XML файл автоматически отправляется на сервер, где преодолевает два этапа конвертацию в SQL, то есть непосредственный разбор древа XML файла и преобразование в SQL команды. Далее эти команды выполняются сервером.
В рамках задачи определим модельные единицы измерения:
-
память в многоканальных устройствах измеряется в мегабайтах;
-
время измеряется в миллисекундах.
Исходные данные:
N – интенсивность поступающих запросов;
T1 – время обслуживание(отправка данных на сервер);
T2 – время обслуживания (конвертация);
T3 – время обслуживания (сервера БД);
Tis – время моделирования ().
Смоделировать предстоит таким образом, что бы выявить узкие места в выделенном технологическом процессе, изменяя интенсивность запросов. Так как в реальном процессе, с каждым новым пользователем будет увеличиваться запросы от пользователя + запросы поступающие в виде XML файла, который может включать в себя множество запросов.
-
Разработка и тестирование проекта
В листинге 1 представлен исходный код нашей модели, интенсивность поступления запросов 5000 миллисекунд.
Листинг 1 исходный код модели
SIMULATE
cmdquery EQU 5000 ; интенсивность запросов
byfferquery STORAGE 64 ; память выделенная под буферизацию на клиентском ПК
konvertor STORAGE 1024 ; память выделенная для конвертации
GENERATE (Exponential(1,0,cmdquery)) ; генерация транзактов с интенсивностью распределенной экспоненциально
QUEUE bufqu ; очередь на отправку
ENTER byfferquery,4 ; занимаем многоканальное устройство буфер 4 мегабайтами
DEPART bufqu ; уменьшаем очередь
ADVANCE (Normal(30,100,1)) ; отправляем даныые с клиенского узла на сервер зависит от скорости передачи данных, нижняя граница взята примерно 30 миллисекунд распределенная нормально
LEAVE byfferquery,4 ; освобождаем буфер на 4 мегабайта
QUEUE bufkon ; очередь на конвертацию
ENTER konvertor,4 ; занимаем ковертер 4 мегабайтами
DEPART bufkon ; уменьшаем очередь
ADVANCE 30,20 ; обслуживание конвертером, взято примерно 30 миллесекунд +-20
LEAVE konvertor,4 ; освобождаем конвертер на 4 мегабайта
QUEUE db ; очередь на транзакцию в БД
SEIZE database ; занимаем одноканальное устройство БД
DEPART db ; уменьшаем очередь
ADVANCE 50,30 ; обслуживаем транзакция в БД поступающего запроса
RELEASE database ; освобождаем одноканальное устройство БД
TERMINATE
GENERATE 3600000 ;сегмент времени один час
TERMINATE 1
Просмотрим получившийся отчет:
GPSS World Simulation Report - курсач модель.82.1
Monday, December 08, 2014 06:20:54
START TIME END TIME BLOCKS FACILITIES STORAGES
0.000 3600000.000 19 1 2
NAME VALUE
BUFKON 10004.000
BUFQU 10003.000
BYFFERQUERY 10001.000
CMDQUERY 5000.000
DATABASE 10006.000
DB 10005.000
KONVERTOR 10002.000
LABEL LOC BLOCK TYPE ENTRY COUNT CURRENT COUNT RETRY
1 GENERATE 685 0 0
2 QUEUE 685 0 0
3 ENTER 685 0 0
4 DEPART 685 0 0
5 ADVANCE 685 0 0
6 LEAVE 685 0 0
7 QUEUE 685 0 0
8 ENTER 685 0 0
9 DEPART 685 0 0
10 ADVANCE 685 0 0
11 LEAVE 685 0 0
12 QUEUE 685 0 0
13 SEIZE 685 0 0
14 DEPART 685 0 0
15 ADVANCE 685 0 0
16 RELEASE 685 0 0
17 TERMINATE 685 0 0
18 GENERATE 1 0 0
19 TERMINATE 1 0 0
FACILITY ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY
DATABASE 685 0.010 50.145 1 0 0 0 0 0
QUEUE MAX CONT. ENTRY ENTRY(0) AVE.CONT. AVE.TIME AVE.(-0) RETRY
BUFQU 1 0 685 685 0.000 0.000 0.000 0
BUFKON 1 0 685 685 0.000 0.000 0.000 0
DB 1 0 685 680 0.000 0.258 35.347 0
STORAGE CAP. REM. MIN. MAX. ENTRIES AVL. AVE.C. UTIL. RETRY DELAY
BYFFERQUERY 64 64 0 8 2740 1 0.076 0.001 0 0
KONVERTOR 1024 1024 0 8 2740 1 0.023 0.000 0 0
FEC XN PRI BDT ASSEM CURRENT NEXT PARAMETER VALUE
687 0 3604567.823 687 0 1
688 0 7200000.000 688 0 18
Из нашего отчета видно, что все сгенерированные запросы, успешно прошли все блоки технологического процесса. Так же можно увидеть нагрузку на блоке и средние время затраченное на обработку информации.
Теперь предположим, что интенсивность поступления запросов равна 100 миллисекундам. Тогда получим такой отчет.
GPSS World Simulation Report - курсач модель.89.1
Monday, December 08, 2014 06:33:08
START TIME END TIME BLOCKS FACILITIES STORAGES
0.000 3600000.000 19 1 2
NAME VALUE
BUFKON 10004.000
BUFQU 10003.000
BYFFERQUERY 10001.000
CMDQUERY 100.000
DATABASE 10006.000
DB 10005.000
KONVERTOR 10002.000
LABEL LOC BLOCK TYPE ENTRY COUNT CURRENT COUNT RETRY
1 GENERATE 35709 0 0
2 QUEUE 35709 0 0
3 ENTER 35709 0 0
4 DEPART 35709 0 0
5 ADVANCE 35709 0 0
6 LEAVE 35709 0 0
7 QUEUE 35709 0 0
8 ENTER 35709 0 0
9 DEPART 35709 0 0
10 ADVANCE 35709 0 0
11 LEAVE 35709 0 0
12 QUEUE 35709 2 0
13 SEIZE 35707 0 0
14 DEPART 35707 0 0
15 ADVANCE 35707 1 0
16 RELEASE 35706 0 0
17 TERMINATE 35706 0 0
18 GENERATE 1 0 0
19 TERMINATE 1 0 0
FACILITY ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY
DATABASE 35707 0.497 50.114 1 35707 0 0 0 2
QUEUE MAX CONT. ENTRY ENTRY(0) AVE.CONT. AVE.TIME AVE.(-0) RETRY
BUFQU 1 0 35709 35709 0.000 0.000 0.000 0
BUFKON 1 0 35709 35709 0.000 0.000 0.000 0
DB 7 2 35709 17945 0.270 27.255 54.788 0
STORAGE CAP. REM. MIN. MAX. ENTRIES AVL. AVE.C. UTIL. RETRY DELAY
BYFFERQUERY 64 64 0 32 142836 1 3.968 0.062 0 0
KONVERTOR 1024 1024 0 20 142836 1 1.186 0.001 0 0
FEC XN PRI BDT ASSEM CURRENT NEXT PARAMETER VALUE
35707 0 3600022.844 35707 15 16
35711 0 3600121.406 35711 0 1
35712 0 7200000.000 35712 0 18
В этом отчете по прежнему видно, что поступающие запросы обрабатываются и проходят все этапы. Но следует отметить, что нагрузка на БД стала равна практически 50 процентам, из этого следует, что при увеличении интенсивности поступления запросов, база данных на сервере станет узким местом в выделенном технологическом процессе. Смоделируем с более частой интенсивностью поступления запросов и проанализируем результат. Интенсивность поступления запросов 10 миллисекунд.
GPSS World Simulation Report - курсач модель.90.1
Monday, December 08, 2014 06:45:57
START TIME END TIME BLOCKS FACILITIES STORAGES
0.000 3600000.000 19 1 2
NAME VALUE
BUFKON 10004.000
BUFQU 10003.000
BYFFERQUERY 10001.000
CMDQUERY 10.000
DATABASE 10006.000
DB 10005.000
KONVERTOR 10002.000
LABEL LOC BLOCK TYPE ENTRY COUNT CURRENT COUNT RETRY
1 GENERATE 359908 0 0
2 QUEUE 359908 0 0
3 ENTER 359908 0 0
4 DEPART 359908 0 0
5 ADVANCE 359908 14 0
6 LEAVE 359894 0 0
7 QUEUE 359894 0 0
8 ENTER 359894 0 0
9 DEPART 359894 0 0
10 ADVANCE 359894 2 0
11 LEAVE 359892 0 0
12 QUEUE 359892 287854 0
13 SEIZE 72038 0 0
14 DEPART 72038 0 0
15 ADVANCE 72038 1 0
16 RELEASE 72037 0 0
17 TERMINATE 72037 0 0
18 GENERATE 1 0 0
19 TERMINATE 1 0 0
FACILITY ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY
DATABASE 72038 1.000 49.972 1 72040 0 0 0 287854
QUEUE MAX CONT. ENTRY ENTRY(0) AVE.CONT. AVE.TIME AVE.(-0) RETRY
BUFQU 13 0 359908 340284 0.065 0.654 12.003 0
BUFKON 1 0 359894 359894 0.000 0.000 0.000 0
DB 287854 287854 359892 1 143732.795 1437759.274 1437763.269 0
STORAGE CAP. REM. MIN. MAX. ENTRIES AVL. AVE.C. UTIL. RETRY DELAY
BYFFERQUERY 64 8 0 64 1439632 1 39.990 0.625 0 0
KONVERTOR 1024 1016 0 56 1439576 1 11.986 0.012 0 0
FEC XN PRI BDT ASSEM CURRENT NEXT PARAMETER VALUE
359896 0 3600001.433 359896 5 6
359910 0 3600004.126 359910 0 1
359897 0 3600008.679 359897 5 6
359895 0 3600010.948 359895 10 11
359898 0 3600011.229 359898 5 6
359893 0 3600013.729 359893 10 11
359899 0 3600015.434 359899 5 6
72040 0 3600018.684 72040 15 16
359900 0 3600028.977 359900 5 6
359901 0 3600035.015 359901 5 6
359902 0 3600049.698 359902 5 6
359903 0 3600052.792 359903 5 6
359904 0 3600057.027 359904 5 6
359905 0 3600059.895 359905 5 6
359907 0 3600080.252 359907 5 6
359906 0 3600080.415 359906 5 6
359908 0 3600086.989 359908 5 6
359909 0 3600093.269 359909 5 6
359911 0 7200000.000 359911 0 18
Из этого отчета становится понятно, что БД перегружена и не справляется с таким количеством запросов в час. Так как под каждого пользователя выделяется собственная БД, то проблем в разделение БД не возникнет, но потребуется средства для покупки новых серверов, но так же можно сказать что с увеличением количества запросов, соответственно увеличиться количество пользователей. В следствии этих утверждений решением данной проблемы, возможно путем покупки двух новых серверов, распределение пользовательских баз данных между этими серверами. Смоделируем с той же интенсивностью поступления запросов при покупки двух новых серверов. Учтем время перенаправления данных, то есть добавим время задержки. На листинги 2 представлена модель с приобретенными серверами.
Листинг 2
SIMULATE
cmdtime EQU 10
byfferquery STORAGE 64
konvertor STORAGE 1024
GENERATE (Exponential(1,0,cmdtime))
QUEUE bufqu
ENTER byfferquery,4
DEPART bufqu
ADVANCE (Normal(30,100,1))
LEAVE byfferquery,4
QUEUE bufkon
ENTER konvertor
DEPART bufkon
ADVANCE 30,20
LEAVE konvertor
QUEUE db
GATE NU database,Met1
SEIZE database
DEPART db
ADVANCE 50,30
RELEASE database
Met1 QUEUE db2
GATE NU database2,Met2
SEIZE database2
DEPART db2
ADVANCE 60,35
RELEASE database2
Met2 QUEUE db3
GATE NU database2,Met3
SEIZE database3
DEPART db3
ADVANCE 60,35
RELEASE database3
Met3 TERMINATE
GENERATE 3600000 ;сегмент времени один час
TERMINATE 1
GPSS World Simulation Report - курсач модель2.23.1
Monday, December 08, 2014 07:43:41
START TIME END TIME BLOCKS FACILITIES STORAGES
0.000 3600000.000 32 3 2
NAME VALUE
BUFKON 10004.000
BUFQU 10003.000
BYFFERQUERY 10001.000
CMDTIME 10.000
DATABASE 10006.000
DATABASE2 10008.000
DATABASE3 10010.000
DB 10005.000
DB2 10007.000
DB3 10009.000
KONVERTOR 10002.000
MET1 18.000
MET2 24.000
MET3 30.000
LABEL LOC BLOCK TYPE ENTRY COUNT CURRENT COUNT RETRY
1 GENERATE 358359 0 0
2 QUEUE 358359 0 0
3 ENTER 358359 0 0
4 DEPART 358359 0 0
5 ADVANCE 358359 5 0
6 LEAVE 358354 0 0
7 QUEUE 358354 0 0
8 ENTER 358354 0 0
9 DEPART 358354 0 0
10 ADVANCE 358354 2 0
11 LEAVE 358352 0 0
12 QUEUE 358352 0 0
13 GATE 358352 0 0
14 SEIZE 59936 0 0
15 DEPART 59936 0 0
16 ADVANCE 59936 1 0
17 RELEASE 59935 0 0
MET1 18 QUEUE 358351 0 0
19 GATE 358351 0 0
20 SEIZE 51343 0 0
21 DEPART 51343 0 0
22 ADVANCE 51343 1 0
23 RELEASE 51342 0 0
MET2 24 QUEUE 358350 0 0
25 GATE 358350 0 0
26 SEIZE 51342 0 0
27 DEPART 51342 0 0
28 ADVANCE 51342 0 0
29 RELEASE 51342 0 0
MET3 30 TERMINATE 358350 0 0
31 GENERATE 1 0 0
32 TERMINATE 1 0 0
FACILITY ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY
DATABASE 59936 0.833 50.033 1 358349 0 0 0 0
DATABASE2 51343 0.856 60.046 1 358344 0 0 0 0
DATABASE3 51342 0.857 60.120 1 0 0 0 0 0
QUEUE MAX CONT. ENTRY ENTRY(0) AVE.CONT. AVE.TIME AVE.(-0) RETRY
BUFQU 15 0 358359 339995 0.060 0.603 11.765 0
BUFKON 1 0 358354 358354 0.000 0.000 0.000 0
DB 298416 298416 358352 59936 149088.973 1497746.077 1798564.093 0
DB2 307008 307008 358351 51343 153396.947 1541028.234 1798744.687 0
DB3 307008 307008 358350 19432 153397.381 1541036.898 1629392.869 0
STORAGE CAP. REM. MIN. MAX. ENTRIES AVL. AVE.C. UTIL. RETRY DELAY
BYFFERQUERY 64 44 0 64 1433436 1 39.818 0.622 0 0
KONVERTOR 1024 1022 0 13 358354 1 2.986 0.003 0 0
FEC XN PRI BDT ASSEM CURRENT NEXT PARAMETER VALUE
358344 0 3600003.778 358344 22 23
358361 0 3600017.085 358361 0 1
358349 0 3600025.199 358349 16 17
358356 0 3600026.480 358356 5 6
358355 0 3600028.505 358355 10 11
358357 0 3600032.787 358357 5 6
358358 0 3600034.587 358358 5 6
358354 0 3600035.190 358354 10 11
358359 0 3600083.711 358359 5 6
358360 0 3600092.155 358360 5 6
358362 0 7200000.000 358362 0 31
Из полученного отчета видно, что покупка трех серверов решила эту проблему. То есть в данных условиях покупка серверов станет оправданным вложением, позволит не потерять пользователей системы, избавить от перегрузок серверов и оборудования. Купленные сервера обслуживают меньшие количество запросов чем основной сервер, так как данные перенаправляются(соответственно на это тратится время) в случае если основной сервер занят. Для наглядности построим график очередей запросов к серверам. На рисунке 1 представлен график очередей.
Рисунок 1 – график очередей к серверам