[Bro] write_expire computational time

Aashish Sharma 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.

bro ./test-expire-func.bro
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.

Aashish 


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
> 
> -- 
> Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro


More information about the Bro mailing list