Не очень конструктивное "НО"



Posted by Аркадий Водяник on July 29, 1999 at 05:23:33:

In Reply to: Неплохо, НО. posted by Борис, Киев. on July 28, 1999 at 23:44:04:

Борис пишет:

Предположения 1 -среднее время "чистой" обработки запроса очень претендует на место
аргумента в исследованиях, а не константу.

А у меня предположение 1) обозначено как а) и звучит не совсем так:


a) Сервер выполняет любой запрос за фиксированное время st.

И я предупреждал в конце своего сообщения:

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

Исходя из этого: что мешает Вам, если, конечно, по-настоящему интересно,
модифицировать функцию ServerDone? И даже если этого не делать, что мешает
задавать различные значения константе st?

Далее:

Предположение 2 - разве предположение?

У меня это было записано так:

b) Каждый пользователь НЕ МОЖЕТ послать запрос, пока не пришел ответ на
предыдущий запрос; другими словами, он взаимодействует с Сервером по одному
каналу...

Да, это предположение. Дело в том, что Клиент для Windows может открыть несколько
каналов - например, для нескольких одновременно открытых окон с формами.

Еще:

Если не затруднит повториться об очередях или псевдоочередях?
Какой алгоритм или просто какая реальная картина обработки запросов в процессе,
например, 10 последовательных отправлений(нажатий-"отправить запрос") с разрывом
в тик или одновременного. Так как "какой под руку попадется", как-то совсем не по
нашему...
60сек между запросами-тоже далеко от истины. Ведь при вводе операции открываются
формы в ветвях вопросах одна за другой и в руководстве нигде не описаны
предостережения от запуска таких плеяд.

Не затруднит. Каждый новый запрос помещается в каталог в виде файла *.in.
Как операционная система помещает новый файл в каталог обмена? Наверное примерно так,
как показано в этих строках модели - т.е. ищет освобожденную ранее позицию в каталоге:


for j:=1 to N
do if not Box[j].Active
then begin Box[j].Active:=true; Box[j].User:=i; goto 1; end;

А как Сервер ищет следующий запрос для обработки? Тоже сканирует каталог: сначала
до конца, а затем снова сначала:


for i:=ServerP+1 to N
do if Box[i].Active
then begin ServerP:=i; ServerT:=Tick; goto NextTick; end;
for i:=1 to ServerP-1
do if Box[i].Active
then begin ServerP:=i; ServerT:=Tick; goto NextTick; end;

О 60с. Во-первых, в модели есть случайность - см.функцию UserWant. Там и "плеяды"
возникают иногда. Запросы ведь не идут со строгой периодичностью - есть
флуктуации, и значительные. Во вторых, на то она и модель, чтобы менять константу ut.


Формальный вопрос.
1. Чем объяснить физический смысл пилообразности при А=28 и 30?

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


Думаю, что поиски имитационных моделей полезны, но давайте подумаем, что нам от этого
всего надо?

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


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

Это хорошее предложение. Из файла Log в LogMode, например, можно извлечь много полезной
информации, не то что из имитационной модели. Но для этого нужны утилиты, которых еще нет.
А человеко-часы есть и у нас.


Пpишедшие ответы: