Страниц: [1]   Вниз
  Отправить эту тему    Печать  
Автор Тема: Гибче работать со счетчиками количества срабатываний правил  (Прочитано 7151 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« : 31 марта 2007, 14:36:39 »

Хотелось бы иметь возможность:
  - в окне настроек списка обнулять счетчик количества срабатываний на одном конкретном правиле. Сейчас приходится лазить в файл lst;
  - автоматически обнулять счетчик при изменении любого поля правила (кроме "вкл/выкл").
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #1 : 31 марта 2007, 19:23:12 »

  - автоматически обнулять счетчик при изменении любого поля правила (кроме "вкл/выкл").

Я бы так не хотел! Можно просто открыть для редактирования поле "Количество попаданий" - и делай все, что хочешь...
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #2 : 27 апреля 2007, 11:59:49 »

Часто работающие правила нередко находятся в середине/конце списка. Результат срабатывания каждого из списков Ч, Т, Н, З не зависит от порядка применения правил. В связи с этим возникла мысль: было б эффективней проверять в первую очередь часто работающие правила, т.к. вероятность их срабатывания выше, чем у остальных. Соответственно, среднее время обработки списка сократится. Для этого при загрузке указанных списков, а также по таймауту (например, раз в сутки) автоматически сортировать их во внутреннем представлении по количеству попаданий (по убыванию).
Вместе с тем, нужно оставить возможность просмотра списка пользователем на вкладке настроек в произвольно выбранном им порядке следования правил.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #3 : 27 апреля 2007, 12:33:30 »

Соответственно, среднее время обработки списка сократится.

На сколько сократится? На несколько миллисекунд в день?
Практические замеры уже проводились и описаны в ФАКе! Скорость проверки списков даже при большом количестве правил падает незначительно!

Думаю, времени на автоматическую сортировку списков при старте уйдет гораздо больше, чем впоследствии сэкономится на непроверке "лишних" правил! Тем более, что при старте HC и без того сильно грузит процессор, а сортировка правил усугубит и еще более увеличит время старта!
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #4 : 27 апреля 2007, 13:25:48 »

На сколько сократится? На несколько миллисекунд в день?
Практические замеры уже проводились и описаны в ФАКе! Скорость проверки списков даже при большом количестве правил падает незначительно!

Думаю, времени на автоматическую сортировку списков при старте уйдет гораздо больше, чем впоследствии сэкономится на непроверке "лишних" правил! Тем более, что при старте HC и без того сильно грузит процессор, а сортировка правил усугубит и еще более увеличит время старта!
Если НС не предназначен для обслуживания сети из нескольких пользователей, то правда твоя. Если предназначен - будет теряться уйма времени, и проверки списков будут здорово грузить ЦПУ. Если тест проводился на однопользовательском варианте, с ленивым хождением по сайтам и замером времени на глазок, то что можно ожидать? Сам подумай - на простые 15000 сравнений строк сколько уйдет времени/ресурсов процессора? А на обработку 15000 регулярных выражений? А теперь поток запросов сделать более-менее непрекращающимся?
Имхо, если рассматривается сетевой вариант, надо учитывать.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #5 : 27 апреля 2007, 14:03:17 »

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

Пока же опыты показывают, что при пиковой нагрузке больше всего грузит ЦПУ само формирование дерева в мониторе, а не проверка списков, как таковая! Именно в том направлении надо работать в первую очередь, т.е. создать серверную часть без GUI...
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #6 : 27 апреля 2007, 14:09:20 »

Пока же опыты показывают, что при пиковой нагрузке больше всего грузит ЦПУ само формирование дерева в мониторе, а не проверка списков, как таковая! Именно в том направлении надо работать в первую очередь, т.е. создать серверную часть без GUI...
Приоритетность - совершенно другой вопрос. Здесь обозначено предложение, которое, имхо, надо запомнить. А реализовывать уже в порядке приоритетности.
Кстати, очень жаль, что к просьбе сереги_ang так и не прислушались, и опыты не доведены до конца.  Грустный
« Последнее редактирование: 27 апреля 2007, 14:14:06 от Михаил » Сообщить модератору   Записан
Страниц: [1]   Вверх
  Отправить эту тему    Печать  

 
Перейти в: