When I say static context, I mean something like context=DETECTED_PING
and by dynamic I mean something like context=DETECTED_PING_FROM_$1 where
there is a dynamic value like $1 used in the expression's name.

Given your example minus the []'s we have:

  type=single
  context = ! NO_REGEXP_EXTRACTION
  ptype= regexp
  pattern = your hairy regexp here
  action = ....

So during SEC startup while the rules are loaded before event processing
begins, perhaps SEC could examine the rule and it if does not detect $1
or other dynamic values, it could internally flag the context with [ !
NOREGEXP_EXTRACTION ] and then before attempting to match the new line
per the regexp it would check the context first and potentially avoid
doing the regexp matching.  I'm thinking this may improve performance
but I don't know the ramifications in doing what I'm asking about.

I hope that clears up my question.

Regards,
Rock

-----Original Message-----
From: John P. Rouillard [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 10:53 AM
To: Mills, Rocky
Cc: [email protected]
Subject: Re: [Simple-evcorr-users] SUPPRESS processing earlier? 


In message <[EMAIL PROTECTED]>,
"Mills, Rocky" writes:
>>-----Excerpt from Original Message-----
>>When a rule is evaluated three things happen (well simplified):
>>
>>  1 check the context to see if the rule should be evaluated (this
>>    pre execution context is indicated with a context expression in
>>    square brackets 'context = [ context ]'.
>>  2 check the pattern according to ptype to see if the rule matches
>>  3 check the context (if it's not just a pre-context) to see if the
>>    rule's actions should trigger
>>
>>IIRC ContPreEval is the Cont(ext)Pre(pattern)Eval(uation). That was
>>added to permit the use of:
>>
>>  context = [ test ]
>>
>>so that a rule can be skipped entirely based on the state of the SEC
>>engine's contexts (since pattern application is the expensive part of
>>every rule regardless of whether it matches).
>>

>Given a ptype=regexp and a static context=NO_REGEXP_EXTRACTION (where
>nothing is needed from the line being evaluated) to form the context,
>does SEC skip this rule by checking the context first (like pre
>evaluation context avoiding the regexp match)?  Was thinking this makes
>sense for SEC to flag such a context with [] pre-pattern evaluation
upon
>rule set startup to avoid unnecessary pattern matching.  Perhaps it's
>already doing this.  If not would this improve SEC's performance?

I'm not sure what you are asking here. There no such thing as a
"static context" in sec. All contexts are dynamic can be created and
destroyed.

Since pre-evaluation only occurs if the context in enclosed in square
brackets '[]'. So if the environment when an event is processed
includes a defined context NO_REGEXP_EXTRACTION, and you have the rule

  type=single
  context = [ ! NO_REGEXP_EXTRACTION ]
  ptype= regexp
  pattern = your hairy regexp here
  action = ....

then SEC should (IIRC) never apply the pattern against the current
event.

Hmm, do you mean a constant context that doesn't depend on the results
of the rule match? If so, then no, I don't think it does a pre-eval on
that. Arguably it could do the same on SubStr as well. Checking
through my rulesets, that could be a win depending on how expensive
the regexp is.

Risto, any thoughts?

--
                                -- rouilj
John Rouillard
========================================================================
===
My employers don't acknowledge my existence much less my opinions.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users

Reply via email to