[Bro] spicy performance question

[Robin Sommer]

On Tue, Jun 07, 2016 at 22:21 -0400, Troy Jordan wrote:

> Since Spicy is still in development, is it to be expected that a
> Spicy-based Bro parser would perform significantly slower than an
> existing .pac parser of the same protocol?

In general, no, it's not expected; see the measurement results in the
HILTI paper, which show slightly worse performance in comparison with
existing analyzers (binpac or not), but not dramatically. That said, I
can't rule out that there are still major bottlenecks somewhere in
Spicy that trigger in specific situations.

> In my particular testing environment, the pac-baseed modbus parser
> processes 99% of a given modbus trace file when replayed at a specific
> speed with tcpreplay (logging enabled).

Measuring performance with live traffic is tricky, I usually do such
profiling offline from a trace: just measure execution time Bro needs
to get through the trace (with Spicy you need to exclude the startup
time, though, as that can still be substantial still right now).

The one thing that running offline doesn't get you are potential brief
processing spikes that cause trouble down the read: say there's one
packet causing Spicy go to into a looong loop for some reason; that
could then lead Bro to drop packets because it can't keep up buffering
incoming traffic long enough. In fact, that's one large reason why
Spicy remains not ready for production: as far as I know, it hasn't
been used for live analysis much at all so far, i.e., such effects are
not understood yet. Bro used to have such problems in early versions
as well, which got rooted out only over time.

Robin

-- 
Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin