[Bro] write_expire computational time
asharma at lbl.gov
Tue Apr 25 08:24:12 PDT 2017
Oh! good point. That also reminds me that if your expire times are < 10seconds then you'd have to redef table_expire_interval to a value < 10 seconds.
1483204866.281666 starting: table_iteration, 1
1483204866.281932 inside table_expire_func: table_iteration, 2
1483204876.381928 inside table_expire_func: table_iteration, 3
1483204886.481921 inside table_expire_func: table_iteration, 4
1483204896.582114 inside table_expire_func: table_iteration, 5
Note: expire kicks in every 10 seconds.
## Check for expired table entries after this amount of time.
## .. bro:see:: table_incremental_step table_expire_delay
const table_expire_interval = 10 secs &redef;
Now reducing to < 10 seconds and putting a million elements is a tradeoff. So measure on your end before making production.
On Tue, Apr 25, 2017 at 08:07:06AM -0700, Robin Sommer wrote:
> On Tue, Apr 25, 2017 at 07:54 -0700, Johanna Amann wrote:
> > > if this is the case then write_expire should be O(n), is this correct
> > > ?
> > The time overhead of expiration is O(n), correct.
> To clarify because there could be different interpretations here: it's
> indeed O(n) for the whole expire operation, however that is amortized
> over a longer time frame: when Bro iterates over the table, it works
> on short slices at a time (which is the reason that it can take longer
> to expire an element, as Johanna wrote). So it's not O(n) for each
> table operation or such.
> Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin
> Bro mailing list
> bro at bro-ids.org
More information about the Bro