Generally, yes experience. There were a few flex parsers which could perform poorly. SMB-flex was notorious, due to the fact that it exercised everything flex was bad at. Lua parsers generally haven't shown any performance issues - with a couple exceptions that have already been addressed by updates. SMB_lua is significantly faster than SMB-flex was, no one should be afraid of it.
But some parsers sometimes just have to do a lot of work. So they aren't problematic so much as requiring a trade off between performance and visibility.
There isn't a way to know, "this parser is occupying these resources". Best practice is to make the parser do as little work as possible - which admittedly is more art than science.
Quick tips (all of these are covered in more depth in "The Book"):
- Use long, unique tokens. Each time a token is matched, the parser is run. Even if it does a little bit of work to decide that "this match" isn't relevant to the parser then bails, that's more work than the decoder needed to do. Choose tokens that are more likely to match only when relevant.
- Minimize the use of payload:find(). The less find-ing a parser has to do, the better.
- Limit the distance searched by payload:find(). The less payload the parser has to search, the better.
- Use small payload objects, rather than the entire stream.
- Localize variables and functions when it makes sense to do so.
- Avoid string manipulation when possible, especially appending - use table.concat() instead.
As for what to watch for, just as Jeff said,
- Dropped packets - classic sign of an unhappy decoder
- CPU
- Memory usage
Also be sure to watch your logs. I'd also suggest if possible to have an independent non-production decoder dedicated to content development and testing. Import pcaps instead of capturing live traffic so that you have a known, consistent, repeatable set of test data. Import, make changes, import again - repeat until ready to deploy the content for production use.
