Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

table_expire_interval limits fine-grained table expiration #740

Open
vpax opened this issue Jan 15, 2020 · 2 comments
Open

table_expire_interval limits fine-grained table expiration #740

vpax opened this issue Jan 15, 2020 · 2 comments

Comments

@vpax
Copy link
Contributor

@vpax vpax commented Jan 15, 2020

It appears that the global table_expire_interval sets a global lower bound on the expiration timeouts for container elements. I have a script that uses a short create_expire (e.g., 80 msec) but the expirations don't happen for 10+ seconds when running on a pcap (which has plenty of packets, so the problem isn't the packet-driven clock). If I redef table_expire_interval = 10 msec then I get the behavior I'd expect.

As best as I can figure, table_expire_interval is vestigial from back-in-the-day (it was introduced in Bro 0.7!), likely for performance reasons. I think at a minimum we should provide an attribute that can override it for a given table. It also seems worth assessing whether there's any performance benefit these days, given all the refinements that have been made to table expiration.

@jsiwek jsiwek added this to Unassigned / Todo in Release 3.2.0 via automation Jan 15, 2020
@jsiwek jsiwek added this to the 3.2.0 milestone Jan 15, 2020
@rsmmr

This comment has been minimized.

Copy link
Member

@rsmmr rsmmr commented Jan 16, 2020

Yeah, the semantics are "expire after at least X"--which in the case of ms vs secs isn't really great obviously. The exact time further affected by table_incremental_step as well.

The current behavior is so that we don't need install one timer per table entry. Making the interval a per-table attribute should work though.

@vpax

This comment has been minimized.

Copy link
Contributor Author

@vpax vpax commented Jan 17, 2020

FWIW, I did some measurements for my particular scenario. For default processing, lowering the global timeout to 100 msec makes no discernible difference to run time. Lowering it to 1 msec, however, is disaster (performance falls off by 5x).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Release 3.2.0
  
Unassigned / Todo
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.