Project

General

Profile

Actions

Bug #1024

closed

Perf profiling different if we club 2 rules

Added by Anoop Saldanha over 10 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

Description

Profiling enabled on my 2.0beta1-

2 rules -
alert tcp any any -> any any (content:"curl"; http_header; sid:1;)
alert tcp any any -> any any (content:"curl"; http_user_agent; sid:1;)

If I run the sigs independently, both of them seem to take almost equal no of ticks,
according to the profiling stats.

If I load both the rules at the same time, the first sig that is processed is
reported to take a lot of ticks(which is equal to the ticks it would take to run it
individually), but the second sig takes far less ticks than the first sig that is
processed.

These are the ticks obtained from a simple pcap that I have that accesses
a web page-

cat rules_file_hh.rules
alert tcp any any -> any any (content:"curl"; http_header; sid:1;) // 24k ticks

cat rules_file_ua.rules
alert tcp any any -> any any (content:"curl"; http_user_agent; sid:1;) // 24k ticks

cat rules_file_both_1.rules
alert tcp any any -> any any (content:"curl"; http_header; sid:1;) // 24k ticks
alert tcp any any -> any any (content:"curl"; http_user_agent; sid:2;) // 3k ticks

cat rules_file_both_2_reverse_order.rules
alert tcp any any -> any any (content:"curl"; http_user_agent; sid:1;) // 24k ticks
alert tcp any any -> any any (content:"curl"; http_header; sid:2;) // 3k ticks

What might be the reason for the faster perf of the 2nd sig, when we load both of
them simultaneously. Caching from the first sig processing speeding the processing
on the second sig, bug?

Actions #1

Updated by Victor Julien over 10 years ago

It would be interesting to add a few more similar rules to the mix and see how the profiling looks for those. Maybe there is a hidden "startup cost" to the stateful detection. Like allocating the de_state perhaps.

Actions #2

Updated by Victor Julien over 10 years ago

  • Target version changed from 2.0beta2 to TBD
Actions #3

Updated by Victor Julien over 5 years ago

  • Status changed from New to Closed
  • Assignee deleted (OISF Dev)
  • Target version deleted (TBD)

Could be caching too, where the first call does the mem lookups and the 2nd can use the hot caches. Don't think this is a bug.

Actions

Also available in: Atom PDF