[Snort-users] Snort/Barnyard2 performance with remote DB

Mike Lococo mikelococo at ...11827...
Wed Feb 29 10:25:18 EST 2012

On 02/28/2012 07:37 PM, beenph wrote:
> The revamped output plugin using the old schema will increase your
> perf ...at least by a 10 time factor if not more (trying to be
> conservative here).
> Have you tried it?

A factor of 10 doesn't make a meaningful difference for me.  For local
DB's with lan latency, barnyard2 is already plenty fast for my use.  For
remote DB's with 200ms of latency to be feasible I'd need to see a
factor of 100 improvement (remember we're starting from ~1 alert/sec for
a link with over 200ms latency).  I'm pretty sure this problem isn't
solvable without batching multiple alerts per tcp round-trip, or
employing dozens of insert threads to get parallelism.

My solution was to move the database local to the barnyard2 instance and
use a more latency tolerant protocol to push the events back to a
central system.  In my case, an Arcsight connector is doing that work
and it employs both batching and multiple transport threads to achieve
latency tolerance.

I really like barnyard2 as a tool.  I use it extensively and in almost
all of my deployments it introduces effectively zero overhead and isn't
even close to being a bottleneck.  It is highly sensitive to latency,
though, and in a few deployments I've had to engineer around that


More information about the Snort-users mailing list