Имеем:
Есть 403 датчика (событий, реакций). В зависимости от сработавшего датчика нужно выполнить тот или иной код в Кэш.
Ежесекундно совершается от 5 до 70 событий. Все делается в режиме реального времени.
Количество датчиков планируется увеличить до 1500.
Получаем, что даже при 400 у нас в пиковые моменты кэш "спустую" может прогонять (пока дойдет до последней строки в коде КЭШ) 400*70=28000 строк.

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

То есть сейчас код нечто вроде
Если "А" выполняем то то код Кэш "..."
Если "В" выполняем то то код Кэш "...2.."
и так до "403"

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

Код можно не предлагать (не выкладывать), ГЛАВНОЕ ИДЕЯ (код напишем сами).

krvsaКак вариант "разделить" запись "события" от датчика от "обработки" этих, уже записаных, событий...

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

Нереально. Приоритетов между ними нет (у нас все профессии важны ;-) ) , есть только те, что чаще всего повторяются. Из 403 на 20 событий приходится около 75% всех сигналов, действий.

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

Как вариант еще иметь несколько процессов по обработке таблички событий, возможно это сделает приоритет более т.с. "активным"...
Посмотрим, может и сработает, но практически то же подход "ВЛОБ", только разделенный на несколько лбов (потоков).
----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT

krvsaКак вариант "разделить" запись "события" от датчика от "обработки" этих, уже записаных, событий...

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


Нереально. Приоритетов между ними нет (у нас все профессии важны ;-) ) , есть только те, что чаще всего повторяются. Из 403 на 20 событий приходится около 75% всех сигналов, действий.

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


Автоматически отпадает.

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

Посмотрим, может и сработает, но практически то же подход "ВЛОБ", только разделенный на несколько лбов (потоков).

servitИмеем список датчиков и соответствующий им код:

Далее вызываем код в зависимости от сработавшего датчика:
Ещё можно обработку разнести по разным экземплярам Caché с помощью ECP и отображения программ/пакетов.

Представьте себе искуственный интелект, где важна последовательность реакций на события.
Имеем "поток данных"
время, датчик, событие (показатель)
причем за секунду их может быть 70 срабатываний. Поток идет непрерывно. За рабочий день доходит до 800'000.

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

Не думаю, что быдет выигрыш - явно прослеживается проблема - согласование 400 баз по времени - то есть теперь придется сравнивать - время наступления события.

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

logist
Я бы делал так.

Заводим глобаль двухуровневую
^Code(Датчик,Событие)=Код
и делаем
if $data(^Code(Датчик,Событие)) xecute ^Code(Датчик,Событие)
Можно выполнять вместо xecute job или писать отдельную очередь
^очередь($i(^очередь))=^Code(Датчик,Событие)
и отдельным уже процессом обходить эту очередь, чтобы не тормозить процесс
который читает датчики.

Как то так.

=Сергей Шутов (logist)
ООО Димас, Хабаровск



Резултаты от датчиков идут потоком "ODBC" так что систему не сильно нагружает.
Цепляется последовательность по "id", которая совпадает практически по времени наступления событий.
"xecute" требует также проверку условия "Если" или наступления опреденного события (в нашем случае).

Повторю что у нас имеется.

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

Мы делаем:
вытаскиваем данные подряд из класса (по возрастанию id, последовательно)
затем в верхних страках If или Xecute с условием (не суть важно, суть одна) прописываем 20 наиболее частых событий (название событий, типа А1, А2, А3, А4-А20)

Затем, оставшиеся событий (сигналы) мы разделили на 2 части - очень редкие и прочие
очень редкие это Z1,Z2,Z3... их штук 50
осталось 403-50-20=333 (счастливое число)
которые мы также разделили на 7
В1,В2,В3...
С1,С2,С3

Что происходит.
Код написан следующим образом
Сперва идет проверка на предмет наступления наиболее частого события.
Затем проверка на В, или С, или..., или Z
Нашли, что это С
переход на группу событий С и делаем ту же выборку
Если С1 = ..., то такой то код.

Проверка Если = идет вроде бы быстро, но сам факт "пустой проверки на название датчика - тупым перебором" не особо радует.

Получается- что много частых, неэффективных проверок, которые через 8 часов приводят к задержке реакции на наступившие события примерно на 5-9 минут, что в нашем случае непременимо.

Дальнейшее дробление на группы событий ощутимого выигрыша не дает (не аткого как ждали).

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

Представьте скаутов опытных и не очень (почему скаутов - не знаю).
Те что не опытные - на предмет сбора трав - начинаю листать справочник и проверять какая трава и можно ли её есть/заваривать чай. и так для каждой травы - перелистывания справочника на 400 страниц.

Оптыный скаут - видит траву, справочник не перелистывает, а сразу знает что с ней можно/нужно деалть.

К тому же стремимся и мы.


Другие похожие направления - биржа. есть события - нужна реакция (молниеносная).
Или проверка самолета. Если возникла ошибка, нужна реакция (опять моментальная).
Если таких событий масса, то перебор всего списка сыграет роковую роль.

fotopravka.ru
Или проверка самолета.

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

lf^(событие)="метка^программы"
j метка^программы

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

fotopravka.ru
Проверка Если = идет вроде бы быстро, но сам факт "пустой проверки на название датчика - тупым перебором" не особо радует.

Получается- что много частых, неэффективных проверок, которые через 8 часов приводят к задержке реакции на наступившие события примерно на 5-9 минут, что в нашем случае непременимо.

Повторюсь, за день проходит до 800 000 событий и на все на них нужно дать ответную реакцию.

800000*50 (перебор строк) = 40 млн бесполезных исполняемых строк кода!!!

Ptn
ODBC вроде как не сильно быстрый ... не ?
Систему не загружает, (нагрузка 1-3% всего), Со своей задачей справляется, сбоев и проблем не замечено. Удобно, просто.

fotopravka.ru
Почему бы не составить матрицу событий :
^matrix(код события)=группа события, обработчик события
и проверять её элементарным $DATA(^matrix(код события)) c последующим $GET(^matrix(код события))

То же вариант. Надо бедет побробнее проанализировать.


fotopravka.ru
Что то я не пойму - а запись полученная через ODBC разве не однозначно определяет название датчика ?

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

lfЗдесь нет перебора, будьте внимательнее.
Фактически выполняется:
j @^global(событие)


Я может не совсем понимаю Вас.
Речь идет об общей базе на все события или на каждое событие - своя база (вссего 403 базы)
и после наступления события выполняется код. Тогда как с очередность - постоянно опрашивать все базы на предмет появления нового значения/сигнала.
Как тогда быть с очередностью. Не совсем понимаю.

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

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

DAiMorа как насчет использования триггеров
при добавлении строки в класс сразу обработаете нужное событие
быстрее чем триггер по-моему вы не отреагируете на появление события, и отслеживать нет необходимости, только главное выполнение операция по нужному событию вывести в отдельный процесс, тогда у вас не будет задержек в обработке транзакций
_________________________________
Cache for Windows NT (AMD64) 5.0.21 (Build 6408) Tue Jan 3 2006 13:37:41 EST

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

Alexey MaslovИмел в виду, конечно:


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